Re: [FFmpeg-devel] [PATCH] avcodec/libilbc: Support newer libiLBC versions

[Timothy Gu]

On Wed, Mar 10, 2021 at 7:49 PM Andreas Rheinhardt
 wrote:
> Beginning with version 3.0, libiLBC switched the types of some parts
> of their public API to size_t and renamed some types; the old names
> continue to work as typedefs, but are deprecated. It furthermore
> added version macros.
>
> This commit uses said version macro to use the new types when using
> newer libiLBC versions.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/libilbc.c | 17 +
>  1 file changed, 17 insertions(+)

LGTM. Thanks!

[...]

Best,
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add doc on ffmpeg-devel, update on -cvslog list (v3)

[Timothy Gu]

Hi,

On Mon, Dec 4, 2017 at 4:43 AM Carl Eugen Hoyos  wrote:

> The patch is not ok, Carl Eugen


It is clear that you have no respect for community consensus.

9 for removal of mandatory status (10 counting myself):
TR: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220272.html

PBM:
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220441.html
RB: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221152.html
RP: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221155.html
CB: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221204.html
DB: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221695.html
HL: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221697.html
wm4: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221727.html
LL: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221729.html

2 neutral:
MT: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221174.html
(personally
uses -cvslog but "try to reply to -devel")
MN: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221387.html
(encourage
subscription rather than require it)

1 against:
You.

As the Documentation maintainer, this patch LGTM. With community consensus,
this is thusly applied.

Thanks to you all.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

[Timothy Gu]

Hi all,

On Sun, Nov 26, 2017 at 12:32 AM Jim DeLaHunt 
wrote:
> 1. In doc/developer.texi, eliminate the single chapter,
> and promote each section underneath to chapter, and
> each subsection to section. Thus content and relative
> structure remains the same, but the overall structure is
> simpler.  Anchors within the page remain the same.

I have manually applied this part of the patch, which is noncontroversial
and a
strict improvement to what we have right now.

> 2. In doc/developer.texi, add a new section about
> ffmpeg-devel, based on existing text from ffmpeg-cvslog
> section regarding discussion of patches and of
> development issues.

The wording in
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221199.html sounds
good
to me.

> 3. In doc/developer.texi, rewrite the ffmpeg-cvslog section
> to match the current usage of ffmpeg-cvslog. Some developers
> choose to follow this list, but it is not mandatory.

> +from all sources. Subscribing to this list is not mandatory, if
> +all you want to do is submit a patch here and there.

I would remove the "if" part, leaving only the "not mandatory" message.
Over my
tenure as FFmpeg developer I have never subscribed to -cvslog, since there
are
other ways of following FFmpeg development these days (subscribing to the
FFmpeg repo on GitHub, for example). I am glad to see this sentiment echoed
by
Ronald and Rostislav.

However, other than this technicality, I am in favor of the spirit of this
part
of the patch.



Carl,

On Mon, Nov 27, 2017 at 3:03 PM Carl Eugen Hoyos  wrote:
> If you believe that it is unclear that there is a difference between an
> occasional contributor (who most likely would not read -devel nor
> -cvslog) and a committer (who is supposed to read -cvslog), then
> maybe a patch is useful.
>
> I believe the difference could be considered common sense.

Thank you for expressing your opinion regarding this. However, I cannot say
I
agree with this evaluation. As I read this paragraph as it currently stands,
the tone makes it sound like subscription is mandatory ("we expect you"). I
believe the proposed modification is a significant improvement over the
existing text.

Additionally, from what I'm reading, it seems as if you believe subscribing
to
-cvslog is even more important than subscribing to -devel, which is false,
plain and simple.

Without further opinions from you, I will be applying this part of the
patch in
due time, by virtue of being the maintainer of Documentation.

Thanks to you all,

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/utils: simplify lockmgr

[Timothy Gu]

On Sun, Nov 26, 2017 at 8:44 PM Rostislav Pehlivanov 
wrote:

> @@ -103,8 +104,7 @@ static int default_lockmgr_cb(void **arg, enum
> AVLockOp op)
>  case AV_LOCK_DESTROY:
>  if (*mutex)
>  pthread_mutex_destroy(*mutex);
> -av_free(*mutex);
> -avpriv_atomic_ptr_cas(mutex, *mutex, NULL);
> +av_freep(*mutex);
>

av_freep(mutex)? Probably why Michael is seeing the crash.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] qsvdec: Fix memory leak

[Timothy Gu]

Found by Coverity in FFmpeg.
---
 libavcodec/qsvdec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index ea4abfa..258042d 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -305,8 +305,10 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
 
 do {
 ret = get_surface(avctx, q, );
-if (ret < 0)
+if (ret < 0) {
+av_freep();
 return ret;
+}
 
 ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ?  : 
NULL,
   insurf, , sync);
-- 
2.10.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] qsvdec: Fix memory leak

[Timothy Gu]

Fixes CID1396851.
---
 libavcodec/qsvdec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index ea4abfa..258042d 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -305,8 +305,10 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
 
 do {
 ret = get_surface(avctx, q, );
-if (ret < 0)
+if (ret < 0) {
+av_freep();
 return ret;
+}
 
 ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ?  : 
NULL,
   insurf, , sync);
-- 
2.10.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] omx: Fix OOM check

[Timothy Gu]

Also use av_mallocz_array().

Fixes CID1396839.
---
 libavcodec/omx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index c1b6fb9..b5093f4 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -352,12 +352,12 @@ static av_cold int find_component(OMXContext 
*omx_context, void *logctx,
 av_log(logctx, AV_LOG_WARNING, "No component for role %s found\n", 
role);
 return AVERROR_ENCODER_NOT_FOUND;
 }
-components = av_mallocz(sizeof(char*) * num);
+components = av_mallocz_array(num, sizeof(*components));
 if (!components)
 return AVERROR(ENOMEM);
 for (i = 0; i < num; i++) {
 components[i] = av_mallocz(OMX_MAX_STRINGNAME_SIZE);
-if (!components) {
+if (!components[i]) {
 ret = AVERROR(ENOMEM);
 goto end;
 }
-- 
2.10.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] travis: setup for automated coverity builds

[Timothy Gu]

On Fri, Dec 2, 2016 at 3:22 AM Timo Rothenpieler <t...@rothenpieler.org>
wrote:

> On 12/2/2016 4:14 AM, Timothy Gu wrote:
> > On Thu, Dec 1, 2016 at 1:23 PM Timo Rothenpieler <t...@rothenpieler.org>
> > wrote:
> >
> >> Travis can only run scheduled builds daily, weekly or monthly.
> >
> > So we run them daily, and use a bit of logic in the .travis.yml to
> >> cancel out early on 3 days per week.
> >>
> >
> > Nice! Didn't know Travis CI could do this.
> >
>
> It needs to be explicitly requested, but I don't think that will be an
> issue if we explain them our usecase:
> https://docs.travis-ci.com/user/cron-jobs/


Agreed.

>
> > A few nits: indent the array, just as you did for `services`; the
> official
> > Travis CI-Coverity bridge uses COVERITY_SCAN_NOTIFICATION_EMAIL and
> > COVERITY_SCAN_TOKEN, so for consistency you might want to change that.
>
> Updated the image to use those, updated this patch locally to do the same.


> > Another thing is that currently https://github.com/BtbN/FFmpeg-Coverity
> (the
> > source of "ffmpeg/coverity" image) belongs to your GitHub account. Maybe
> we
> > should think of transferring that to github.com/FFmpeg?
>
> I can't create that repository myself, but so if someone could import it
> from my Account, that would be nice.
>

That has been done my Michael as I can see.

So one question: will this .travis.yml be applied to the main FFmpeg repo
or the newly created FFmpeg-Coverity repo?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] travis: setup for automated coverity builds

[Timothy Gu]

On Thu, Dec 1, 2016 at 1:23 PM Timo Rothenpieler 
wrote:

> Travis can only run scheduled builds daily, weekly or monthly.

So we run them daily, and use a bit of logic in the .travis.yml to
> cancel out early on 3 days per week.
>

Nice! Didn't know Travis CI could do this.


> ---
>  .travis.yml | 32 +++-
>  1 file changed, 7 insertions(+), 25 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index e541ee1..abc264a 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -1,26 +1,8 @@
> -language: c
> -sudo: false
> -os:
> -  - linux
> -  - osx
> -addons:
> -  apt:
> -packages:
> -  - yasm
> -  - diffutils
> -compiler:
> -  - clang
> -  - gcc
> -cache:
> -  directories:
> -- ffmpeg-samples
> -before_install:
> -  - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew update --all; fi
> -install:
> -  - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew install yasm; fi
> +sudo: required
> +services:
> +  - docker
>  script:
> -  - mkdir -p ffmpeg-samples
> -  - ./configure --samples=ffmpeg-samples --cc=$CC
> -  - make -j 8
> -  - make fate-rsync
> -  - make check -j 8
> +- DOW="$(date "+%u")"
> +- for d in 2 4 6; do [[ "$d" == "$DOW" ]] && exit 0; done
> +- docker pull ffmpeg/coverity
> +- docker run --env COV_EMAIL --env COV_TOKEN ffmpeg/coverity
>

A few nits: indent the array, just as you did for `services`; the official
Travis CI-Coverity bridge uses COVERITY_SCAN_NOTIFICATION_EMAIL and
COVERITY_SCAN_TOKEN, so for consistency you might want to change that.

Another thing is that currently https://github.com/BtbN/FFmpeg-Coverity (the
source of "ffmpeg/coverity" image) belongs to your GitHub account. Maybe we
should think of transferring that to github.com/FFmpeg?

I also have a few comments on your current build scripts, but we can change
those once this patch is in.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] travis.yml: Whitelist "coverity" branch in preparation for Coverity integration

[Timothy Gu]

---
 .travis.yml | 3 +++
 1 file changed, 3 insertions(+)

This patch will needed to be applied to all Git branches because of a Travis CI
restriction:
https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches

diff --git a/.travis.yml b/.travis.yml
index e541ee1..a50c46d 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,5 +1,8 @@
 language: c
 sudo: false
+branches:
+  only:
+- coverity
 os:
   - linux
   - osx
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Timothy Gu]

On Sun, Nov 27, 2016 at 1:52 PM Michael Niedermayer 
wrote:

> I dont want to give a automated travis_ci system any write or admin
> access, some of what i read hinted in that direction, some of what
> i read hinted that this was not needed though
> giving a automated system write access would be a security issue and
> we should not do that
>

You don't need to give Travis CI any privileges. The way it's going to work
is:

1. Set up a dedicated "coverity" branch
2. Set up Travis CI to only watch changes on that branch, and when there is
a new push compile the code with Coverity's custom wrappers, etc.
3. Set up a cronjob on a computer (doesn't matter who's) that pulls new
commits on master into coverity every |x| days

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Timothy Gu]

On Sun, Nov 27, 2016 at 1:13 PM Philip Langdale  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sun, 27 Nov 2016 21:26:13 +0100
> Michael Niedermayer  wrote:
>
> > On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > On Sat, 26 Nov 2016 23:55:17 +0100
> > > Michael Niedermayer  wrote:
> > >
> > > > Hi all
> > > >
> > > > The machine on which the coverity stuff is is old, both hw and OS.
> > > > the OS will no longer get security updates in a few months and
> > > > the hw does not always boot and its switched off most of the time.
> > > > and it has no other use anymore than running coverity. Ive tried
> > > > to find someone a while ago to take coverity testing over and i
> > > > thought timothy would maybe do it but he seems to not have had any
> > > > time to look into it ...
> > > > and de facto ive not run it regularly in the recent months.
> > > > So this is kinda a louder announcement that if you care about
> > > > coverity testing, you need to do something ...
> > > >
> > > > thx
> > > >
> > > > PS: work would involve installing every optional dependancy of
> > > > FFmpeg (and keep them updated as needed)
> > > > and regularly either manually or automatically git pull, build
> > > > with the coverity tools and upload Its not a huge amount of work
> > > > but it is work
> > > >
> > >
> > > Hi Michael,
> > >
> > > I think we could do this using travis-ci.
> > >
> > > https://scan.coverity.com/travis_ci
> > >
> > > travis can be directly connected to the github mirror and then we
> > > set up a coverity job as covered in this doc.
> > >
> > > It wouldn't even need to be configured to build - just run the
> > > coverity scan. I'd be happy to investigate this, but I'd need admin
> > > permissions on github to configure travis integration.
> >
> > The way coverity works is by wraping around the compiler or something
> > gether lots of info and that is then uploaded
> > so you need configure and build
> >
> > for coverity to check all optional code it needs all the headers
> > from nvidia, sdl, x11 to the most obscure.
> > if they arent installed coverity wouldnt be able to test these
> > components as the code would not be complete
> >
> > so in whatever envirnment this is done all optional dependancies
> > must be installed one way or another.
> >
> > i assume in the example on https://scan.coverity.com/travis_ci
> > build_command_prepend: ./configure
> > would be a very long command with many --enable*
> >
> > also therese that limit:
> > https://scan.coverity.com/faq#frequency
> > Up to 12 builds per week, with a maximum of 3 builds per day, for
> > projects with fewer than 100K lines of code Up to   8 builds per
> > week, with a maximum of 2 builds per day, for projects with 100K to
> > 500K lines of code Up to   4 builds per week, with a maximum of 1
> > build per day, for projects with 500K to 1 million lines of code Up
> > to   2 builds per week, with a maximum of 1 build per day, for
> > projects with more than 1 million lines of code
> >
> > so we cannot do coverity after every commit, a cronjob might be a
> > simpler choice that runs at the frequency that we can submit
> >
> > Is there still an advantage in travis ci / would that still be
> > preferred?
> >
> > [...]
>
> The recommended configuration on that page is to have it watch a branch
> and you push master to the branch when you want a scan. We can do that
> whenever we want - once a month or whatever. Right now you are doing it
> ad-hoc, and we could still do it ad-hoc. Equally, a cron job running
> somewhere could push to the branch on whatever frequency we want.
>
> The goal here is to remove the need for the dedicated build machine, not
> to improve any other part of the process - although there will be
> opportunities for that.
>
> I've looked at how you prepare a build environment in travis and it's
> simple to install dependencies; that won't be a problem.
>

Libav has had used Travis for a while now for FATE, and I personally have
attempted to set up the same for FFmpeg, without much success.

The problem with using Travis for Coverity (versus a local machine) is
still the issue of dependencies. While system-level deps like vdpau can be
installed easily, there are three classes of other deps that need to be
installed to make Coverity the most useful:

1. Dependencies very few people use, and therefore not packaged by Ubuntu
(e.g. libnut, libxavs, zimg)
2. Dependencies in active development, only the newest versions of which
are accepted by FFmpeg's build system (there currently isn't any examples
but it's not impossible to see this in the future)
3. Proprietary dependencies, which may or may not currently be an issue
anymore. Philip and Timo, how easy is it to get cuda/nvenc/cuvid/npp to
compile.

Timothy
___

Re: [FFmpeg-devel] [PATCH 1/2] pixdesc: Order function prototypes semantically

[Timothy Gu]

On Mon, Aug 22, 2016 at 5:53 AM Michael Niedermayer <mich...@niedermayer.cc>
wrote:

> On Sun, Aug 21, 2016 at 05:09:00PM -0700, Timothy Gu wrote:
> > ---
> >  libavutil/pixdesc.h | 194
> ++--
> >  1 file changed, 97 insertions(+), 97 deletions(-)
>
> LGTM
>
> thx
>

Applied, thanks.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] pixfmt: Use enum assignment for aliases

[Timothy Gu]

On Tue, Aug 23, 2016 at 12:28 PM Michael Niedermayer <mich...@niedermayer.cc>
wrote:

> On Sun, Aug 21, 2016 at 05:09:01PM -0700, Timothy Gu wrote:
> > This way, Doxygen is happier as aliases are now grouped together, and
> > it never handled #define's in an enum well in the first place.
> >
> > Y400A already exists as an enum assignment.
> > ---
> >  libavutil/pixfmt.h | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index 6f71ac0..efc3714 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -77,7 +77,7 @@ enum AVPixelFormat {
> >  #if FF_API_XVMC
> >  AV_PIX_FMT_XVMC_MPEG2_MC,///< XVideo Motion Acceleration via common
> packet passing
> >  AV_PIX_FMT_XVMC_MPEG2_IDCT,
> > -#define AV_PIX_FMT_XVMC AV_PIX_FMT_XVMC_MPEG2_IDCT
> > +AV_PIX_FMT_XVMC = AV_PIX_FMT_XVMC_MPEG2_IDCT,
> >  #endif /* FF_API_XVMC */
> >  AV_PIX_FMT_UYVY422,   ///< packed YUV 4:2:2, 16bpp, Cb Y0 Cr Y1
> >  AV_PIX_FMT_UYYVYY411, ///< packed YUV 4:1:1, 12bpp, Cb Y0 Y1 Cr Y2
> Y3
> > @@ -178,6 +178,7 @@ enum AVPixelFormat {
> >  AV_PIX_FMT_YUV422P9LE, ///< planar YUV 4:2:2, 18bpp, (1 Cr & Cb
> sample per 2x1 Y samples), little-endian
> >  AV_PIX_FMT_VDA_VLD,///< hardware decoding through VDA
> >  AV_PIX_FMT_GBRP,  ///< planar GBR 4:4:4 24bpp
> > +AV_PIX_FMT_GBR24P = AV_PIX_FMT_GBRP, // alias for #AV_PIX_FMT_GBRP
> >  AV_PIX_FMT_GBRP9BE,   ///< planar GBR 4:4:4 27bpp, big-endian
> >  AV_PIX_FMT_GBRP9LE,   ///< planar GBR 4:4:4 27bpp, little-endian
> >  AV_PIX_FMT_GBRP10BE,  ///< planar GBR 4:4:4 30bpp, big-endian
> > @@ -308,9 +309,6 @@ enum AVPixelFormat {
> >  AV_PIX_FMT_NB,///< number of pixel formats, DO NOT USE THIS
> if you want to link with shared libav* because the number of formats might
> differ between versions
> >  };
> >
> > -#define AV_PIX_FMT_Y400A AV_PIX_FMT_GRAY8A
> > -#define AV_PIX_FMT_GBR24P AV_PIX_FMT_GBRP
> > -
> >  #if AV_HAVE_BIGENDIAN
> >  #   define AV_PIX_FMT_NE(be, le) AV_PIX_FMT_##be
> >  #else
>
> probably ok
>
> thx
>

Applied, thanks.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] doc/t2h: use container

[Timothy Gu]

On Sun, Oct 02, 2016 at 02:53:22PM +0100, Josh de Kock wrote:
> Full width text is really difficult to read, this makes it more
> more legible on larger (widescreen) screens. It also means we aren't
> inventing our own container instead of using the bootstrap one.
> 
> Signed-off-by: Josh de Kock 
> ---
>  doc/t2h.init | 2 +-
>  doc/t2h.pm   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

LGTM.

[...]

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/t2h: add max-width to css.

[Timothy Gu]

On Fri, Sep 30, 2016 at 6:28 PM Josh de Kock  wrote:

> Full width text is really difficult to read, this just makes it
> slightly more legible on larger (widescreen) screens.
>
> Signed-off-by: Josh de Kock 
> ---
> See http://screenshotcomparison.com/comparison/186256 for a comparison of
> before/after.
>
>  doc/t2h.init | 2 +-
>  doc/t2h.pm   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/t2h.init b/doc/t2h.init
> index c41be2e..994e276 100644
> --- a/doc/t2h.init
> +++ b/doc/t2h.init
> @@ -22,7 +22,7 @@ EOT
>  my $TEMPLATE_HEADER2 = $ENV{"FFMPEG_HEADER2"} || <
>
> -
> +
>  EOT
>
>  my $TEMPLATE_FOOTER = $ENV{"FFMPEG_FOOTER"} || < diff --git a/doc/t2h.pm b/doc/t2h.pm
> index 5efb2da..a3b7c6b 100644
> --- a/doc/t2h.pm
> +++ b/doc/t2h.pm
> @@ -174,7 +174,7 @@ EOT
>  
>
>
> -
> +
>
>  EOT
>

Perhaps, using the Bootstrap "container" class would be better as it
provides responsive equivalents for other screen sizes.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] pixfmt: Use enum assignment for aliases

[Timothy Gu]

On Sun, Aug 21, 2016 at 05:09:01PM -0700, Timothy Gu wrote:
> -#define AV_PIX_FMT_XVMC AV_PIX_FMT_XVMC_MPEG2_IDCT
> +AV_PIX_FMT_XVMC = AV_PIX_FMT_XVMC_MPEG2_IDCT,

I don't think this constitutes an API break, but comments are welcome.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] pixfmt: Use enum assignment for aliases

[Timothy Gu]

This way, Doxygen is happier as aliases are now grouped together, and
it never handled #define's in an enum well in the first place.

Y400A already exists as an enum assignment.
---
 libavutil/pixfmt.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 6f71ac0..efc3714 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -77,7 +77,7 @@ enum AVPixelFormat {
 #if FF_API_XVMC
 AV_PIX_FMT_XVMC_MPEG2_MC,///< XVideo Motion Acceleration via common packet 
passing
 AV_PIX_FMT_XVMC_MPEG2_IDCT,
-#define AV_PIX_FMT_XVMC AV_PIX_FMT_XVMC_MPEG2_IDCT
+AV_PIX_FMT_XVMC = AV_PIX_FMT_XVMC_MPEG2_IDCT,
 #endif /* FF_API_XVMC */
 AV_PIX_FMT_UYVY422,   ///< packed YUV 4:2:2, 16bpp, Cb Y0 Cr Y1
 AV_PIX_FMT_UYYVYY411, ///< packed YUV 4:1:1, 12bpp, Cb Y0 Y1 Cr Y2 Y3
@@ -178,6 +178,7 @@ enum AVPixelFormat {
 AV_PIX_FMT_YUV422P9LE, ///< planar YUV 4:2:2, 18bpp, (1 Cr & Cb sample per 
2x1 Y samples), little-endian
 AV_PIX_FMT_VDA_VLD,///< hardware decoding through VDA
 AV_PIX_FMT_GBRP,  ///< planar GBR 4:4:4 24bpp
+AV_PIX_FMT_GBR24P = AV_PIX_FMT_GBRP, // alias for #AV_PIX_FMT_GBRP
 AV_PIX_FMT_GBRP9BE,   ///< planar GBR 4:4:4 27bpp, big-endian
 AV_PIX_FMT_GBRP9LE,   ///< planar GBR 4:4:4 27bpp, little-endian
 AV_PIX_FMT_GBRP10BE,  ///< planar GBR 4:4:4 30bpp, big-endian
@@ -308,9 +309,6 @@ enum AVPixelFormat {
 AV_PIX_FMT_NB,///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
-#define AV_PIX_FMT_Y400A AV_PIX_FMT_GRAY8A
-#define AV_PIX_FMT_GBR24P AV_PIX_FMT_GBRP
-
 #if AV_HAVE_BIGENDIAN
 #   define AV_PIX_FMT_NE(be, le) AV_PIX_FMT_##be
 #else
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] pixdesc: Order function prototypes semantically

[Timothy Gu]

---
 libavutil/pixdesc.h | 194 ++--
 1 file changed, 97 insertions(+), 97 deletions(-)

diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
index 3b0bcdb..a8ad588 100644
--- a/libavutil/pixdesc.h
+++ b/libavutil/pixdesc.h
@@ -173,78 +173,6 @@ typedef struct AVPixFmtDescriptor {
 #define AV_PIX_FMT_FLAG_ALPHA(1 << 7)
 
 /**
- * Read a line from an image, and write the values of the
- * pixel format component c to dst.
- *
- * @param data the array containing the pointers to the planes of the image
- * @param linesize the array containing the linesizes of the image
- * @param desc the pixel format descriptor for the image
- * @param x the horizontal coordinate of the first pixel to read
- * @param y the vertical coordinate of the first pixel to read
- * @param w the width of the line to read, that is the number of
- * values to write to dst
- * @param read_pal_component if not zero and the format is a paletted
- * format writes the values corresponding to the palette
- * component c in data[1] to dst, rather than the palette indexes in
- * data[0]. The behavior is undefined if the format is not paletted.
- */
-void av_read_image_line(uint16_t *dst, const uint8_t *data[4],
-const int linesize[4], const AVPixFmtDescriptor *desc,
-int x, int y, int c, int w, int read_pal_component);
-
-/**
- * Write the values from src to the pixel format component c of an
- * image line.
- *
- * @param src array containing the values to write
- * @param data the array containing the pointers to the planes of the
- * image to write into. It is supposed to be zeroed.
- * @param linesize the array containing the linesizes of the image
- * @param desc the pixel format descriptor for the image
- * @param x the horizontal coordinate of the first pixel to write
- * @param y the vertical coordinate of the first pixel to write
- * @param w the width of the line to write, that is the number of
- * values to write to the image line
- */
-void av_write_image_line(const uint16_t *src, uint8_t *data[4],
- const int linesize[4], const AVPixFmtDescriptor *desc,
- int x, int y, int c, int w);
-
-/**
- * Return the pixel format corresponding to name.
- *
- * If there is no pixel format with name name, then looks for a
- * pixel format with the name corresponding to the native endian
- * format of name.
- * For example in a little-endian system, first looks for "gray16",
- * then for "gray16le".
- *
- * Finally if no pixel format has been found, returns AV_PIX_FMT_NONE.
- */
-enum AVPixelFormat av_get_pix_fmt(const char *name);
-
-/**
- * Return the short name for a pixel format, NULL in case pix_fmt is
- * unknown.
- *
- * @see av_get_pix_fmt(), av_get_pix_fmt_string()
- */
-const char *av_get_pix_fmt_name(enum AVPixelFormat pix_fmt);
-
-/**
- * Print in buf the string corresponding to the pixel format with
- * number pix_fmt, or a header if pix_fmt is negative.
- *
- * @param buf the buffer where to write the string
- * @param buf_size the size of buf
- * @param pix_fmt the number of the pixel format to print the
- * corresponding info string, or a negative value to print the
- * corresponding header.
- */
-char *av_get_pix_fmt_string(char *buf, int buf_size,
-enum AVPixelFormat pix_fmt);
-
-/**
  * Return the number of bits per pixel used by the pixel format
  * described by pixdesc. Note that this is not the same as the number
  * of bits per sample.
@@ -307,6 +235,103 @@ int av_pix_fmt_get_chroma_sub_sample(enum AVPixelFormat 
pix_fmt,
 int av_pix_fmt_count_planes(enum AVPixelFormat pix_fmt);
 
 /**
+ * @return the name for provided color range or NULL if unknown.
+ */
+const char *av_color_range_name(enum AVColorRange range);
+
+/**
+ * @return the name for provided color primaries or NULL if unknown.
+ */
+const char *av_color_primaries_name(enum AVColorPrimaries primaries);
+
+/**
+ * @return the name for provided color transfer or NULL if unknown.
+ */
+const char *av_color_transfer_name(enum AVColorTransferCharacteristic 
transfer);
+
+/**
+ * @return the name for provided color space or NULL if unknown.
+ */
+const char *av_color_space_name(enum AVColorSpace space);
+
+/**
+ * @return the name for provided chroma location or NULL if unknown.
+ */
+const char *av_chroma_location_name(enum AVChromaLocation location);
+
+/**
+ * Return the pixel format corresponding to name.
+ *
+ * If there is no pixel format with name name, then looks for a
+ * pixel format with the name corresponding to the native endian
+ * format of name.
+ * For example in a little-endian system, first looks for "gray16",
+ * then for "gray16le".
+ *
+ * Finally if no pixel format has been found, returns AV_PIX_FMT_NONE.
+ */
+enum AVPixelFormat av_get_pix_fmt(const char *name);
+
+/**
+ * Return the short name for a pixel format, NULL in case pix_fmt is
+ * unknown.
+ *
+ * @see 

Re: [FFmpeg-devel] [PATCH] mem: Extend and edit Doxygen

[Timothy Gu]

On Fri Aug 5 14:15:19 EEST 2016, Michael Niedermayer wrote:
> to me it sounds more natural without "the" but english aint my area

Changed.

> either way the patch overall looks nice (i didnt deeply review)
> Acked-by: Michael

Thanks. Pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Timothy Gu]

Hi

On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao  wrote:

>
>
> On 2016/8/16 10:14, Chao Liu wrote:
> > Sorry for this little diversion: what are the differences between QSV and
> > vaapi?
> > My understanding is that QSV has better performance, while vaapi supports
> > more decoders / encoders. Is that correct?
> > It would be nice if there are some data showing the speed of these HW
> > accelerated decoders / encoders.
>
> QSV has better performance is right, but libyami have more
> decoders/encoders than
> vaapi hw accel decoder/encoder. :)
>

I am not sure where you got this information.

On Intel platforms they all use the same chip. Because VAAPI supports more
than just Intel platforms, VAAPI supports all codecs libyami and QSV
support, if not more.

QSV works on both Windows and Linux, although it is a pain to set up a
Linux QSV environment (you have to have the right distro, right kernel,
etc.).


>
> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and
> native
> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> native
> vaapi encoder
>

You didn't mention _how_ you profiled things, and for HW encoding different
ways of profiling can cause wildly different results. If for example you
are not doing zero-copy VAAPI operations, you are inherently giving the
other two methods an edge.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Timothy Gu]

On Mon, Aug 15, 2016 at 6:00 PM Jun Zhao  wrote:

> I know the worry after read the above thread.For Intel GPU HW accelerate
> decode/encode,
> now have 3 options in ffmpeg:
>
> 1. ffmpeg and QSV (Media SDK)
> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> 3. ffmpeg and libyami
>
> And I know the guys prefer option 2 than 3, but I have a little question,
> what's the
> difference about ffmpeg/libyami and the other external codec library(e,g
> openh264,
> videotoolbox...)?
>

OpenH264 is software-only. VideoToolbox is Apple-only.


> As I know Intel have 3 full time Libyami developers, so no guarantee maybe
> is wrong.:)
>

That's true right now, but Intel has offered no guarantee for the future.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v7 01/11] avformat: Add fifo pseudo-muxer

[Timothy Gu]

On Sun, Aug 14, 2016 at 11:12 AM Marton Balint  wrote:

> On Thu, 11 Aug 2016, sebechlebsky...@gmail.com wrote:
> > +@anchor tee
>
> I still get error when building the docs:
>
> doc/muxers.texi:1531: @anchor expected braces
> doc/muxers.texi:1443: @ref reference to nonexistent node `tee'
> make: *** [doc/ffmpeg-all.html] Error 1

@anchor{tee} should work.
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/vdpau: clean up vdpau_internal.h

[Timothy Gu]

On Thu, Aug 4, 2016 at 12:57 AM Carl Eugen Hoyos  wrote:

> 2016-08-03 6:30 GMT+02:00 James Almer :
> > Also don't include it on files that don't need it.
> >
> > This reduces differences with libav
> >
> > Signed-off-by: James Almer 
> > ---
> > Untested with VDPAU enabled.
>
> The patch is probably ok if it does not brake compilation with
> VDPAU enabled or disabled.
>

Tested with VDPAU enabled. Compilation works.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Timothy Gu]

On Wed, Aug 3, 2016 at 11:57 AM James Almer  wrote:

> On 7/31/2016 5:01 PM, Michael Niedermayer wrote:
> > Hi all
> >
> > you have a great idea for a Outreachy task or a GSoC task ?
> > Or something you always wanted to do but never had the time and
> > it would fit in the time for GSoC/Outreachy ?
> > Or some feature you always wanted which would fit as a task?
> > Also keep in mind Outreachy is more flexible and not limited to
> > coding tasks !
> > reply and dump it here below:
>
> Writing new examples or porting decoding_encoding.c and
> demuxing_decoding.c to use codecpar and send/receive packet/frame.
>

+1

Maye also adding or extending doxy on public and private header,
> sort of like what Timothy did the last couple days, but as Paul
> said, coding related there's probably not a whole lot left that
> can be easily done by students.
>

+1 too.

Also fixing up some parts of FATE I don't have time to fix, and adapting
Doxygen output style to the website. Web development sounds like a buzzword
these days.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Timothy Gu]

On Wed, Aug 3, 2016 at 12:36 PM Michael Niedermayer 
wrote:

> what about writing guides/howtos about how to build/replace FFmpeg
> on all kinds of hw
>

That's the responsibility of the HW vendor.


> i mean everything these days uses FFmpeg below one or more layers
> and users should have the right to replace their products FFmpeg
> maybe with one that has more features enabled or a newer version
> but in practice for how many products that contain FFmpeg can
> the user actually do this easily? ...
>

Practically none, an amount easily matched by the number of users who are
interested in doing that.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] - libavdevices/decklink_*.cpp: formatting change to remove uneeded spaces in initializers

[Timothy Gu]

On Tue, Aug 2, 2016 at 10:17 PM Felt, Patrick 
wrote:

> ---
> libavdevice/decklink_common.cpp | 10 +-
> libavdevice/decklink_dec.cpp| 18 +-
> libavdevice/decklink_enc.cpp| 26 +-
> 3 files changed, 27 insertions(+), 27 deletions(-)
>

Pushed. If you could use git send-email to send patches, or at least send a
git formatted patch with a commit message and an author, that would be the
best.

Thanks,

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] af_hdcd: add flags to AVOption defs

[Timothy Gu]

On Mon, Aug 1, 2016 at 8:56 AM Burt P  wrote:

> Signed-off-by: Burt P 
> ---
>  libavfilter/af_hdcd.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>

Applied. You might also want to look into using AV_OPT_TYPE_BOOL for these
two options.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] jni, mediacodec: Return ENOSYS on unsupported platforms

[Timothy Gu]

On Tue, Aug 2, 2016 at 8:42 PM Timothy Gu <timothyg...@gmail.com> wrote:

> On Tue, Aug 2, 2016 at 6:30 PM James Almer <jamr...@gmail.com> wrote:
>
>> On 8/2/2016 7:28 PM, Timothy Gu wrote:
>> > ---
>> >  libavcodec/jni.c| 9 -
>> >  libavcodec/mediacodec.c | 6 --
>> >  2 files changed, 8 insertions(+), 7 deletions(-)
>> >
>>
>> I'd say split this in two patches, so you can easily cherry-pick
>> the jni part for release branches 3.0 and 3.1.
>>
>
> Done locally. Thanks for noticing.
>

Split up and pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] jni, mediacodec: Return ENOSYS on unsupported platforms

[Timothy Gu]

On Tue, Aug 2, 2016 at 6:30 PM James Almer <jamr...@gmail.com> wrote:

> On 8/2/2016 7:28 PM, Timothy Gu wrote:
> > ---
> >  libavcodec/jni.c| 9 -
> >  libavcodec/mediacodec.c | 6 --
> >  2 files changed, 8 insertions(+), 7 deletions(-)
> >
>
> I'd say split this in two patches, so you can easily cherry-pick
> the jni part for release branches 3.0 and 3.1.
>

Done locally. Thanks for noticing.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] snapshots differ from git clone

[Timothy Gu]

On Tue, Aug 2, 2016 at 3:10 PM Nicolas George  wrote:

> Le sextidi 16 thermidor, an CCXXIV, Jan Ehrhardt a écrit :
> > Because it is faster to download a snapshot and extract it than
> > doing a git clone
>
> I suggest you consider doing a shallow clone (--depth 1). It should take
> roughly the same time as getting and unpacking a snapshot. IIRC, one of the
> minor perks of doing that is that the version script will give a more
> useful
> version tag.
>

At least here, Git is still slower. In addition, https://git.ffmpeg.org
doesn't seem to support --depth.

$ time curl https://www.ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 | tar
-jxf -
real 0m10.331s
user 0m2.272s
sys 0m0.312s
$ git clone --depth=1 https://git.ffmpeg.org/ffmpeg.git ffmpeg2
Cloning into 'ffmpeg2'...
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header
$ time git clone --depth=1 https://github.com/FFmpeg/FFmpeg.git ffmpeg2
real 0m17.540s
user 0m1.308s
sys 0m0.308s

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] jni, mediacodec: Return ENOSYS on unsupported platforms

[Timothy Gu]

---
 libavcodec/jni.c| 9 -
 libavcodec/mediacodec.c | 6 --
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index 32456f5..85dcf2a 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -20,19 +20,18 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "config.h"
+
 #include 
 
-#include "config.h"
+#include "libavutil/error.h"
 #include "jni.h"
 
 #if CONFIG_JNI
-
-#include 
 #include 
 #include 
 
 #include "libavutil/log.h"
-#include "libavutil/error.h"
 #include "ffjni.h"
 
 void *java_vm;
@@ -69,7 +68,7 @@ void *av_jni_get_java_vm(void *log_ctx)
 
 int av_jni_set_java_vm(void *vm, void *log_ctx)
 {
-return 0;
+return AVERROR(ENOSYS);
 }
 
 void *av_jni_get_java_vm(void *log_ctx)
diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
index cd8766f..a658f0e 100644
--- a/libavcodec/mediacodec.c
+++ b/libavcodec/mediacodec.c
@@ -22,6 +22,8 @@
 
 #include "config.h"
 
+#include "libavutil/error.h"
+
 #if CONFIG_H264_MEDIACODEC_HWACCEL
 
 #include 
@@ -108,7 +110,7 @@ AVMediaCodecContext *av_mediacodec_alloc_context(void)
 
 int av_mediacodec_default_init(AVCodecContext *avctx, AVMediaCodecContext 
*ctx, void *surface)
 {
-return 0;
+return AVERROR(ENOSYS);
 }
 
 void av_mediacodec_default_free(AVCodecContext *avctx)
@@ -117,7 +119,7 @@ void av_mediacodec_default_free(AVCodecContext *avctx)
 
 int av_mediacodec_release_buffer(AVMediaCodecBuffer *buffer, int render)
 {
-return 0;
+return AVERROR(ENOSYS);
 }
 
 #endif
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] mem: Order function prototypes semantically

[Timothy Gu]

On Tue, Aug 2, 2016 at 3:13 PM Michael Niedermayer <mich...@niedermayer.cc>
wrote:

> On Sun, Jul 31, 2016 at 09:07:03PM -0700, Timothy Gu wrote:
> > ---
> >  libavutil/mem.h | 198
> 
> >  1 file changed, 99 insertions(+), 99 deletions(-)
>
> LGTM if that order is preferred
>

Thanks, pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] snapshots differ from git clone

[Timothy Gu]

On Tue, Aug 2, 2016 at 1:54 PM Jan Ehrhardt  wrote:

> I have a script that cross-compiles ffmpeg on Ubuntu for Windows.
> Because it is faster to download a snapshot and extract it than
> doing a git clone the script uses
> http://ffmpeg.org/releases/ffmpeg-snapshot-git.tar.bz2


This sounds like a bug on the snapshot server. The files you mentioned were
removed from Git in e3461197b and 9fd6ea933fa.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] jni, mediacodec: Return ENOSYS on unsupported platforms

[Timothy Gu]

---
 libavcodec/jni.c| 2 +-
 libavcodec/mediacodec.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index 32456f5..e08a185 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -69,7 +69,7 @@ void *av_jni_get_java_vm(void *log_ctx)
 
 int av_jni_set_java_vm(void *vm, void *log_ctx)
 {
-return 0;
+return AVERROR(ENOSYS);
 }
 
 void *av_jni_get_java_vm(void *log_ctx)
diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
index cd8766f..25b3dd0 100644
--- a/libavcodec/mediacodec.c
+++ b/libavcodec/mediacodec.c
@@ -108,7 +108,7 @@ AVMediaCodecContext *av_mediacodec_alloc_context(void)
 
 int av_mediacodec_default_init(AVCodecContext *avctx, AVMediaCodecContext 
*ctx, void *surface)
 {
-return 0;
+return AVERROR(ENOSYS);
 }
 
 void av_mediacodec_default_free(AVCodecContext *avctx)
@@ -117,7 +117,7 @@ void av_mediacodec_default_free(AVCodecContext *avctx)
 
 int av_mediacodec_release_buffer(AVMediaCodecBuffer *buffer, int render)
 {
-return 0;
+return AVERROR(ENOSYS);
 }
 
 #endif
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] - cosmetic: the decklink_dec* files are used for input from the decklink cards. update the header to reflect that

[Timothy Gu]

On Tue, Aug 2, 2016 at 12:51 PM Felt, Patrick 
wrote:

> That’s really odd.  Has to be something stupid from my MUA.  Let me attach
> it as a file and it should go.  (I wrote this off a brand new fresh clone).
>

Pushed, thanks.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] avcodec/bsf: Add list BSF API

[Timothy Gu]

Sorry, I seem to have lost the original mail, and as Gmane is dead I had to
review using Nicolas's mail.

On Tue, Aug 2, 2016 at 8:14 AM Nicolas George  wrote:

> Le primidi 11 thermidor, an CCXXIV, sebechlebsky...@gmail.com a écrit :
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 36f7935..39106ee 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -5949,6 +5949,80 @@ void av_bsf_free(AVBSFContext **ctx);
> >   */
> >  const AVClass *av_bsf_get_class(void);
> >
> > +/**
> > + * Structure for chain/list of bitstream filters.
> > + * Empty list can be allocated by av_bsf_list_alloc().
> > + */
> > +typedef struct AVBSFList AVBSFList;
> > +
> > +/**
> > + * Allocate empty list of bitstream filters.
> > + * The list must be later freed by av_bsf_list_free()
> > + * or finalized by av_bsf_list_finalize().
> > + *
> > + * @return pointer to AVBSFList on success, NULL in case of failure
>

For  Doxygen documentation, capitalize the first letter of the descriptions
in @return's and @param's, and @ref-erence types, structs, and enums. (For
functions, an empty set of parentheses is enough.)

The same rules apply to all the new functions you've added.

@return Pointer to @ref AVBSFList on success, NULL in case of failure.


> > + */
> > +AVBSFList *av_bsf_list_alloc(void);
> > +
> > +/**
> > + * Free list of bitstream filters.
> > + *
> > + * @param lst pointer to pointer returned by av_bsf_list_alloc()
>

@param lst Pointer to pointer returned by av_bsf_list_alloc()

> + */
> > +void av_bsf_list_free(AVBSFList **lst);
> > +
> > +/**
> > + * Append bitstream filter to the list of bitstream filters.
> > + *
>


> > + * @param lst list to append to
>

List


> > + * @param bsf AVBSFContext to be appended
>

@ref AVBSFContext


> > + *
> > + * @return >=0 on success, negative AVERROR in case of failure
> > + */
> > +int av_bsf_list_append(AVBSFList *lst, AVBSFContext *bsf);
> > +
> > +/**
> > + * Finalize list of bitstream filters.
> > + *
> > + * This function will transform AVBSFList to single AVBSFContext,
>

@ref's


> > + * so the whole chain of bitstream filters can be treated as single
> filter
> > + * freshly allocated by av_bsf_alloc().
>


> > + * The AVBSFList structure is destroyed after this call and must not
>

Ditto


> > + * be accessed.
> > + *
> > + * @param lst  AVBSFList structure to be transformed
>


> > + * @param bsf[out] pointer to be set to newly created AVBSFContext
> structure
>

@param[out] bsf

Same applies to rest of the file.


> > + * representing the chain of bitstream filters
> > + *
> > + * @return >=0 on success, negative AVERROR in case of failure
> > + */
> > +int av_bsf_list_finalize(AVBSFList **lst, AVBSFContext **bsf);
> > +
> > +/**
> > + * Parse string describing list of bitstream filters and create single
> > + * AVBSFContext describing the whole chain of bitstream filters.
> > + * Resulting AVBSFContext can be treated as any other AVBSFContext
> freshly
> > + * allocated by av_bsf_alloc().
> > + *
> > + * @param str  string describing chain of bitstream filters in
> format
>


> > + * bsf1[=opt1=val1:opt2=val2][,bsf2]
>

Use Markdown backtick syntax to make it display in monospace font

`bsf[=opt1=val1:opt2=val2][,bsf2]`


> > + * @param bsf[out] pointer to be set to newly created AVBSFContext
> structure
> > + * representing the chain of bitstream filters
> > + *
> > + * @return >=0 on success, negative AVERROR in case of failure
> > + */
> > +int av_bsf_list_parse_str(const char *str, AVBSFContext **bsf);
> > +
> > +/**
> > + * Get null/pass-through bitstream filter.
> > + *

> + * @param bsf[out] pointer to be set to new instance of pass-through
> > + * bitstream filter

> + *
> > + * @return
> > + */
> > +int av_bsf_get_null_filter(AVBSFContext **bsf);
> > +
> >  /* memory */
> >
> >  /**
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] mem: Extend and edit Doxygen

[Timothy Gu]

---

A bit more editing...

---
 libavutil/mem.h | 588 +++-
 1 file changed, 451 insertions(+), 137 deletions(-)

diff --git a/libavutil/mem.h b/libavutil/mem.h
index 145ac91..4b99342 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -20,7 +20,8 @@
 
 /**
  * @file
- * memory handling functions
+ * @ingroup lavu_mem
+ * Memory handling functions
  */
 
 #ifndef AVUTIL_MEM_H
@@ -35,9 +36,56 @@
 
 /**
  * @addtogroup lavu_mem
+ * Utilities for manipulating memory.
+ *
+ * FFmpeg has several applications of memory that are not required of a typical
+ * program. For example, the computing-heavy components like video decoding and
+ * encoding can be sped up significantly through the use of aligned memory.
+ *
+ * However, for each of FFmpeg's applications of memory, there might not be a
+ * recognized or standardized API for that specific use. Memory alignment, for
+ * instance, varies wildly depending on operating systems, architectures, and
+ * compilers. Hence, this component of @ref libavutil is created to make
+ * dealing with memory consistently possible on all platforms.
+ *
+ * @{
+ *
+ * @defgroup lavu_mem_macros Alignment Macros
+ * Helper macros for declaring aligned variables.
  * @{
  */
 
+/**
+ * @def DECLARE_ALIGNED(n,t,v)
+ * Declare a variable that is aligned in the memory.
+ *
+ * @code{.c}
+ * DECLARE_ALIGNED(16, uint16_t, aligned_int) = 42;
+ * DECLARE_ALIGNED(32, uint8_t, aligned_array)[128];
+ *
+ * // The default-alignment equivalent would be
+ * uint16_t aligned_int = 42;
+ * uint8_t aligned_array[128];
+ * @endcode
+ *
+ * @param n Minimum alignment in bytes
+ * @param t Type of the variable (or array element)
+ * @param v Name of the variable
+ */
+
+/**
+ * @def DECLARE_ASM_CONST(n,t,v)
+ * Declare a static constant aligned variable appropriate for use in inline
+ * assembly code.
+ *
+ * @code{.c}
+ * DECLARE_ASM_CONST(16, uint64_t, pw_08) = UINT64_C(0x0008000800080008);
+ * @endcode
+ *
+ * @param n Minimum alignment in bytes
+ * @param t Type of the variable (or array element)
+ * @param v Name of the variable
+ */
 
 #if defined(__INTEL_COMPILER) && __INTEL_COMPILER < 1110 || defined(__SUNPRO_C)
 #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
@@ -60,12 +108,47 @@
 #define DECLARE_ASM_CONST(n,t,v)static const t v
 #endif
 
+/**
+ * @}
+ */
+
+/**
+ * @defgroup lavu_mem_attrs Function Attributes
+ * Function attributes applicable to memory handling functions.
+ *
+ * These function attributes can help compilers emit more useful warnings, or
+ * generate better code.
+ * @{
+ */
+
+/**
+ * @def av_malloc_attrib
+ * Function attribute denoting a malloc-like function.
+ *
+ * @see https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-g_t_0040code_007bmalloc_007d-function-attribute-3251;>Function
 attribute `malloc` in GCC's documentation
+ */
+
 #if AV_GCC_VERSION_AT_LEAST(3,1)
 #define av_malloc_attrib __attribute__((__malloc__))
 #else
 #define av_malloc_attrib
 #endif
 
+/**
+ * @def av_alloc_size(...)
+ * Function attribute used on a function that allocates memory, whose size is
+ * given by the specified parameter(s).
+ *
+ * @code{.c}
+ * void *av_malloc(size_t size) av_alloc_size(1);
+ * void *av_calloc(size_t nmemb, size_t size) av_alloc_size(1, 2);
+ * @endcode
+ *
+ * @param ... One or two parameter indexes, separated by a comma
+ *
+ * @see https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-g_t_0040code_007balloc_005fsize_007d-function-attribute-3220;>Function
 attribute `alloc_size` in GCC's documentation
+ */
+
 #if AV_GCC_VERSION_AT_LEAST(4,3)
 #define av_alloc_size(...) __attribute__((alloc_size(__VA_ARGS__)))
 #else
@@ -73,31 +156,51 @@
 #endif
 
 /**
- * Allocate a block of size bytes with alignment suitable for all
- * memory accesses (including vectors if available on the CPU).
- * @param size Size in bytes for the memory block to be allocated.
- * @return Pointer to the allocated block, NULL if the block cannot
- * be allocated.
+ * @}
+ */
+
+/**
+ * @defgroup lavu_mem_funcs Heap Management
+ * Functions responsible for allocating, freeing, and copying memory.
+ *
+ * All memory allocation functions have a built-in upper limit of `INT_MAX`
+ * bytes. This may be changed with av_max_alloc(), although exercise extreme
+ * caution when doing so.
+ *
+ * @{
+ */
+
+/**
+ * Allocate a memory block with alignment suitable for all memory accesses
+ * (including vectors if available on the CPU).
+ *
+ * @param size Size in bytes for the memory block to be allocated
+ * @return Pointer to the allocated block, or `NULL` if the block cannot
+ * be allocated
  * @see av_mallocz()
  */
 void *av_malloc(size_t size) av_malloc_attrib av_alloc_size(1);
 
 /**
- * Allocate a block of size bytes with alignment suitable for all
- * memory accesses (including vectors if available on the CPU) and
- * zero all the bytes of the block.
- 

Re: [FFmpeg-devel] [PATCH] doc: add Libav merge document

[Timothy Gu]

I've put this document onto the wiki so that it's easier to edit:
https://trac.ffmpeg.org/wiki/LibavMerge

Timothy

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] build: Make API documentation depend on config.mak

[Timothy Gu]

On Sun, Jul 31, 2016 at 7:06 AM Michael Niedermayer <mich...@niedermayer.cc>
wrote:

> On Fri, Jul 29, 2016 at 10:30:37PM -0700, Timothy Gu wrote:
> > The Doxygen command is generated from the list of installed headers,
> > which may change per configuration (e.g. `--enable-gpl` results in
> > libpostproc to be built and installed).
> > ---
> >  doc/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> LGTM but please wait with applying so others who know the build
> system better have a chance to look at this
>
> thx
>

Pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] mem: Order function prototypes semantically

[Timothy Gu]

---
 libavutil/mem.h | 198 
 1 file changed, 99 insertions(+), 99 deletions(-)

diff --git a/libavutil/mem.h b/libavutil/mem.h
index 2f53b47..145ac91 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -83,6 +83,16 @@
 void *av_malloc(size_t size) av_malloc_attrib av_alloc_size(1);
 
 /**
+ * Allocate a block of size bytes with alignment suitable for all
+ * memory accesses (including vectors if available on the CPU) and
+ * zero all the bytes of the block.
+ * @param size Size in bytes for the memory block to be allocated.
+ * @return Pointer to the allocated block, NULL if it cannot be allocated.
+ * @see av_malloc()
+ */
+void *av_mallocz(size_t size) av_malloc_attrib av_alloc_size(1);
+
+/**
  * Allocate a block of size * nmemb bytes with av_malloc().
  * @param nmemb Number of elements
  * @param size Size of the single element
@@ -98,6 +108,34 @@ av_alloc_size(1, 2) static inline void 
*av_malloc_array(size_t nmemb, size_t siz
 }
 
 /**
+ * Allocate a block of size * nmemb bytes with av_mallocz().
+ * @param nmemb Number of elements
+ * @param size Size of the single element
+ * @return Pointer to the allocated block, NULL if the block cannot
+ * be allocated.
+ * @see av_mallocz()
+ * @see av_malloc_array()
+ */
+av_alloc_size(1, 2) static inline void *av_mallocz_array(size_t nmemb, size_t 
size)
+{
+if (!size || nmemb >= INT_MAX / size)
+return NULL;
+return av_mallocz(nmemb * size);
+}
+
+/**
+ * Allocate a block of nmemb * size bytes with alignment suitable for all
+ * memory accesses (including vectors if available on the CPU) and
+ * zero all the bytes of the block.
+ * The allocation will fail if nmemb * size is greater than or equal
+ * to INT_MAX.
+ * @param nmemb
+ * @param size
+ * @return Pointer to the allocated block, NULL if it cannot be allocated.
+ */
+void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
+
+/**
  * Allocate or reallocate a block of memory.
  * If ptr is NULL and size > 0, allocate a new block. If
  * size is zero, free the memory block pointed to by ptr.
@@ -119,16 +157,6 @@ void *av_realloc(void *ptr, size_t size) av_alloc_size(2);
 
 /**
  * Allocate or reallocate a block of memory.
- * This function does the same thing as av_realloc, except:
- * - It takes two arguments and checks the result of the multiplication for
- *   integer overflow.
- * - It frees the input block in case of failure, thus avoiding the memory
- *   leak with the classic "buf = realloc(buf); if (!buf) return -1;".
- */
-void *av_realloc_f(void *ptr, size_t nelem, size_t elsize);
-
-/**
- * Allocate or reallocate a block of memory.
  * If *ptr is NULL and size > 0, allocate a new block. If
  * size is zero, free the memory block pointed to by ptr.
  * @param   ptr Pointer to a pointer to a memory block already allocated
@@ -148,6 +176,16 @@ av_warn_unused_result
 int av_reallocp(void *ptr, size_t size);
 
 /**
+ * Allocate or reallocate a block of memory.
+ * This function does the same thing as av_realloc, except:
+ * - It takes two arguments and checks the result of the multiplication for
+ *   integer overflow.
+ * - It frees the input block in case of failure, thus avoiding the memory
+ *   leak with the classic "buf = realloc(buf); if (!buf) return -1;".
+ */
+void *av_realloc_f(void *ptr, size_t nelem, size_t elsize);
+
+/**
  * Allocate or reallocate an array.
  * If ptr is NULL and nmemb > 0, allocate a new block. If
  * nmemb is zero, free the memory block pointed to by ptr.
@@ -186,6 +224,42 @@ av_alloc_size(2, 3) void *av_realloc_array(void *ptr, 
size_t nmemb, size_t size)
 av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, size_t 
size);
 
 /**
+ * Reallocate the given block if it is not large enough, otherwise do nothing.
+ *
+ * @see av_realloc
+ */
+void *av_fast_realloc(void *ptr, unsigned int *size, size_t min_size);
+
+/**
+ * Allocate a buffer, reusing the given one if large enough.
+ *
+ * Contrary to av_fast_realloc the current buffer contents might not be
+ * preserved and on error the old buffer is freed, thus no special
+ * handling to avoid memleaks is necessary.
+ *
+ * @param ptr pointer to pointer to already allocated buffer, overwritten with 
pointer to new buffer
+ * @param size size of the buffer *ptr points to
+ * @param min_size minimum size of *ptr buffer after returning, *ptr will be 
NULL and
+ * *size 0 if an error occurred.
+ */
+void av_fast_malloc(void *ptr, unsigned int *size, size_t min_size);
+
+/**
+ * Allocate a buffer, reusing the given one if large enough.
+ *
+ * All newly allocated space is initially cleared
+ * Contrary to av_fast_realloc the current buffer contents might not be
+ * preserved and on error the old buffer is freed, thus no special
+ * handling to avoid memleaks is necessary.
+ *
+ * @param ptr pointer to pointer to already allocated buffer, overwritten with 
pointer to new buffer
+ * @param size size of the buffer 

[FFmpeg-devel] [PATCH 2/2] mem: Extend and edit Doxygen

[Timothy Gu]

---
 libavutil/mem.h | 539 ++--
 1 file changed, 406 insertions(+), 133 deletions(-)

diff --git a/libavutil/mem.h b/libavutil/mem.h
index 145ac91..675b11c 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -20,7 +20,8 @@
 
 /**
  * @file
- * memory handling functions
+ * @ingroup lavu_mem
+ * Memory handling functions
  */
 
 #ifndef AVUTIL_MEM_H
@@ -35,9 +36,58 @@
 
 /**
  * @addtogroup lavu_mem
+ * Utilities for manipulating memory.
+ *
+ * In modern processor architectures, misaligned memory sometimes incurs a
+ * performance penalty in execution. The x86 architecture, for example, has
+ * many vector instructions that will crash on misaligned memory. For a
+ * computing-intensive project like FFmpeg, using aligned memory is even more
+ * crucial for a high level of performance.
+ *
+ * However, there is not a universal C API for allocating and declaring aligned
+ * memory. Different operating systems, architectures, and compilers have very
+ * different defaults and behavior for memory alignment. Hence, this component
+ * of @ref libavutil is created to make dealing with memory consistently
+ * possible on all platforms.
+ *
+ * @{
+ *
+ * @defgroup lavu_mem_macros Alignment Macros
+ * Helper macros for declaring aligned variables.
  * @{
  */
 
+/**
+ * @def DECLARE_ALIGNED(n,t,v)
+ * Declare a variable that is aligned in the memory.
+ *
+ * @code{.c}
+ * DECLARE_ALIGNED(16, uint16_t, aligned_int) = 42;
+ * DECLARE_ALIGNED(32, uint8_t, aligned_array)[128];
+ *
+ * // The default-alignment equivalent would be
+ * uint16_t aligned_int = 42;
+ * uint8_t aligned_array[128];
+ * @endcode
+ *
+ * @param n Minimum alignment in bytes
+ * @param t Type of the variable (or array element)
+ * @param v Name of the variable
+ */
+
+/**
+ * @def DECLARE_ASM_CONST(n,t,v)
+ * Declare a static constant aligned variable appropriate for use in inline
+ * assembly code.
+ *
+ * @code{.c}
+ * DECLARE_ASM_CONST(16, uint64_t, pw_08) = UINT64_C(0x0008000800080008);
+ * @endcode
+ *
+ * @param n Minimum alignment in bytes
+ * @param t Type of the variable (or array element)
+ * @param v Name of the variable
+ */
 
 #if defined(__INTEL_COMPILER) && __INTEL_COMPILER < 1110 || defined(__SUNPRO_C)
 #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
@@ -60,12 +110,47 @@
 #define DECLARE_ASM_CONST(n,t,v)static const t v
 #endif
 
+/**
+ * @}
+ */
+
+/**
+ * @defgroup lavu_mem_attrs Function Attributes
+ * Function attributes applicable to memory handling functions.
+ *
+ * These function attributes can help compilers emit more useful warnings, or
+ * generate better optimized code.
+ * @{
+ */
+
+/**
+ * @def av_malloc_attrib
+ * Function attribute denoting a malloc-like function.
+ *
+ * @see https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-g_t_0040code_007bmalloc_007d-function-attribute-3251;>Function
 attribute `malloc` in GCC's documentation
+ */
+
 #if AV_GCC_VERSION_AT_LEAST(3,1)
 #define av_malloc_attrib __attribute__((__malloc__))
 #else
 #define av_malloc_attrib
 #endif
 
+/**
+ * @def av_alloc_size(...)
+ * Function attribute used on a function that allocates memory, whose size is
+ * given by the specified parameter(s).
+ *
+ * @code{.c}
+ * void *av_malloc(size_t size) av_alloc_size(1);
+ * void *av_calloc(size_t nmemb, size_t size) av_alloc_size(1, 2);
+ * @endcode
+ *
+ * @param ... One or two parameter indexes, separated by a comma
+ *
+ * @see https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-g_t_0040code_007balloc_005fsize_007d-function-attribute-3220;>Function
 attribute `alloc_size` in GCC's documentation
+ */
+
 #if AV_GCC_VERSION_AT_LEAST(4,3)
 #define av_alloc_size(...) __attribute__((alloc_size(__VA_ARGS__)))
 #else
@@ -73,31 +158,51 @@
 #endif
 
 /**
- * Allocate a block of size bytes with alignment suitable for all
- * memory accesses (including vectors if available on the CPU).
- * @param size Size in bytes for the memory block to be allocated.
- * @return Pointer to the allocated block, NULL if the block cannot
- * be allocated.
+ * @}
+ */
+
+/**
+ * @defgroup lavu_mem_funcs Heap Management
+ * Functions responsible for allocating, freeing, and copying aligned memory.
+ *
+ * All memory allocation functions have a built-in upper limit of `INT_MAX`
+ * bytes. This may be changed with av_max_alloc(), although exercise extreme
+ * caution when doing so.
+ *
+ * @{
+ */
+
+/**
+ * Allocate a memory block with alignment suitable for all memory accesses
+ * (including vectors if available on the CPU).
+ *
+ * @param size Size in bytes for the memory block to be allocated
+ * @return Pointer to the allocated block, or `NULL` if the block cannot
+ * be allocated
  * @see av_mallocz()
  */
 void *av_malloc(size_t size) av_malloc_attrib av_alloc_size(1);
 
 /**
- * Allocate a block of size bytes with alignment suitable for all
- * memory accesses (including 

Re: [FFmpeg-devel] [PATCH] mem: Make function attribute usage consistent

[Timothy Gu]

On Sun, Jul 31, 2016 at 4:56 AM Michael Niedermayer <mich...@niedermayer.cc>
wrote:

> On Sat, Jul 30, 2016 at 07:13:06PM -0700, Timothy Gu wrote:
> > ---
> >  libavutil/mem.h | 47 +--
> >  1 file changed, 37 insertions(+), 10 deletions(-)
>
> causes
> make fate-lossless-shorten
> to Abort
>

Patch dropped. This might be a GCC issue since I cannot reproduce it on gcc
(Debian 4.9.2-10) 4.9.2.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] mem: Make function attribute usage consistent

[Timothy Gu]

---
 libavutil/mem.h | 47 +--
 1 file changed, 37 insertions(+), 10 deletions(-)

diff --git a/libavutil/mem.h b/libavutil/mem.h
index 2f53b47..a6bb6b7 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -80,7 +80,9 @@
  * be allocated.
  * @see av_mallocz()
  */
-void *av_malloc(size_t size) av_malloc_attrib av_alloc_size(1);
+av_malloc_attrib
+av_alloc_size(1)
+void *av_malloc(size_t size);
 
 /**
  * Allocate a block of size * nmemb bytes with av_malloc().
@@ -90,7 +92,9 @@ void *av_malloc(size_t size) av_malloc_attrib 
av_alloc_size(1);
  * be allocated.
  * @see av_malloc()
  */
-av_alloc_size(1, 2) static inline void *av_malloc_array(size_t nmemb, size_t 
size)
+av_malloc_attrib
+av_alloc_size(1, 2)
+static inline void *av_malloc_array(size_t nmemb, size_t size)
 {
 if (!size || nmemb >= INT_MAX / size)
 return NULL;
@@ -115,7 +119,9 @@ av_alloc_size(1, 2) static inline void 
*av_malloc_array(size_t nmemb, size_t siz
  *  some libc implementations.
  * @see av_fast_realloc()
  */
-void *av_realloc(void *ptr, size_t size) av_alloc_size(2);
+av_malloc_attrib
+av_alloc_size(2)
+void *av_realloc(void *ptr, size_t size);
 
 /**
  * Allocate or reallocate a block of memory.
@@ -125,6 +131,8 @@ void *av_realloc(void *ptr, size_t size) av_alloc_size(2);
  * - It frees the input block in case of failure, thus avoiding the memory
  *   leak with the classic "buf = realloc(buf); if (!buf) return -1;".
  */
+av_malloc_attrib
+av_alloc_size(2, 3)
 void *av_realloc_f(void *ptr, size_t nelem, size_t elsize);
 
 /**
@@ -145,6 +153,7 @@ void *av_realloc_f(void *ptr, size_t nelem, size_t elsize);
  *  some libc implementations.
  */
 av_warn_unused_result
+av_alloc_size(2)
 int av_reallocp(void *ptr, size_t size);
 
 /**
@@ -164,7 +173,9 @@ int av_reallocp(void *ptr, size_t size);
  *  The situation is undefined according to POSIX and may crash with
  *  some libc implementations.
  */
-av_alloc_size(2, 3) void *av_realloc_array(void *ptr, size_t nmemb, size_t 
size);
+av_malloc_attrib
+av_alloc_size(2, 3)
+void *av_realloc_array(void *ptr, size_t nmemb, size_t size);
 
 /**
  * Allocate or reallocate an array through a pointer to a pointer.
@@ -183,7 +194,8 @@ av_alloc_size(2, 3) void *av_realloc_array(void *ptr, 
size_t nmemb, size_t size)
  *  The situation is undefined according to POSIX and may crash with
  *  some libc implementations.
  */
-av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, size_t 
size);
+av_alloc_size(2, 3)
+int av_reallocp_array(void *ptr, size_t nmemb, size_t size);
 
 /**
  * Free a memory block which has been allocated with av_malloc(z)() or
@@ -203,7 +215,9 @@ void av_free(void *ptr);
  * @return Pointer to the allocated block, NULL if it cannot be allocated.
  * @see av_malloc()
  */
-void *av_mallocz(size_t size) av_malloc_attrib av_alloc_size(1);
+av_malloc_attrib
+av_alloc_size(1)
+void *av_mallocz(size_t size);
 
 /**
  * Allocate a block of nmemb * size bytes with alignment suitable for all
@@ -215,7 +229,9 @@ void *av_mallocz(size_t size) av_malloc_attrib 
av_alloc_size(1);
  * @param size
  * @return Pointer to the allocated block, NULL if it cannot be allocated.
  */
-void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
+av_malloc_attrib
+av_alloc_size(1, 2)
+void *av_calloc(size_t nmemb, size_t size);
 
 /**
  * Allocate a block of size * nmemb bytes with av_mallocz().
@@ -226,7 +242,9 @@ void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
  * @see av_mallocz()
  * @see av_malloc_array()
  */
-av_alloc_size(1, 2) static inline void *av_mallocz_array(size_t nmemb, size_t 
size)
+av_malloc_attrib
+av_alloc_size(1, 2)
+static inline void *av_mallocz_array(size_t nmemb, size_t size)
 {
 if (!size || nmemb >= INT_MAX / size)
 return NULL;
@@ -239,7 +257,8 @@ av_alloc_size(1, 2) static inline void 
*av_mallocz_array(size_t nmemb, size_t si
  * @return Pointer to a newly-allocated string containing a
  * copy of s or NULL if the string cannot be allocated.
  */
-char *av_strdup(const char *s) av_malloc_attrib;
+av_malloc_attrib
+char *av_strdup(const char *s);
 
 /**
  * Duplicate a substring of the string s.
@@ -249,7 +268,9 @@ char *av_strdup(const char *s) av_malloc_attrib;
  * @return Pointer to a newly-allocated string containing a
  * copy of s or NULL if the string cannot be allocated.
  */
-char *av_strndup(const char *s, size_t len) av_malloc_attrib;
+av_malloc_attrib
+av_alloc_size(2)
+char *av_strndup(const char *s, size_t len);
 
 /**
  * Duplicate the buffer p.
@@ -257,6 +278,8 @@ char *av_strndup(const char *s, size_t len) 
av_malloc_attrib;
  * @return Pointer to a newly allocated buffer containing a
  * copy of p or NULL if the buffer cannot be allocated.
  */
+av_malloc_attrib
+av_alloc_size(2)
 void *av_memdup(const void *p, size_t size);
 
 /**
@@ -368,6 +391,8 @@ void av_memcpy_backptr(uint8_t *dst, int back, int 

[FFmpeg-devel] [PATCH 1/2] build: Make API documentation depend on config.mak

[Timothy Gu]

The Doxygen command is generated from the list of installed headers,
which may change per configuration (e.g. `--enable-gpl` results in
libpostproc to be built and installed).
---
 doc/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/Makefile b/doc/Makefile
index 4a77aac..c90cb1a 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -125,7 +125,7 @@ $(DOC_EXAMPLES:%$(EXESUF)=%.o): | doc/examples
 OBJDIRS += doc/examples
 
 DOXY_INPUT  = $(INSTHEADERS) $(DOC_EXAMPLES:%$(EXESUF)=%.c) 
$(LIB_EXAMPLES:%$(EXESUF)=%.c)
-DOXY_INPUT_DEPS = $(addprefix $(SRC_PATH)/, $(DOXY_INPUT))
+DOXY_INPUT_DEPS = $(addprefix $(SRC_PATH)/, $(DOXY_INPUT)) config.mak
 
 doc/doxy/html: TAG = DOXY
 doc/doxy/html: $(SRC_PATH)/doc/Doxyfile $(SRC_PATH)/doc/doxy-wrapper.sh 
$(DOXY_INPUT_DEPS)
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] mem: Make function attribute usage consisten

[Timothy Gu]

---
 libavutil/mem.h | 42 +++---
 1 file changed, 27 insertions(+), 15 deletions(-)

diff --git a/libavutil/mem.h b/libavutil/mem.h
index 2f53b47..ca936e8 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -80,7 +80,8 @@
  * be allocated.
  * @see av_mallocz()
  */
-void *av_malloc(size_t size) av_malloc_attrib av_alloc_size(1);
+av_malloc_attrib
+void *av_malloc(size_t size) av_alloc_size(1);
 
 /**
  * Allocate a block of size * nmemb bytes with av_malloc().
@@ -90,7 +91,8 @@ void *av_malloc(size_t size) av_malloc_attrib 
av_alloc_size(1);
  * be allocated.
  * @see av_malloc()
  */
-av_alloc_size(1, 2) static inline void *av_malloc_array(size_t nmemb, size_t 
size)
+av_malloc_attrib
+static inline void *av_malloc_array(size_t nmemb, size_t size) 
av_alloc_size(1, 2)
 {
 if (!size || nmemb >= INT_MAX / size)
 return NULL;
@@ -115,6 +117,7 @@ av_alloc_size(1, 2) static inline void 
*av_malloc_array(size_t nmemb, size_t siz
  *  some libc implementations.
  * @see av_fast_realloc()
  */
+av_malloc_attrib
 void *av_realloc(void *ptr, size_t size) av_alloc_size(2);
 
 /**
@@ -125,7 +128,8 @@ void *av_realloc(void *ptr, size_t size) av_alloc_size(2);
  * - It frees the input block in case of failure, thus avoiding the memory
  *   leak with the classic "buf = realloc(buf); if (!buf) return -1;".
  */
-void *av_realloc_f(void *ptr, size_t nelem, size_t elsize);
+av_malloc_attrib
+void *av_realloc_f(void *ptr, size_t nelem, size_t elsize) av_alloc_size(2, 3);
 
 /**
  * Allocate or reallocate a block of memory.
@@ -145,7 +149,7 @@ void *av_realloc_f(void *ptr, size_t nelem, size_t elsize);
  *  some libc implementations.
  */
 av_warn_unused_result
-int av_reallocp(void *ptr, size_t size);
+int av_reallocp(void *ptr, size_t size) av_alloc_size(2);
 
 /**
  * Allocate or reallocate an array.
@@ -164,7 +168,8 @@ int av_reallocp(void *ptr, size_t size);
  *  The situation is undefined according to POSIX and may crash with
  *  some libc implementations.
  */
-av_alloc_size(2, 3) void *av_realloc_array(void *ptr, size_t nmemb, size_t 
size);
+av_malloc_attrib
+void *av_realloc_array(void *ptr, size_t nmemb, size_t size) av_alloc_size(2, 
3);
 
 /**
  * Allocate or reallocate an array through a pointer to a pointer.
@@ -183,7 +188,7 @@ av_alloc_size(2, 3) void *av_realloc_array(void *ptr, 
size_t nmemb, size_t size)
  *  The situation is undefined according to POSIX and may crash with
  *  some libc implementations.
  */
-av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, size_t 
size);
+int av_reallocp_array(void *ptr, size_t nmemb, size_t size) av_alloc_size(2, 
3);
 
 /**
  * Free a memory block which has been allocated with av_malloc(z)() or
@@ -203,7 +208,8 @@ void av_free(void *ptr);
  * @return Pointer to the allocated block, NULL if it cannot be allocated.
  * @see av_malloc()
  */
-void *av_mallocz(size_t size) av_malloc_attrib av_alloc_size(1);
+av_malloc_attrib
+void *av_mallocz(size_t size) av_alloc_size(1);
 
 /**
  * Allocate a block of nmemb * size bytes with alignment suitable for all
@@ -215,7 +221,8 @@ void *av_mallocz(size_t size) av_malloc_attrib 
av_alloc_size(1);
  * @param size
  * @return Pointer to the allocated block, NULL if it cannot be allocated.
  */
-void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
+av_malloc_attrib
+void *av_calloc(size_t nmemb, size_t size) av_alloc_size(1, 2);
 
 /**
  * Allocate a block of size * nmemb bytes with av_mallocz().
@@ -226,7 +233,8 @@ void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
  * @see av_mallocz()
  * @see av_malloc_array()
  */
-av_alloc_size(1, 2) static inline void *av_mallocz_array(size_t nmemb, size_t 
size)
+av_malloc_attrib
+static inline void *av_mallocz_array(size_t nmemb, size_t size) 
av_alloc_size(1, 2)
 {
 if (!size || nmemb >= INT_MAX / size)
 return NULL;
@@ -239,7 +247,8 @@ av_alloc_size(1, 2) static inline void 
*av_mallocz_array(size_t nmemb, size_t si
  * @return Pointer to a newly-allocated string containing a
  * copy of s or NULL if the string cannot be allocated.
  */
-char *av_strdup(const char *s) av_malloc_attrib;
+av_malloc_attrib
+char *av_strdup(const char *s);
 
 /**
  * Duplicate a substring of the string s.
@@ -249,7 +258,8 @@ char *av_strdup(const char *s) av_malloc_attrib;
  * @return Pointer to a newly-allocated string containing a
  * copy of s or NULL if the string cannot be allocated.
  */
-char *av_strndup(const char *s, size_t len) av_malloc_attrib;
+av_malloc_attrib
+char *av_strndup(const char *s, size_t len) av_alloc_size(2);
 
 /**
  * Duplicate the buffer p.
@@ -257,7 +267,8 @@ char *av_strndup(const char *s, size_t len) 
av_malloc_attrib;
  * @return Pointer to a newly allocated buffer containing a
  * copy of p or NULL if the buffer cannot be allocated.
  */
-void *av_memdup(const void *p, size_t size);
+av_malloc_attrib
+void *av_memdup(const void 

[FFmpeg-devel] [PATCH] dynarray: Change AV_ to FF_ for AV_DYNARRAY_ADD

[Timothy Gu]

The header is not installed and the macro isn't used outside libavutil,
so it is obviously privat to libavutil. Make the name reflect that.
---
 libavutil/dynarray.h | 2 +-
 libavutil/mem.c  | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavutil/dynarray.h b/libavutil/dynarray.h
index 4947d93..034a9fe 100644
--- a/libavutil/dynarray.h
+++ b/libavutil/dynarray.h
@@ -42,7 +42,7 @@
  * array and size are not changed; the statement can end
  * with a return or a goto
  */
-#define AV_DYNARRAY_ADD(av_size_max, av_elt_size, av_array, av_size, \
+#define FF_DYNARRAY_ADD(av_size_max, av_elt_size, av_array, av_size, \
 av_success, av_failure) \
 do { \
 size_t av_size_new = (av_size); \
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 809ec01..1a8fc21 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -312,7 +312,7 @@ int av_dynarray_add_nofree(void *tab_ptr, int *nb_ptr, void 
*elem)
 void **tab;
 memcpy(, tab_ptr, sizeof(tab));
 
-AV_DYNARRAY_ADD(INT_MAX, sizeof(*tab), tab, *nb_ptr, {
+FF_DYNARRAY_ADD(INT_MAX, sizeof(*tab), tab, *nb_ptr, {
 tab[*nb_ptr] = elem;
 memcpy(tab_ptr, , sizeof(tab));
 }, {
@@ -326,7 +326,7 @@ void av_dynarray_add(void *tab_ptr, int *nb_ptr, void *elem)
 void **tab;
 memcpy(, tab_ptr, sizeof(tab));
 
-AV_DYNARRAY_ADD(INT_MAX, sizeof(*tab), tab, *nb_ptr, {
+FF_DYNARRAY_ADD(INT_MAX, sizeof(*tab), tab, *nb_ptr, {
 tab[*nb_ptr] = elem;
 memcpy(tab_ptr, , sizeof(tab));
 }, {
@@ -340,7 +340,7 @@ void *av_dynarray2_add(void **tab_ptr, int *nb_ptr, size_t 
elem_size,
 {
 uint8_t *tab_elem_data = NULL;
 
-AV_DYNARRAY_ADD(INT_MAX, elem_size, *tab_ptr, *nb_ptr, {
+FF_DYNARRAY_ADD(INT_MAX, elem_size, *tab_ptr, *nb_ptr, {
 tab_elem_data = (uint8_t *)*tab_ptr + (*nb_ptr) * elem_size;
 if (elem_data)
 memcpy(tab_elem_data, elem_data, elem_size);
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hapdec: remove unused memory.h include

[Timothy Gu]

On Thu, Jul 28, 2016 at 6:11 PM Josh de Kock  wrote:

> Most systems have this, so it isn't really a problem to include it
> even if it's not used, but some do not have memory.h as it is
> non-standard. Since it's unused just remove it anyway.
> ---
>  libavcodec/hapdec.c | 1 -
>  1 file changed, 1 deletion(-)
>

Looks good to me. For what it's worth, the include was added in
commit 3ee217853a6741b829a2683f49c590618891b1ab, and looks like a stray
change.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mpegtsenc: add special case for handling timed ID3 packets

[Timothy Gu]

On Thu, May 19, 2016 at 1:23 PM Michael Niedermayer 
wrote:

> On Thu, May 19, 2016 at 06:45:41PM +0200, Stefano Sabatini wrote:
> > Set the stream_id to 0xbd (private_stream_id_1). Tools seem to assume
> > that value, and this is consistent with MPEG TS (ITU-T H.222.0) section
> > 2.12.3.
> > ---
> >  libavformat/mpegtsenc.c | 3 +++
> >  1 file changed, 3 insertions(+)
>
> should be ok
>

Any reason why this was held back?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Timothy Gu]

Hi,

On Mon, Mar 28, 2016 at 03:39:22PM +0200, Michael Niedermayer wrote:
> On Mon, Mar 28, 2016 at 12:34:05PM +, Kieran Kunhya wrote:
> > On Mon, 28 Mar 2016 at 11:58 Moritz Barsnick  wrote:
> > 
> > > On Mon, Mar 28, 2016 at 02:18:32 +0200, Michael Niedermayer wrote:
> > > > +it is malice its rarely good to start with that as initial assumption.
> > >^
> > >, it's
> > >
> > > > +The goal of Software development is to create technical excellence, not
> > > for any
> > >^ s
> > >
> > >
> > Let's compare this to the VLC code of conduct:
> > https://wiki.videolan.org/Code_of_Conduct/
> > 
> > Note how it has a list of specific violations, instead of vague things like
> > "Be excellent" that the FFmpeg one has.
> > Note how it has a huge section on disciplinary procedures.
> 
> i dont mind at all to be more specific, do people want a more specific
> list similar to vlc ?
> I thought it wasnt neccessary to write it as a strict "law" as if
> theres a nation of criminals that needs precissely worded laws.
> But rather a nation of good meaning people who all want to work
> together.

I have to agree with Kieran here. I believe that as a community, we definitely
_want_ to assume good faith, etc. But conflict resolution requires strict,
codified consequences for violations of the CoC, to ensure fairness. The
language needs to be made more serious so that people actually take it in the
way it is intended.

In addition to VLC, many other popular open-source guidelines, such as:

- Citizen Code of Conduct: http://citizencodeofconduct.org/
- Contributor Covenant: http://contributor-covenant.org/version/1/4/
- Node.js: https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md
- Ruby: https://www.ruby-lang.org/en/conduct/
- etc.

all have consequences of unwelcomed behavior and/or a specific definition of
an unwelcomed behavior.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Vote] Code of Conduct

[Timothy Gu]

On Wed, May 18, 2016 at 08:40:07PM +0200, Michael Niedermayer wrote:
> This is the version i had in my pending branch and should be the last 
> version of the Code of Conduct from march, IIRC there where no further 
> comments on the last version, so iam calling everyone to vote on this.
> Everyone because it should be binding to everyone.
> 
> Kieran and Thilo asked for a formal vote and i agree that this needs
> a vote.

What are we looking for? A unanimous vote? ⅔ majority? ½? A vote can't be
formal if such basic mechanism is not defined.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9

[Timothy Gu]

On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote:
>
> Just to document it, this has caused build breakage in various
> scenarios, even in GCC 5.3 (6.1 not tested).
> 
> The latest reported on IRC just today here:
> libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
> libavcodec/sbrdsp.c:47:13: internal compiler error: in
> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
>  static void sbr_neg_odd_64_c(float *x)
> 
> There are various other cases which usually involve inline asm when
> building with SIMD (ie. --cpu=host) and the optimizer running out of
> registers, for example:
> libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints
> 
> IMHO this feature is not quite ready to be enabled unconditionally in
> our code base, and we should re-evaluate this change.

I don't have a problem with reverting this commit, but as James mentioned I do
prefer the bug to be reported to GCC if possible.

Have you also considered the possibility to enable this feature only if inline
assembly is not enabled?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

On Mon, Apr 04, 2016 at 06:06:28PM -0400, Aaron Boxer wrote:
> I could  give you an OS image that has a version of FFmpeg that uses
> proprietary codecs.

Aside from Carl's comment, please define "proprietary codecs." Proprietary
codecs have different licenses, just like how both ISC and GNU AGPL are
"open-source" licenses.

In fact, let me list out all the possibilities for such a "proprietary codec"
you can possibly talk about:

- cuda: No OS I know distribute CUDA by default. Not even Ubuntu.
- faac: Ditto.
- nvenc: Ditto.
- fdk-aac: The OS can distribute it legally if GPL is not enabled.
- openssl: Ditto.

Some other proprietary libraries not listed here do not need
"--enabled-nonfree" since they are system libraries (explicitly excluded in
GPL), and are irrelevant to this discussion.

> If you run it without knowing and without paying license, then you have a
> similar problem.

False. For all the libraries above, running alone does not pose any problems
with licensing.

cuda: "2.1  Rights and Limitations of Grant.  NVIDIA hereby grants Customer
the following non-exclusive, non-transferable right to use the SOFTWARE, with
the following limitations:" 2.1.1 says users cannot copy NVIDIA products.
2.1.2 gives an additional permission for Linux users. 2.1.3 concerns reverse
engineering, separation of components, and rentals.

faac: "ISO/IEC gives users of the MPEG-2 NBC/MPEG-4 Audio standards free
license to this software module or modifications thereof for use in hardware
or software products claiming conformance to the MPEG-2 NBC/ MPEG-4 Audio
standards."

nvenc: "Subject to Licensee’s compliance with the terms of this Agreement,
NVIDIA grants to Licensee a nonexclusive, non-transferable, worldwide,
royalty-free, fully paid-up license and right to install, use, reproduce,
display, perform, modify the Source Code of the Software" Limitations do not
include running.

fdk-aac: "Redistribution and use in source and binary forms, with or without
modification, are permitted without payment of copyright license fees provided
that you satisfy the following conditions" For the five conditions that
follow, 1, 2, and 4 concern only redistribution, and 3 and 5 concern only
documentation and advertising.

openssl: The clauses that makes OpenSSL GPL-incompatible are about
advertising.

> Should we then ban closed source codecs from FFmpeg?

No. Why ban them if it's perfectly legal to run them?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

Hi,

On Mon, Apr 04, 2016 at 03:54:11PM -0400, Aaron Boxer wrote:
> >
> > >
> > > The following changes were made:
> > >
> > > 1. Removed bpp (redundant as this information is already stored in
> > precision)
> >
> > Does compilation still work without this change?
> >
> 
> Yes.

Then the change is unrelated, and either needs to be in a separate patch or
not commited at all.

> >
> > Does the compilation of OpenJPEG break _now_ without the patch? If so,
> > submit
> > a bug report, if not, then this change merits further discussion.
> >
> 
> Compilation against OpenJPEG master is broken, but everything works with
> the latest release
> of OpenJPEG (2.1)

Would be great if you post the compilation log and file a ticket.

> >
> > If there isn't a way to detect Grok from OpenJPEG, there should be one.
> >
> > If it is not clear to you why we are so against AGPL, it is because it
> > incurs
> > additional restrictions on the work that we don't consider to be in the
> > spirit
> > of free software, regardless of what FSF says. But I think you already know
> > about that.
> >
> 
> Why do you consider it to not be in the spirit of free software?
> So far, nobody has given me a convincing argument against the use of  the
> AGPL.

I believe most members of the FFmpeg community consider free software the same
way Linus Torvalds (among others) considers it: share the
sources/modifications if you are distributing them, and do whatever you want
with it if you are not.

We have no problem whatsoever with the entities using FFmpeg on their server
without distributing the binaries or releasing their sources, or tivoization
(which is a related, but different issue). Sure, it's better if they submit
the patches, and we think that they are missing out by not submitting them,
but we don't have any problems with it.

We do have a problem with the people that are preventing others from using the
software under the aforementioned legitimate circumstances. For existing
non-free software, we really don't have a choice, and it is clear to the user
that such a copy of FFmpeg is non-free. But licenses like AGPL which claim it
is "free" but fail our criteria of freedom are deemed to be "evil." In fact,
AGPL is much more restrictive than most non-free licenses we deal with, since
it concerns use in addition to distribution (see also Reimar's comments).

Moving forward, thanks to the explicit GPL compatibility shoehorned into
Chapter 13 of AGPLv3, there isn't anything that makes us license our _own
work_ as AGPL simply because FFmpeg binary is linked to an AGPL work (in fact,
we cannot relicense our own code from LGPL to AGPLv3 like we can from LGPL to
GPL). But using such a resultant mixture of licenses isn't something we want
our users, personal or enterprise, to deal with.

And that is why we are making more fuss about AGPL than most non-free
libraries.

Timothy

P.S. I am not a lawyer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:

> From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> From: Aaron Boxer 
> Date: Sun, 27 Mar 2016 00:15:20 -0400

> Subject: [PATCH] Support the following jpeg 2000 codecs:
> 
> a) latest release of openjpeg (2.1)
> b) master branch of openjpeg
> c) grok (https://github.com/GrokImageCompression/grok)

The commit message should be changed to:

build: Support additional OpenJPEG-compatible libraries

Support OpenJPEG 2.1, master, as well as Grok.

> 
> The following changes were made:
> 
> 1. Removed bpp (redundant as this information is already stored in precision)

Does compilation still work without this change?

> 2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and in
> grok, this flag indicates a static build, so codec API functions are marked
> as hidden. This prevents FFmpeg from using a dynamic build of these codecs.

This will break Windows DLL MinGW support. See
https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/openjpeg.h#L79-L108.
When Windows is used and OPJ_STATIC is not defined, __declspec(dllimport) is 
used, which asks GCC to mangle
the symbol name when compiling. However, under MinGW environment, such
mangling doesn't work, since the DLL is all that is needed for linking under
MinGW.

Does the compilation of OpenJPEG break _now_ without the patch? If so, submit
a bug report, if not, then this change merits further discussion.

> 3. link to libdl. This is needed by grok, as it supports a plugin
> architecture that allows plugins to be dynamically loaded at runtime.

Is there a way to detect Grok? Linking to a library that is unnecessary for a
specific case doesn't sound appealing to me.

Also it should be made clear that if Grok is linked into FFmpeg, the resulting
binary is a mixture of AGPL and GPL works. If --enable-gpl or
--enable-version3 is not enabled, the compilation should fail.

If there isn't a way to detect Grok from OpenJPEG, there should be one.

If it is not clear to you why we are so against AGPL, it is because it incurs
additional restrictions on the work that we don't consider to be in the spirit
of free software, regardless of what FSF says. But I think you already know
about that.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] version.sh: Add next release to the version

[Timothy Gu]

Also make consistent the fallback versions.

This patch uses a RELEASE-based approach rather than a tag-based one.
There are several reasons for this. First, the -dev tags never convey
more information than RELEASE. Second, RELEASE can provide a version
even without Git.

The new script is designed to be fairly robust, tested under a plethora
of conditions.
---
 RELEASE|  2 +-
 version.sh | 50 +++---
 2 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/RELEASE b/RELEASE
index b889d20..f25eb1f 100644
--- a/RELEASE
+++ b/RELEASE
@@ -1 +1 @@
-3.0.git
+n3.1-master
diff --git a/version.sh b/version.sh
index c46aec5..e92c811 100755
--- a/version.sh
+++ b/version.sh
@@ -4,42 +4,54 @@
 
 export GIT_DIR="$1/.git"
 
-# check for git short hash
+# Check version using git describe.
 if ! test "$revision"; then
-if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then
+if (cd "$1" && grep -q master RELEASE); then
+# If we are not in a release branch, use the N-based
+# revision.
 revision=$(git describe --tags --match N 2> /dev/null)
 else
-revision=$(git describe --tags --always 2> /dev/null)
+# Check if there is a tag on this commit.
+test "$version" || version=$(git describe --tags --exact-match 2> 
/dev/null)
+
+# If not, use git describe to find delta from latest tag
+# as the revision.
+revision=$(git describe --tags 2> /dev/null | cut -d- -f2-)
 fi
 fi
 
 # Shallow Git clones (--depth) do not have the N tag:
-# use 'git--MM-DD-hhh'.
-test "$revision" || revision=$(
-  git log -1 --pretty=format:"git-%cd-%h" --date=short 2> /dev/null)
+# use 'ghhh'.
+if ! test "$revision"; then
+revision=$(git log -1 --pretty=format:"%h" 2> /dev/null)
+test "$revision" && revision=g$revision
+fi
 
 # Snapshots from gitweb are in a directory called ffmpeg-hhh or
 # ffmpeg-HEAD-hhh.
 if [ -z "$revision" ]; then
-  srcdir=$(cd "$1" && pwd)
-  case "$srcdir" in
-*/ffmpeg-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])
-  git_hash="${srcdir##*-}";;
-*/ffmpeg-HEAD-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])
-  git_hash="${srcdir##*-}";;
-  esac
+srcdir=$(cd "$1" && pwd)
+case "$srcdir" in
+*/ffmpeg-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])
+revision="g${srcdir##*-}";;
+*/ffmpeg-HEAD-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])
+revision="g${srcdir##*-}";;
+esac
 fi
 
-# no revision number found
-test "$revision" || revision=$(cd "$1" && cat RELEASE 2> /dev/null)
+# If we have a revision prepend it with a hyphen.
+test "$revision" && revision="-$revision"
+
+# Prepend RELEASE.
+revision=$(cat "$1/RELEASE" | cut -d- -f1)-dev$revision
 
-# Append the Git hash if we have one
-test "$revision" && test "$git_hash" && revision="$revision-$git_hash"
+# Check if this is a release through the VERSION file
+test "$version" || version=$(cd "$1" && cat VERSION 2> /dev/null)
 
-# releases extract the version number from the VERSION file
-version=$(cd "$1" && cat VERSION 2> /dev/null)
+# If not a release, use the revision.
 test "$version" || version=$revision
 
+# Append any extra version string.
 test -n "$3" && version=$version-$3
 
 if [ -z "$2" ]; then
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/2] New versioning (was: version.sh: Always use latest tag for generated version number)

[Timothy Gu]

This patch set implements the versioning algorithm I recently proposed.
The first patch addresses an already existing problem with version.sh.
The second is the one actually implementing the change.

To Michael and all release makers: after this patchset when making a
release in a release branch, please do ALL of the following in the
following order.

1. cp RELEASE VERSION
2. git add VERSION
3. Update doc/Doxyfile and Changelog
4. git commit -a -m "Update for $(cat VERSION)"
5. git tag -a -m "Release $(cat VERSION)"
6. Edit RELEASE to make it contain next version
7. git rm VERSION
8. git commit -a -m "Next release is $(cat RELEASE)"

The differences to before is that, first, rather than updating RELEASE
right before a release, it must be updated after the release is made;
second, VERSION must be checked in at the tag, and removed immediately
after the release is made.

When a release branch is cut, do the following

1. Remove "-master" in RELEASE
2. git commit -a -m "Next release is $(cat RELEASE)"

Timothy Gu (2):
  version.sh: Fix Git directory
  version.sh: Add next release to the version

 RELEASE|  2 +-
 version.sh | 54 ++
 2 files changed, 35 insertions(+), 21 deletions(-)

--
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] version.sh: Fix Git directory

[Timothy Gu]

This is necessary for cases where the FFmpeg directory does not have Git
metadata but the parent directories do. See e.g.
https://github.com/mxe/mxe/issues/1219.
---
 version.sh | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/version.sh b/version.sh
index a9d7e39..c46aec5 100755
--- a/version.sh
+++ b/version.sh
@@ -2,18 +2,20 @@
 
 # Usage: version.sh   
 
+export GIT_DIR="$1/.git"
+
 # check for git short hash
 if ! test "$revision"; then
 if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then
-revision=$(cd "$1" && git describe --tags --match N 2> /dev/null)
+revision=$(git describe --tags --match N 2> /dev/null)
 else
-revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
+revision=$(git describe --tags --always 2> /dev/null)
 fi
 fi
 
 # Shallow Git clones (--depth) do not have the N tag:
 # use 'git--MM-DD-hhh'.
-test "$revision" || revision=$(cd "$1" &&
+test "$revision" || revision=$(
   git log -1 --pretty=format:"git-%cd-%h" --date=short 2> /dev/null)
 
 # Snapshots from gitweb are in a directory called ffmpeg-hhh or
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 08:46:42PM +0100, Reimar Döffinger wrote:
> On 04.03.2016, at 11:24, Nicolas George  wrote:
> 
> > The Git (short) hash carries all the information by itself, so it should be
> > present. But extra, redundant, information can be added for the convenience
> > of users and "supporters".
> > 
> > Basically, the version could be something like
> > "g510046c:N78879-3.0master417-H20160303":
> 
> The formatting is rather ugly but I'd be in favour of something like that.
> An attempt to order the information in increasing detail might be:
> v3.0+417-D20160303-N78879-g510046c
> Note that I'm not convinced the git describe info/branch info/number of
> commits since release is all that useful, but the base release version
> number seems nice to have.

I agree.

> Particularly the branch name can easily be misleading as it can be anyone's
> master, not necessarily the one on ffmpeg.org.

Indeed.

->8--

So after all the email exchanges, I think there are certain things that our
version SHOULD contain:

- The hash
- The next release (i.e. n3.1)
- A way to compare two versions

The date is considered to be "good" but perhaps not as necessary.

So here I propose the following for the master branch:

n3.1-dev-N-78911-gf81c81c
   /  |  \  \
 /|   \\
  next  distinguish commits since  commit
release from actual the start ofhash
  release   time

For comparison, versions on the release branch are as follows:

n3.0-4-geb46065
/| \
  /   \  \
previous commits since  commit
release  that releasehash

A few reasons why I chose this style for master branch rather than some other:

- I want it to bear some resemblance to our original style
   - which also happens to satisfy Carl's perhaps unjustified dependency on it
- I want it to be somewhat consistent with our release branch version
- It should also be gitrevisions(7)-compatible

I would also like to raise an awareness of versioning when full Git metadata
is not available. version.sh tries its best to get information, and usually
ends up with one of the following circumstances. However, the format is wildly
inconsistent, and I want to fix this once and for all.

I can utilize the RELEASE file to provide information on our next release,
even when tags are unavailable.

   : Current: New
Master
Full   : N-78911-gf81c81c   : n3.1-dev-N-78911-gf81c81c
Shallow clone  : git-2016-03-04-f81c81c : n3.1-dev-gf81c81c
Gitweb tarball : 3.0.git-f81c81c: n3.1-dev-gf81c81c
Nothing: 3.0.git: n3.1-dev

Release branch
Full   : n3.0-4-geb46065: n3.0.1-dev-4-geb46065
Shallow clone  : eb46065: n3.0.1-dev-geb56065
Nothing: 3.0: n3.0.1-dev

Release
Full   : n3.0   : n3.0
Shallow clone  : n3.0   : n3.0
Nothing: 3.0: n3.0

Any objections?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 06:48:04PM +0100, Thilo Borgmann wrote:
> Am 04.03.16 um 17:57 schrieb Timothy Gu:
> > On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
> >> Am 04.03.16 um 08:58 schrieb wm4:
> >>>
> >>> Being able to see the, well, version in the version output (instead of
> >>> random numbers) sounds like a pretty convincing argument.
> >>
> >> Neither a good play on words nor elaborative; not even helpful.
> >>
> >> You say they are random numbers, CE says it is continuous. What is correct?
> > 
> > It is continuous. But to the user's eye, N-71234 is no different from 
> > N-41234,
> > and hence "random."
> 
> I assume that if there is no difference in the user's eye between
> N-71234 and N-41234 then there is also no difference for that user
> between dev-123 and dev-346.

That's not the point. The point is that there is something before the dev
part, and that's what makes the difference.

When I said "no different," I meant except the fact that N-71234 is obviously
newer. The fact that it fails to convey any additional information is the
issue we are trying to attack.

> 
> 
> >> So what about the release tag? Well it is a quite useful extension because 
> >> of
> >> the already mentioned possibility of determining the existing features at 
> >> once.
> >> I'm pro adding it to the version string.
> >>
> >> The tag-tag? (devxy) I don't see it anywhere except in git and therefore 
> >> it is
> >> uselessly redundant to the existing hash tag in my eyes. Why add another 
> >> more
> >> roughly estimation of the users repo-state? I don't think this should be 
> >> added
> >> to the version string.
> > 
> > Can you elaborate on this? I am not sure I understand everything you are
> > saying. Specfically, what is "devxy"?
> 
> The core concern about it is that is just redundant. I assume Timo to be
> correct about:
> 
> "A new dev tag is made every time a release is branched off, to indicate
> development of the next ffmpeg version started there, ..."
> 
> Then there is no gain of information in the dev-123 tag if there is
> already the release number given. In that case "v4.5-gdeabdef" tells me
> the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the
> can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough.
> 
> Summing it all up for me, I think a release prefix would make perfect
> sense. Thus, switching from
> 
> N-12345-abcdefg
> 
> to
> 
> v4.5-N-12345-abcdefg
> 
> should be done for the sake of the users. There is at least CE wanting
> to stick with N-tags so why not? The only reason I can imagine for
> getting rid of N-tags and/or including dev-123 tags would be that a
> native git show command needs it to work properly as well as giving
> better human readable information.

I see where you are coming from. I will address this issue in my reply to
Reimar.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 10:20:09AM +, Carl Eugen Hoyos wrote:
> Timo Rothenpieler  rothenpieler.org> writes:
> 
> > The current versioning scheme is indeed simple, but 
> > useless in almost all other aspects.
> 
> FFmpeg has a linear development scheme, how can you call 
> a continuous versioning scheme useless? It reflects 1:1 
> on how FFmpeg is developed.

1. FFmpeg does NOT have a linear development scheme. See `git log --merges`.
2. FFmpeg uses Git, which is inherently distributed and nonlinear.

Therefore your argument again is flawed.

> 
> > It gives no indication about what release it is close to
> 
> But the development here is not release-driven (note that 
> I am not saying it should or shouldn't be, I am just 
> describing how it does work for more than a decade), 
> just look at how the latest release was made: A random 
> snapshot was chosen, not even current known possible 
> security issues or regressions were relevant.

As I have said in my reply to your last mail, and as I will do so again,
whether or not release-driven FFmpeg is irrelevant to this conversation. The
versioning scheme is supposed to make people's life easier. It is NOT designed
to be the epitome of FFmpeg development policies.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 11:24:31AM +0100, Nicolas George wrote:
> Basically, the version could be something like
> "g510046c:N78879-3.0master417-H20160303":

One object that can be raised against this is that the current versioning and
the new versioning are both compatible with Git. Try

git show n3.1-dev-400-g3af71ac
git show N-78863-g3af71ac

But since the Git hash is already appended I don't see too much problem with
that.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
> Am 04.03.16 um 08:58 schrieb wm4:
> > 
> > Being able to see the, well, version in the version output (instead of
> > random numbers) sounds like a pretty convincing argument.
> 
> Neither a good play on words nor elaborative; not even helpful.
> 
> You say they are random numbers, CE says it is continuous. What is correct?

It is continuous. But to the user's eye, N-71234 is no different from N-41234,
and hence "random."

> 
> Let's assume the N-tag is not random, then it is a useful extension of the
> pinpointing short hash, since the hashes are not relative to each other (so to
> speak random for the human eye) and therefore the N-tags are useful for
> determining if the user is ahead or behind a certain commit. According to what
> CE says, this helps for user support, Not? And if not, why would someone
> spending most of the time helping users think otherwise?

However, you miss the point that the new system allows one to do the same.

In the old system:

N-90001-gdeadbef
N-9-gdeadbee
N-8-gdeadbed

In the new system:

v4.5-dev-123-gdeadbef
v4.5-dev-122-gdeadbee
v4.0-dev-45-gdeadbed

As you can see, they are functionally equivalent: you can immediately tell
that they are in descending order with both systems.

> Assuming my thoughts are not based on void assumptions, I'm against removing 
> the
> N-tag from the version string.

I hope I have demonstrated that your concern is mistaken.

> So what about the release tag? Well it is a quite useful extension because of
> the already mentioned possibility of determining the existing features at 
> once.
> I'm pro adding it to the version string.
> 
> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
> uselessly redundant to the existing hash tag in my eyes. Why add another more
> roughly estimation of the users repo-state? I don't think this should be added
> to the version string.

Can you elaborate on this? I am not sure I understand everything you are
saying. Specfically, what is "devxy"?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc.c Fix H264 and HEVC vui info update

[Timothy Gu]

On Fri, Mar 04, 2016 at 12:45:47PM +0800, Agatha Hu wrote:
> ---
>  libavcodec/nvenc.c | 33 -
>  1 file changed, 28 insertions(+), 5 deletions(-)

This patched is corrupted by your mail client. What's wrong with the first
patch you sent (with git-send-email)?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 12:55:35AM +, Carl Eugen Hoyos wrote:
> Timothy Gu  gmail.com> writes:
> 
> > Of course, this argument operates on the premise that 
> > making things easier for users is of utmost concern 
> > for us. Please inspire me if this is not the case.
> 
> On the contrary, I believe while the current versioing 
> scheme is simple and understandable, the suggested one 
> is misleading, both for users and when reading user 
> questions.

English is not my first language, so I might well have misunderstood. But by
using the phrase "on the contrary" are you claiming that we should not regard
users' opinions as our most important concern?

You have not provided any solid proof of your belief, which itself direct
contradicts the opinion of at least three people, one of which is ironically a
non-FFmpeg developer "user" who you claim to represent and whose opinion you
claim to value.

Therefore, without further elaboration, I propose to regard your argument as
null and void for the purpose of this discussion.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Thu, Mar 03, 2016 at 11:04:09PM +, Carl Eugen Hoyos wrote:
> Timo Rothenpieler  rothenpieler.org> writes:
> 
> > So instead of
> > 
> > N-78885-g966eade
> 
> The continuous numbering scheme is very convenient when 
> answering user questions and it reflects very well the 
> (past and current) development model of FFmpeg that is 
> not release-driven ...

Do I understand correctly that FFmpeg in the future will not version releases
backwards? If that is the case, then the "continuous" bit is a nonissue.

The argument on development model is unrelated to discussion.

> 
> > 
> > One now gets
> > 
> > n3.1-dev-422-g966eade
> 
> ... while I personally find this slightly ugly.

Users seem to disagree. One example of such a complaint is
http://willus.com/author/ffmpegbmark.shtml:

**I continue to be frustrated** with the nightly-build ffmpeg version
numbering. . . . It would be nice if the nightly builds gave some
indication of what major and minor version release they are related to,
even if it's a snapshot build. A version number like N-46936-g8b6aeb1 is
**meaningless to me (and to most other users, I imagine)**. Why is this so
hard? This is where avconv.exe does much better, giving a more
intelligible version number like v9_beta2-255-gb9629ac.

(some emphasis is mine)

Using the version also comes with other advantages. It is now a lot easier to
check if a certain feature is available in a build by looking at the Changelog
(which records release versions, not N-based revision numbers).

Of course, this argument operates on the premise that making things easier for
users is of utmost concern for us. Please inspire me if this is not the case.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v9] VideoToolbox H.264 Encoder

[Timothy Gu]

Hi,

On Mon, Feb 29, 2016 at 9:42 PM Rick Kern  wrote:

> Autodetected by default. Encode using -codec:v vtenc.
>
> Signed-off-by: Rick Kern 
> ---
>  MAINTAINERS|1 +
>  configure  |   19 +
>  libavcodec/Makefile|1 +
>  libavcodec/allcodecs.c |1 +
>  libavcodec/vtenc.c | 1339
> 
>  5 files changed, 1361 insertions(+)
>  create mode 100644 libavcodec/vtenc.c
>

We already have videotoolbox AVHWAccel. Maybe it would be better to change
the name of the file to videotoolboxenc.c so that it's easier to associate
these two files?

> +AVCodec ff_vtenc_encoder = {

> +.name = "vtenc",
> +.long_name= NULL_IF_CONFIG_SMALL("VideoToolbox H.264
> Encoder"),
>

The norm seems to be using "h264_videotoolbox" (like "h264_qsv") so that
potential future extensions to VideoToolbox can be supported without
changing the name of the codec.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/vc1dsp: Split the file into MC and loopfilter

[Timothy Gu]

On Mon, Feb 29, 2016 at 4:57 AM Ronald S. Bultje  wrote:

> This is kind of hard to review, but I'm going to assume that there's no
> actual code changes, in which case this LGTM.
>

No there isn't. Applied, thanks.

Timothy

>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] tests/api: Silence a few uninitialized variables warnings

[Timothy Gu]

---
 tests/api/api-flac-test.c | 2 +-
 tests/api/api-seek-test.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/api/api-flac-test.c b/tests/api/api-flac-test.c
index 7b48059..288bc2c 100644
--- a/tests/api/api-flac-test.c
+++ b/tests/api/api-flac-test.c
@@ -115,7 +115,7 @@ static int run_test(AVCodec *enc, AVCodec *dec, 
AVCodecContext *enc_ctx,
 int result = 0;
 int got_output = 0;
 int i = 0;
-int in_frame_bytes, out_frame_bytes;
+int in_frame_bytes = 0, out_frame_bytes = 0;
 
 in_frame = av_frame_alloc();
 if (!in_frame) {
diff --git a/tests/api/api-seek-test.c b/tests/api/api-seek-test.c
index 135b972..5b655d8 100644
--- a/tests/api/api-seek-test.c
+++ b/tests/api/api-seek-test.c
@@ -179,7 +179,7 @@ static int seek_test(const char *input_filename, const char 
*start, const char *
 AVFormatContext *fmt_ctx = NULL;
 int video_stream;
 int result;
-int i, j;
+int i = 0, j = 0;
 long int start_ts, end_ts;
 
 size_of_array = 0;
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] x86/vc1dsp: Split the file into MC and loopfilter

[Timothy Gu]

---
 libavcodec/x86/Makefile  |   3 +-
 libavcodec/x86/vc1dsp.asm| 585 ---
 libavcodec/x86/vc1dsp_loopfilter.asm | 317 +++
 libavcodec/x86/vc1dsp_mc.asm | 292 +
 4 files changed, 611 insertions(+), 586 deletions(-)
 delete mode 100644 libavcodec/x86/vc1dsp.asm
 create mode 100644 libavcodec/x86/vc1dsp_loopfilter.asm
 create mode 100644 libavcodec/x86/vc1dsp_mc.asm

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 629b0ee..839b5bc 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -120,7 +120,8 @@ YASM-OBJS-$(CONFIG_QPELDSP)+= x86/qpeldsp.o 
\
   x86/fpel.o\
   x86/qpel.o
 YASM-OBJS-$(CONFIG_RV34DSP)+= x86/rv34dsp.o
-YASM-OBJS-$(CONFIG_VC1DSP) += x86/vc1dsp.o
+YASM-OBJS-$(CONFIG_VC1DSP) += x86/vc1dsp_loopfilter.o   \
+  x86/vc1dsp_mc.o
 YASM-OBJS-$(CONFIG_IDCTDSP)+= x86/simple_idct10.o
 YASM-OBJS-$(CONFIG_VIDEODSP)   += x86/videodsp.o
 YASM-OBJS-$(CONFIG_VP3DSP) += x86/vp3dsp.o
diff --git a/libavcodec/x86/vc1dsp.asm b/libavcodec/x86/vc1dsp.asm
deleted file mode 100644
index eee42c2..000
--- a/libavcodec/x86/vc1dsp.asm
+++ /dev/null
@@ -1,585 +0,0 @@
-;**
-;* VC1 DSP optimizations
-;* Copyright (c) 2007 Christophe GISQUET 
-;* Copyright (c) 2009 David Conrad
-;*
-;* This file is part of FFmpeg.
-;*
-;* FFmpeg is free software; you can redistribute it and/or
-;* modify it under the terms of the GNU Lesser General Public
-;* License as published by the Free Software Foundation; either
-;* version 2.1 of the License, or (at your option) any later version.
-;*
-;* FFmpeg is distributed in the hope that it will be useful,
-;* but WITHOUT ANY WARRANTY; without even the implied warranty of
-;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-;* Lesser General Public License for more details.
-;*
-;* You should have received a copy of the GNU Lesser General Public
-;* License along with FFmpeg; if not, write to the Free Software
-;* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
-;**
-
-%include "libavutil/x86/x86util.asm"
-
-cextern pw_4
-cextern pw_5
-cextern pw_9
-cextern pw_128
-
-section .text
-
-; dst_low, dst_high (src), zero
-; zero-extends one vector from 8 to 16 bits
-%macro UNPACK_8TO16 4
-mova  m%2, m%3
-punpckh%1 m%3, m%4
-punpckl%1 m%2, m%4
-%endmacro
-
-%macro STORE_4_WORDS 6
-%if cpuflag(sse4)
-pextrw %1, %5, %6+0
-pextrw %2, %5, %6+1
-pextrw %3, %5, %6+2
-pextrw %4, %5, %6+3
-%else
-movd  %6d, %5
-%if mmsize==16
-psrldq %5, 4
-%else
-psrlq  %5, 32
-%endif
-mov%1, %6w
-shr%6, 16
-mov%2, %6w
-movd  %6d, %5
-mov%3, %6w
-shr%6, 16
-mov%4, %6w
-%endif
-%endmacro
-
-; in:  p1 p0 q0 q1, clobbers p0
-; out: p1 = (2*(p1 - q1) - 5*(p0 - q0) + 4) >> 3
-%macro VC1_LOOP_FILTER_A0 4
-psubw  %1, %4
-psubw  %2, %3
-paddw  %1, %1
-pmullw %2, [pw_5]
-psubw  %1, %2
-paddw  %1, [pw_4]
-psraw  %1, 3
-%endmacro
-
-; in: p0 q0 a0 a1 a2
-; m0 m1 m7 m6 m5
-; %1: size
-; out: m0=p0' m1=q0'
-%macro VC1_FILTER 1
-PABSW   m4, m7
-PABSW   m3, m6
-PABSW   m2, m5
-movam6, m4
-pminsw  m3, m2
-pcmpgtw m6, m3  ; if (a2 < a0 || a1 < a0)
-psubw   m3, m4
-pmullw  m3, [pw_5]   ; 5*(a3 - a0)
-PABSW   m2, m3
-psraw   m2, 3   ; abs(d/8)
-pxorm7, m3  ; d_sign ^= a0_sign
-
-pxorm5, m5
-movdm3, r2d
-%if %1 > 4
-punpcklbw m3, m3
-%endif
-punpcklbw m3, m5
-pcmpgtw m3, m4  ; if (a0 < pq)
-pandm6, m3
-
-movam3, m0
-psubw   m3, m1
-PABSW   m4, m3
-psraw   m4, 1
-pxorm3, m7  ; d_sign ^ clip_sign
-psraw   m3, 15
-pminsw  m2, m4  ; min(d, clip)
-pcmpgtw m4, m5
-pandm6, m4  ; filt3 (C return value)
-
-; each set of 4 pixels is not filtered if the 3rd is not
-%if mmsize==16
-pshuflw m4, m6, 0xaa
-%if %1 > 4
-pshufhw m4, m4, 0xaa
-%endif
-%else
-pshufw  m4, m6, 0xaa
-%endif
-pandn   m3, m4
-pandm2, m6
-pandm3, m2  ; d final
-
-psraw   m7, 15
-pxorm3, m7
-psubw   m3, m7
-psubw   m0, m3
-paddw   m1, m3
-packuswb m0, m0
-packuswb m1, m1
-%endmacro
-
-; 1st param: size of filter
-; 2nd param: mov suffix equivalent to the filter size
-%macro VC1_V_LOOP_FILTER 2
-pxor  m5, m5
-mov%2 m6, [r4]
-mov%2 m4, [r4+r1]
-mov%2 m7, [r4+2*r1]
-mov%2 m0, [r4+r3]
-punpcklbw m6, m5
-punpcklbw m4, m5
-

Re: [FFmpeg-devel] [PATCH] LICENSE: Thorough editing

[Timothy Gu]

On Sat, Feb 13, 2016 at 05:41:10PM -0800, Timothy Gu wrote:
> The changes in "Incompatible libraries" section are strictly based on
> what our configure script says.
> ---
>  LICENSE.md | 64 
> +-
>  1 file changed, 38 insertions(+), 26 deletions(-)

Pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE2 optimization for divide

[Timothy Gu]

On Sun, Feb 14, 2016 at 03:45:11PM +0100, Henrik Gramner wrote:
> You could try doing 8 or 16 bytes per iteration instead of 4, it might
> be faster depending on how good your cpu is at OOE.

As discussed on IRC, no observable difference has been observed with such
changes, mainly because the bottleneck is in the division itself.

Therefore, patch applied without changes.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Retire unused FATE IDs

[Timothy Gu]

Hi all,

For better security for the FATE server, I have just disabled the SSH keys
corresponding to the following owners:

- ab (only slot is "ab_haiku_fate;" has not been active for 9 months)
- amalia (only slot is "x86_64-Fedora_20-gcc-4.8.3" with one run; has not been
  active for more than 1 year)
- anshul (only slot is "x86-openSuse-gcc-4.7-dakudaddy" with one run; has not
  been active for more than two years)
- dravorek (only slot is "x86-Win10-msvc-19.00.22609" with six runs; has not
  been active for 11 months)
- fate1 (no current FATE stations)
- fate10407 (no current FATE stations)
- graham (no current FATE stations)
- nbabic (seems to be superseded by "nedeljko2;" only slot is
  "mips_linux_gcc_1_7_1;" has not been active for more than 1.5 years)
- reimar (no current FATE stations)
- wolfgang_lietz (only slot is "WL_dolinux" with three runs; has not been
  active for 5 months)

If you are the owner of one of the aforementioned FATE stations/slots and wish
your reporting access to FATE be restored, please contact me or
fate-ad...@ffmpeg.org.

Thank you.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_blend: Use integers for divide mode

[Timothy Gu]

On Sun, Feb 14, 2016 at 10:41:04AM +0100, Paul B Mahol wrote:
> 
> ok

Pushed (last week). Thanks.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/12] avutil/parseutils: use microsecond precision when parsing "now" in av_parse_time()

[Timothy Gu]

On Sun, Feb 14, 2016 at 02:54:29AM +0100, Marton Balint wrote:
> 
> I have applied the series except the last one patching ffmpeg_opt.

This set seems to cause some issues in some FATE stations:

http://fatebeta.ffmpeg.org/report/armel5tej-qemu-debian-gcc4.4/20160214170733#failed_tests
http://fatebeta.ffmpeg.org/report/mips-ubuntu-qemu-gcc-4.4/20160214183331#failed_tests
http://fatebeta.ffmpeg.org/report/sh4-debian-qemu-gcc-4.7/20160214132808#failed_tests
http://fatebeta.ffmpeg.org/report/x86_32-linux-gnu-gcc-4.4.5/20160214082234#failed_tests
http://fatebeta.ffmpeg.org/report/x86_64-netbsd-gcc46/20160214193410#failed_tests

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/vc1dsp: Port vc1_*_hor_16b_shift2 to NASM format

[Timothy Gu]

On Sun, Feb 14, 2016 at 01:21:57PM +0100, Christophe Gisquet wrote:
> Hi,
> 
> 2016-02-14 6:49 GMT+01:00 Timothy Gu <timothyg...@gmail.com>:
> >  %if HAVE_MMX_INLINE
> 
> Isn't that macro meant for C code (and in config.asm without much of a
> purpose)?

Yes, but this code isn't used unless inline asm is enabled so I don't want to
fill the binary up with bloat.

> >  ; Compute the rounder 32-r or 8-r and unpacks it to m7
> >  %macro LOAD_ROUNDER_MMX 1 ; round
> > -movd  m7, %1
> > +movh  m7, %1
> 
> Same here: until there's a SSE2 version for some of those functions,
> which will require specific code (like a shufps), that's unrelated.

Okay, removed.

> 
> > +cglobal vc1_%2_hor_16b_shift2, 4, 5, 0, dst, stride, src, rnd, h
> 
> Do you intend to port more?

Yes, when I get the time.

> Because in that case, having a SSE2
> version of this one would be possible.
> And the wider version would be straightforward in SSE2.
> And that would allow you to put at last a (c) in this code you've
> spent so much time with.

I do intend on writing a SSE2 version but I'd rather port them all first.

> 
> Otherwise looks OK, but I haven't tested.

FATE passes, so pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_blend: Reduce number of arguments for kernel function

[Timothy Gu]

On Sun, Feb 14, 2016 at 10:12:21AM +0100, Paul B Mahol wrote:
> On 2/14/16, Timothy Gu <timothyg...@gmail.com> wrote:
> > ---
> >  libavfilter/blend.h |  2 +-
> >  libavfilter/vf_blend.c  | 27 ++-
> >  libavfilter/x86/vf_blend.asm|  3 +--
> >  libavfilter/x86/vf_blend_init.c |  2 +-
> >  4 files changed, 17 insertions(+), 17 deletions(-)
> >
> 
> ok if it works

Pushed, thanks for the review.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] checkasm: Add vf_blend tests

[Timothy Gu]

On Sun, Feb 14, 2016 at 10:06:16AM +0100, Paul B Mahol wrote:
> On 2/14/16, Timothy Gu <timothyg...@gmail.com> wrote:
> > +
> > +#include 
> > +#include "checkasm.h"
> > +#include "libavfilter/blend.h"
> > +#include "libavutil/common.h"
> > +#include "libavutil/internal.h"
> > +#include "libavutil/intreadwrite.h"
> > +
> > +#define WIDTH 256
> > +#define HEIGHT 256
> > +#define BUF_UNITS 9
> > +#define SIZE_PER_UNIT (WIDTH * HEIGHT)
> > +#define BUF_SIZE (BUF_UNITS * SIZE_PER_UNIT)
> > +
> > +#define randomize_buffers()   \
> > +do {  \
> > +int i, j; \
> > +for (i = 0; i < HEIGHT; i++) {\
> > +for (j = 0; j < WIDTH; j++) { \
> > +top1[i * WIDTH + j] = \
> > +top2[i * WIDTH + j] = i;  \
> > +bot1[i * WIDTH + j] = \
> > +bot2[i * WIDTH + j] = j;  \
> 
> I think you failed to get my point.
> 
> For 8bit blend if you blend 256x256 horizontal gradient
> with 256x256 vertical gradient you will get blend
> function response, which is unique. And covers all
> possibilities for 8bit formats.

You might have missed the fact that I changed WIDTH and HEIGHT as well, so
that for top it'll look like this

  0   0   0   0   0   0 ...   0
  1   1   1   1   1   1 ...   1
  .   .   .   .   .   . ...   .
  .   .   .   .   .   . ...   .
  .   .   .   .   .   . ...   .
255 255 255 255 255 255 ... 255

For bottom it'll look like

  0   1   2   3   4   5 ... 255
  0   1   2   3   4   5 ... 255
  .   .   .   .   .   . ...   .
  .   .   .   .   .   . ...   .
  .   .   .   .   .   . ...   .
  0   1   2   3   4   5 ... 255

Or am I missing something?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] vf_blend: Templatize identity function and use a better name

[Timothy Gu]

On Sun, Feb 14, 2016 at 10:07:39AM +0100, Paul B Mahol wrote:
> On 2/14/16, Timothy Gu <timothyg...@gmail.com> wrote:
> > ---
> >  libavfilter/vf_blend.c | 22 ++
> >  1 file changed, 14 insertions(+), 8 deletions(-)
> >
> 
> lgtm

Set pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate/source: Do not use GNU extensions in sed

[Timothy Gu]

On Sat, Feb 13, 2016 at 02:35:22AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 12, 2016 at 05:07:20PM -0800, Timothy Gu wrote:
> > ---
> > 
> > Tested on FreeBSD 10.2.
> 
> patch should be ok

Pushed, thanks.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] checkasm: Add vf_blend tests

[Timothy Gu]

---
 tests/checkasm/Makefile   |   1 +
 tests/checkasm/checkasm.c |   3 ++
 tests/checkasm/checkasm.h |   1 +
 tests/checkasm/vf_blend.c | 130 ++
 4 files changed, 135 insertions(+)
 create mode 100644 tests/checkasm/vf_blend.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 07fe5bc..bfd7c11 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -1,5 +1,6 @@
 # libavcodec tests
 AVCODECOBJS-$(CONFIG_ALAC_DECODER) += alacdsp.o
+AVCODECOBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
 AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
 AVCODECOBJS-$(CONFIG_DCA_DECODER) += synth_filter.o
 AVCODECOBJS-$(CONFIG_FLACDSP)  += flacdsp.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 49fd2af..1e73e34 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -68,6 +68,9 @@ static const struct {
 #if CONFIG_ALAC_DECODER
 { "alacdsp", checkasm_check_alacdsp },
 #endif
+#if CONFIG_BLEND_FILTER
+{ "vf_blend", checkasm_check_blend },
+#endif
 #if CONFIG_BSWAPDSP
 { "bswapdsp", checkasm_check_bswapdsp },
 #endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 5c07f89..0c8bc2d 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -31,6 +31,7 @@
 #include "libavutil/timer.h"
 
 void checkasm_check_alacdsp(void);
+void checkasm_check_blend(void);
 void checkasm_check_bswapdsp(void);
 void checkasm_check_flacdsp(void);
 void checkasm_check_fmtconvert(void);
diff --git a/tests/checkasm/vf_blend.c b/tests/checkasm/vf_blend.c
new file mode 100644
index 000..51e1391
--- /dev/null
+++ b/tests/checkasm/vf_blend.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright (c) 2016 Tiancheng "Timothy" Gu
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include 
+#include "checkasm.h"
+#include "libavfilter/blend.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define WIDTH 256
+#define HEIGHT 256
+#define BUF_UNITS 9
+#define SIZE_PER_UNIT (WIDTH * HEIGHT)
+#define BUF_SIZE (BUF_UNITS * SIZE_PER_UNIT)
+
+#define randomize_buffers()   \
+do {  \
+int i, j; \
+for (i = 0; i < HEIGHT; i++) {\
+for (j = 0; j < WIDTH; j++) { \
+top1[i * WIDTH + j] = \
+top2[i * WIDTH + j] = i;  \
+bot1[i * WIDTH + j] = \
+bot2[i * WIDTH + j] = j;  \
+} \
+} \
+for (i = 0; i < SIZE_PER_UNIT; i += 4) { \
+uint32_t r = rnd();   \
+AV_WN32A(dst1 + i, r);\
+AV_WN32A(dst2 + i, r);\
+} \
+for (; i < BUF_SIZE; i += 4) {\
+uint32_t r = rnd();   \
+AV_WN32A(top1 + i, r);\
+AV_WN32A(top2 + i, r);\
+r = rnd();\
+AV_WN32A(bot1 + i, r);\
+AV_WN32A(bot2 + i, r);\
+r = rnd();\
+AV_WN32A(dst1 + i, r);\
+AV_WN32A(dst2 + i, r);\
+} \
+} while (0)
+
+#define check_blend_func() 
\
+do {   
\
+int i; 
\
+declare_func(void, const uint8_t *top, ptrdiff_t top_linesize, 
\
+ const uint8_t *bottom, ptrdiff_t bottom_linesize, 
\
+ uint8_t *dst, ptrdiff_t dst_linesize, 
\
+ ptrdiff_t width, ptrdiff_

[FFmpeg-devel] [PATCH 1/2] vf_blend: Templatize identity function and use a better name

[Timothy Gu]

---
 libavfilter/vf_blend.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index 2b734b4..c24013d 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -118,15 +118,21 @@ static const AVOption blend_options[] = {
 
 AVFILTER_DEFINE_CLASS(blend);
 
-static void blend_normal(const uint8_t *top, ptrdiff_t top_linesize,
- const uint8_t *bottom, ptrdiff_t bottom_linesize,
- uint8_t *dst, ptrdiff_t dst_linesize,
- ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,
- FilterParams *param, double *values)
-{
-av_image_copy_plane(dst, dst_linesize, top, top_linesize, width, end - 
start);
+#define COPY(src)\
+static void blend_copy ## src(const uint8_t *top, ptrdiff_t top_linesize,\
+const uint8_t *bottom, ptrdiff_t bottom_linesize,\
+uint8_t *dst, ptrdiff_t dst_linesize,\
+ptrdiff_t width, ptrdiff_t start, ptrdiff_t end, \
+FilterParams *param, double *values) \
+{\
+av_image_copy_plane(dst, dst_linesize, src, src ## _linesize,\
+width, end - start); \
 }
 
+COPY(top)
+
+#undef COPY
+
 static void blend_normal_8bit(const uint8_t *top, ptrdiff_t top_linesize,
   const uint8_t *bottom, ptrdiff_t bottom_linesize,
   uint8_t *dst, ptrdiff_t dst_linesize,
@@ -505,7 +511,7 @@ static int config_output(AVFilterLink *outlink)
 case BLEND_MULTIPLY:   param->blend = is_16bit ? blend_multiply_16bit  
 : blend_multiply_8bit;   break;
 case BLEND_MULTIPLY128:param->blend = is_16bit ? 
blend_multiply128_16bit: blend_multiply128_8bit;break;
 case BLEND_NEGATION:   param->blend = is_16bit ? blend_negation_16bit  
 : blend_negation_8bit;   break;
-case BLEND_NORMAL: param->blend = param->opacity == 1 ? 
blend_normal:
+case BLEND_NORMAL: param->blend = param->opacity == 1 ? 
blend_copytop :
   is_16bit ? blend_normal_16bit
 : blend_normal_8bit; break;
 case BLEND_OR: param->blend = is_16bit ? blend_or_16bit
 : blend_or_8bit; break;
 case BLEND_OVERLAY:param->blend = is_16bit ? blend_overlay_16bit   
 : blend_overlay_8bit;break;
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] vf_blend: Use memcpy when opacity is 0

[Timothy Gu]

For xor mode, 1.8x faster on Haswell.
---
 libavfilter/vf_blend.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index c24013d..599084f 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -130,6 +130,7 @@ static void blend_copy ## src(const uint8_t *top, ptrdiff_t 
top_linesize,\
 }
 
 COPY(top)
+COPY(bottom)
 
 #undef COPY
 
@@ -512,6 +513,7 @@ static int config_output(AVFilterLink *outlink)
 case BLEND_MULTIPLY128:param->blend = is_16bit ? 
blend_multiply128_16bit: blend_multiply128_8bit;break;
 case BLEND_NEGATION:   param->blend = is_16bit ? blend_negation_16bit  
 : blend_negation_8bit;   break;
 case BLEND_NORMAL: param->blend = param->opacity == 1 ? 
blend_copytop :
+  param->opacity == 0 ? 
blend_copybottom :
   is_16bit ? blend_normal_16bit
 : blend_normal_8bit; break;
 case BLEND_OR: param->blend = is_16bit ? blend_or_16bit
 : blend_or_8bit; break;
 case BLEND_OVERLAY:param->blend = is_16bit ? blend_overlay_16bit   
 : blend_overlay_8bit;break;
@@ -528,6 +530,10 @@ static int config_output(AVFilterLink *outlink)
 if (ARCH_X86)
 ff_blend_init_x86(param, is_16bit);
 
+if (param->opacity == 0 && param->mode != BLEND_NORMAL) {
+param->blend = blend_copytop;
+}
+
 if (s->all_expr && !param->expr_str) {
 param->expr_str = av_strdup(s->all_expr);
 if (!param->expr_str)
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE4.1 optimization for divide

[Timothy Gu]

---

The reason why this function uses SSE4.1 is the roundps instruction. Would
love to find a way to truncate a float to integer in SSE2.

---
 libavfilter/x86/vf_blend.asm| 32 
 libavfilter/x86/vf_blend_init.c |  6 ++
 2 files changed, 38 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index a5ea74c..dac04d7 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,6 +24,7 @@
 
 SECTION_RODATA
 
+ps_255: times 4 dd 255.0
 pw_1:   times 8 dw 1
 pw_128: times 8 dw 128
 pw_255: times 8 dw 255
@@ -285,3 +286,34 @@ INIT_XMM sse2
 BLEND_ABS
 INIT_XMM ssse3
 BLEND_ABS
+
+INIT_XMM sse4
+BLEND_INIT divide, 4
+pxor   m2, m2
+mova   m3, [ps_255]
+.nextrow:
+movxq, widthq
+
+.loop:
+movdm0, [topq + xq]  ; 00xx
+movdm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 0x0x
+punpcklbw   m1, m2
+punpcklwd   m0, m2   ; 000x000x
+punpcklwd   m1, m2
+
+cvtdq2psm0, m0
+cvtdq2psm1, m1
+divps   m0, m1   ; a / b
+mulps   m0, m3   ; a / b * 255
+roundps m0, m0, 3; truncate
+minps   m0, m3
+cvtps2dqm0, m0
+
+packusdwm0, m0   ; 0x0x
+packuswbm0, m0   ; 00xx
+movd   [dstq + xq], m0
+add xq, mmsize / 4
+
+jl .loop
+BLEND_END
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index a6baf94..f542870 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -48,6 +48,7 @@ BLEND_FUNC(difference, sse2)
 BLEND_FUNC(difference, ssse3)
 BLEND_FUNC(negation, sse2)
 BLEND_FUNC(negation, ssse3)
+BLEND_FUNC(divide, sse4)
 
 av_cold void ff_blend_init_x86(FilterParams *param, int is_16bit)
 {
@@ -79,4 +80,9 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_NEGATION:   param->blend = ff_blend_negation_ssse3;   break;
 }
 }
+if (EXTERNAL_SSE4(cpu_flags) && param->opacity == 1 && !is_16bit) {
+switch (param->mode) {
+case BLEND_DIVIDE:   param->blend = ff_blend_divide_sse4;   break;
+}
+}
 }
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: Remove x86_cpu.h

[Timothy Gu]

On Sun, Feb 07, 2016 at 09:29:23AM -0800, Timothy Gu wrote:
> It is private (uninstalled) and unused.
> ---
>  libavutil/x86_cpu.h | 1 -
>  1 file changed, 1 deletion(-)
>  delete mode 100644 libavutil/x86_cpu.h

Pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] x86/vc1dsp: Port vc1_*_hor_16b_shift2 to NASM format

[Timothy Gu]

---
 libavcodec/x86/vc1dsp.asm   | 92 -
 libavcodec/x86/vc1dsp_mmx.c | 61 --
 2 files changed, 99 insertions(+), 54 deletions(-)

diff --git a/libavcodec/x86/vc1dsp.asm b/libavcodec/x86/vc1dsp.asm
index 91a1991..2e9f067 100644
--- a/libavcodec/x86/vc1dsp.asm
+++ b/libavcodec/x86/vc1dsp.asm
@@ -25,6 +25,7 @@
 cextern pw_4
 cextern pw_5
 cextern pw_9
+cextern pw_128
 
 section .text
 
@@ -319,9 +320,47 @@ cglobal vc1_h_loop_filter8, 3,5,8
 RET
 
 %if HAVE_MMX_INLINE
+
+; XXX some of these macros are not used right now, but they will in the future
+; when more functions are ported.
+
+%macro OP_PUT 2 ; dst, src
+%endmacro
+
+%macro OP_AVG 2 ; dst, src
+pavgb   %1, %2
+%endmacro
+
+%macro NORMALIZE_MMX 1 ; shift
+paddw   m3, m7 ; +bias-r
+paddw   m4, m7 ; +bias-r
+psraw   m3, %1
+psraw   m4, %1
+%endmacro
+
+%macro TRANSFER_DO_PACK 2 ; op, dst
+packuswbm3, m4
+%1  m3, [%2]
+mova  [%2], m3
+%endmacro
+
+%macro TRANSFER_DONT_PACK 2 ; op, dst
+%1  m3, [%2]
+%1  m3, [%2 + mmsize]
+mova  [%2], m3
+mova [mmsize + %2], m4
+%endmacro
+
+; see MSPEL_FILTER13_CORE for use as UNPACK macro
+%macro DO_UNPACK 1 ; reg
+punpcklbw   %1, m0
+%endmacro
+%macro DONT_UNPACK 1 ; reg
+%endmacro
+
 ; Compute the rounder 32-r or 8-r and unpacks it to m7
 %macro LOAD_ROUNDER_MMX 1 ; round
-movd  m7, %1
+movh  m7, %1
 punpcklwd m7, m7
 punpckldq m7, m7
 %endmacro
@@ -394,6 +433,57 @@ cglobal vc1_put_ver_16b_shift2, 4,7,0, dst, src, stride
 dec i
 jnz .loop
 REP_RET
+%undef rnd
+%undef shift
+%undef stride_neg2
+%undef stride_9minus4
+%undef i
+
+; void ff_vc1_*_hor_16b_shift2_mmx(uint8_t *dst, x86_reg stride,
+;  const int16_t *src, int rnd);
+; Data is already unpacked, so some operations can directly be made from
+; memory.
+%macro HOR_16B_SHIFT2 2 ; op, opname
+cglobal vc1_%2_hor_16b_shift2, 4, 5, 0, dst, stride, src, rnd, h
+movhq, 8
+sub  srcq, 2
+sub  rndd, (-1+9+9-1) * 1024 ; add -1024 bias
+LOAD_ROUNDER_MMX rndq
+mova   m5, [pw_9]
+mova   m6, [pw_128]
+pxor   m0, m0
+
+.loop:
+mova   m1, [srcq + 2 * 0]
+mova   m2, [srcq + 2 * 0 + mmsize]
+mova   m3, [srcq + 2 * 1]
+mova   m4, [srcq + 2 * 1 + mmsize]
+paddw  m3, [srcq + 2 * 2]
+paddw  m4, [srcq + 2 * 2 + mmsize]
+paddw  m1, [srcq + 2 * 3]
+paddw  m2, [srcq + 2 * 3 + mmsize]
+pmullw m3, m5
+pmullw m4, m5
+psubw  m3, m1
+psubw  m4, m2
+NORMALIZE_MMX  7
+; remove bias
+paddw  m3, m6
+paddw  m4, m6
+TRANSFER_DO_PACK   %1, dstq
+add  srcq, 24
+add  dstq, strideq
+dechq
+jnz .loop
+
+RET
+%endmacro
+
+INIT_MMX mmx
+HOR_16B_SHIFT2 OP_PUT, put
+
+INIT_MMX mmxext
+HOR_16B_SHIFT2 OP_AVG, avg
 %endif ; HAVE_MMX_INLINE
 
 %macro INV_TRANS_INIT 0
diff --git a/libavcodec/x86/vc1dsp_mmx.c b/libavcodec/x86/vc1dsp_mmx.c
index ff13d9b..8325648 100644
--- a/libavcodec/x86/vc1dsp_mmx.c
+++ b/libavcodec/x86/vc1dsp_mmx.c
@@ -38,6 +38,10 @@
 void ff_vc1_put_ver_16b_shift2_mmx(int16_t *dst,
const uint8_t *src, x86_reg stride,
int rnd, int64_t shift);
+void ff_vc1_put_hor_16b_shift2_mmx(uint8_t *dst, x86_reg stride,
+   const int16_t *src, int rnd);
+void ff_vc1_avg_hor_16b_shift2_mmxext(uint8_t *dst, x86_reg stride,
+  const int16_t *src, int rnd);
 
 #define OP_PUT(S,D)
 #define OP_AVG(S,D) "pavgb " #S ", " #D " \n\t"
@@ -71,55 +75,6 @@ void ff_vc1_put_ver_16b_shift2_mmx(int16_t *dst,
  "punpckldq %%mm7, %%mm7   \n\t"
 
 /**
- * Data is already unpacked, so some operations can directly be made from
- * memory.
- */
-#define VC1_HOR_16b_SHIFT2(OP, OPNAME)\
-static void OPNAME ## vc1_hor_16b_shift2_mmx(uint8_t *dst, x86_reg stride,\
- const int16_t *src, int rnd)\
-{\
-int h = 8;\
-\
-src -= 1;\
-rnd -= (-1+9+9-1)*1024; /* Add -1024 bias */\
-__asm__ volatile(\
-LOAD_ROUNDER_MMX("%4")\
-"movq  "MANGLE(ff_pw_128)", %%mm6\n\t"\
-"movq  "MANGLE(ff_pw_9)", %%mm5 \n\t"\
-"1:\n\t"\
-"movq  2*0+0(%1), %%mm1\n\t"\
-"movq  2*0+8(%1), %%mm2\n\t"\
-"movq  2*1+0(%1), %%mm3\n\t"\
-"movq  2*1+8(%1), %%mm4\n\t"\
-"paddw 

[FFmpeg-devel] [PATCH] LICENSE: Thorough editing

[Timothy Gu]

The changes in "Incompatible libraries" section are strictly based on
what our configure script says.
---
 LICENSE.md | 64 +-
 1 file changed, 38 insertions(+), 26 deletions(-)

diff --git a/LICENSE.md b/LICENSE.md
index 0c53d0f..a70f486 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -1,4 +1,4 @@
-#FFmpeg:
+# License
 
 Most files in FFmpeg are under the GNU Lesser General Public License version 
2.1
 or later (LGPL v2.1+). Read the file `COPYING.LGPLv2.1` for details. Some other
@@ -13,16 +13,19 @@ configure to activate them. In this case, FFmpeg's license 
changes to GPL v2+.
 Specifically, the GPL parts of FFmpeg are:
 
 - libpostproc
-- optional x86 optimizations in the files
-  - `libavcodec/x86/flac_dsp_gpl.asm`
-  - `libavcodec/x86/idct_mmx.c`
-  - `libavfilter/x86/vf_removegrain.asm`
-- libutvideo encoding/decoding wrappers in
-  `libavcodec/libutvideo*.cpp`
+- optional x86 optimization in the files
+- `libavcodec/x86/flac_dsp_gpl.asm`
+- `libavcodec/x86/idct_mmx.c`
+- `libavfilter/x86/vf_removegrain.asm`
+- libutvideo encoding/decoding wrappers in `libavcodec/libutvideo*.cpp`
 - the X11 grabber in `libavdevice/x11grab.c`
-- the swresample test app in
-  `libswresample/swresample-test.c`
-- the `texi2pod.pl` tool
+- the following building and testing tools
+- `compat/solaris/make_sunver.pl`
+- `doc/t2h.pm`
+- `doc/texi2pod.pl`
+- `libswresample/swresample-test.c`
+- `tests/checkasm/*`
+- `tests/tiny_ssim.c`
 - the following filters in libavfilter:
 - `f_ebur128.c`
 - `vf_blackframe.c`
@@ -47,9 +50,9 @@ Specifically, the GPL parts of FFmpeg are:
 - `vf_pp.c`
 - `vf_pp7.c`
 - `vf_pullup.c`
+- `vf_repeatfields.c`
 - `vf_sab.c`
 - `vf_smartblur.c`
-- `vf_repeatfields.c`
 - `vf_spp.c`
 - `vf_stereo3d.c`
 - `vf_super2xsai.c`
@@ -73,14 +76,12 @@ There are a handful of files under other licensing terms, 
namely:
 * `tests/reference.pnm` is under the expat license.
 
 
-external libraries
-==
+## External libraries
 
 FFmpeg can be combined with a number of external libraries, which sometimes
 affect the licensing of binaries resulting from the combination.
 
-compatible libraries
-
+### Compatible libraries
 
 The following libraries are under GPL:
 - frei0r
@@ -101,14 +102,25 @@ license is incompatible with the LGPL v2.1 and the GPL 
v2, but not with
 version 3 of those licenses. So to combine these libraries with FFmpeg, the
 license version needs to be upgraded by passing `--enable-version3` to 
configure.
 
-incompatible libraries
---
-
-The Fraunhofer AAC library and FAAC are under licenses which
-are incompatible with the GPLv2 and v3. We do not know for certain if their
-licenses are compatible with the LGPL.
-If you wish to enable these libraries, pass `--enable-nonfree` to configure.
-But note that if you enable any of these libraries the resulting binary will
-be under a complex license mix that is more restrictive than the LGPL and that
-may result in additional obligations. It is possible that these
-restrictions cause the resulting binary to be unredistributeable.
+### Incompatible libraries
+
+There are certain libraries you can combine with FFmpeg whose licenses are not
+compatible with the GPL and/or the LGPL. If you wish to enable these
+libraries, even in circumstances that their license may be incompatible, pass
+`--enable-nonfree` to configure. But note that if you enable any of these
+libraries the resulting binary will be under a complex license mix that is
+more restrictive than the LGPL and that may result in additional obligations.
+It is possible that these restrictions cause the resulting binary to be
+unredistributable.
+
+The Fraunhofer FDK AAC and OpenSSL libraries are under licenses which are
+incompatible with the GPLv2 and v3. To the best of our knowledge, they are
+compatible with the LGPL.
+
+The FAAC library is incompatible with all versions of GPL and LGPL.
+
+The NVENC library, while its header file is licensed under the compatible MIT
+license, requires a proprietary binary blob at run time, and is deemed to be
+incompatible with the GPL. We are not certain if it is compatible with the
+LGPL, but we require `--enable-nonfree` even with LGPL configurations in case
+it is not.
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE2 optimization for divide

[Timothy Gu]

On Sat, Feb 13, 2016 at 07:21:25PM -0800, Timothy Gu wrote:
> ---
>  libavfilter/x86/vf_blend.asm| 30 ++
>  libavfilter/x86/vf_blend_init.c |  2 ++
>  2 files changed, 32 insertions(+)

Locally added commit message:

 4.5x faster than C float version with autovectorization
10  x faster than C int version
25  x faster than C float version without autovectorization

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vf_blend: Reduce number of arguments for kernel function

[Timothy Gu]

---
 libavfilter/blend.h |  2 +-
 libavfilter/vf_blend.c  | 27 ++-
 libavfilter/x86/vf_blend.asm|  3 +--
 libavfilter/x86/vf_blend_init.c |  2 +-
 4 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/libavfilter/blend.h b/libavfilter/blend.h
index 161055c..7003505 100644
--- a/libavfilter/blend.h
+++ b/libavfilter/blend.h
@@ -67,7 +67,7 @@ typedef struct FilterParams {
 void (*blend)(const uint8_t *top, ptrdiff_t top_linesize,
   const uint8_t *bottom, ptrdiff_t bottom_linesize,
   uint8_t *dst, ptrdiff_t dst_linesize,
-  ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,
+  ptrdiff_t width, ptrdiff_t height,
   struct FilterParams *param, double *values);
 } FilterParams;
 
diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index 2b734b4..1c9924a 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -121,22 +121,22 @@ AVFILTER_DEFINE_CLASS(blend);
 static void blend_normal(const uint8_t *top, ptrdiff_t top_linesize,
  const uint8_t *bottom, ptrdiff_t bottom_linesize,
  uint8_t *dst, ptrdiff_t dst_linesize,
- ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,
+ ptrdiff_t width, ptrdiff_t height,
  FilterParams *param, double *values)
 {
-av_image_copy_plane(dst, dst_linesize, top, top_linesize, width, end - 
start);
+av_image_copy_plane(dst, dst_linesize, top, top_linesize, width, height);
 }
 
 static void blend_normal_8bit(const uint8_t *top, ptrdiff_t top_linesize,
   const uint8_t *bottom, ptrdiff_t bottom_linesize,
   uint8_t *dst, ptrdiff_t dst_linesize,
-  ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,
+  ptrdiff_t width, ptrdiff_t height,
   FilterParams *param, double *values)
 {
 const double opacity = param->opacity;
 int i, j;
 
-for (i = start; i < end; i++) {
+for (i = 0; i < height; i++) {
 for (j = 0; j < width; j++) {
 dst[j] = top[j] * opacity + bottom[j] * (1. - opacity);
 }
@@ -149,7 +149,7 @@ static void blend_normal_8bit(const uint8_t *top, ptrdiff_t 
top_linesize,
 static void blend_normal_16bit(const uint8_t *_top, ptrdiff_t top_linesize,
   const uint8_t *_bottom, ptrdiff_t 
bottom_linesize,
   uint8_t *_dst, ptrdiff_t dst_linesize,
-  ptrdiff_t width, ptrdiff_t start, ptrdiff_t 
end,
+  ptrdiff_t width, ptrdiff_t height,
   FilterParams *param, double *values)
 {
 const uint16_t *top = (uint16_t*)_top;
@@ -161,7 +161,7 @@ static void blend_normal_16bit(const uint8_t *_top, 
ptrdiff_t top_linesize,
 top_linesize /= 2;
 bottom_linesize /= 2;
 
-for (i = start; i < end; i++) {
+for (i = 0; i < height; i++) {
 for (j = 0; j < width; j++) {
 dst[j] = top[j] * opacity + bottom[j] * (1. - opacity);
 }
@@ -175,13 +175,13 @@ static void blend_normal_16bit(const uint8_t *_top, 
ptrdiff_t top_linesize,
 static void blend_## name##_8bit(const uint8_t *top, ptrdiff_t top_linesize,   
  \
  const uint8_t *bottom, ptrdiff_t 
bottom_linesize,   \
  uint8_t *dst, ptrdiff_t dst_linesize, 
  \
- ptrdiff_t width, ptrdiff_t start, ptrdiff_t 
end,\
+ ptrdiff_t width, ptrdiff_t height,
\
  FilterParams *param, double *values)  
\
 {  
\
 double opacity = param->opacity;   
\
 int i, j;  
\

\
-for (i = start; i < end; i++) {
\
+for (i = 0; i < height; i++) { 
\
 for (j = 0; j < width; j++) {  
\
 dst[j] = top[j] + ((expr) - top[j]) * opacity; 
\
 }  
\
@@ -195,7 +195,7 @@ static void blend_## name##_8bit(const uint8_t *top, 
ptrdiff_t top_linesize,
 static void blend_## name##_16bit(const uint8_t *_top, ptrdiff_t top_linesize, 
  \
   const uint8_t *_bottom, ptrdiff_t 
bottom_linesize, \
   uint8_t *_dst, ptrdiff_t dst_linesize,   
  

[FFmpeg-devel] [PATCH] vf_blend: Use integers for divide mode

[Timothy Gu]

2.5x faster for 8-bit mode without autovectorization in GCC, 2x
slower with it on x86. However, since the platforms we enable GCC
autovectorization on most probably has support for SSE2
optimization (added in the subsequent commit), this commit should
in general do good.
---
 libavfilter/vf_blend.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index 2b734b4..b9e5add 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -240,7 +240,7 @@ DEFINE_BLEND8(hardlight,  (B < 128) ? MULTIPLY(2, B, A) : 
SCREEN(2, B, A))
 DEFINE_BLEND8(hardmix,(A < (255 - B)) ? 0: 255)
 DEFINE_BLEND8(darken, FFMIN(A, B))
 DEFINE_BLEND8(lighten,FFMAX(A, B))
-DEFINE_BLEND8(divide, av_clip_uint8(((float)A / ((float)B) * 255)))
+DEFINE_BLEND8(divide, av_clip_uint8(B == 0 ? 255 : 255 * A / B))
 DEFINE_BLEND8(dodge,  DODGE(A, B))
 DEFINE_BLEND8(burn,   BURN(A, B))
 DEFINE_BLEND8(softlight,  (A > 127) ? B + (255 - B) * (A - 127.5) / 127.5 * 
(0.5 - fabs(B - 127.5) / 255): B - B * ((127.5 - A) / 127.5) * (0.5 - fabs(B - 
127.5)/255))
@@ -280,7 +280,7 @@ DEFINE_BLEND16(hardlight,  (B < 32768) ? MULTIPLY(2, B, A) 
: SCREEN(2, B, A))
 DEFINE_BLEND16(hardmix,(A < (65535 - B)) ? 0: 65535)
 DEFINE_BLEND16(darken, FFMIN(A, B))
 DEFINE_BLEND16(lighten,FFMAX(A, B))
-DEFINE_BLEND16(divide, av_clip_uint16(((float)A / ((float)B) * 65535)))
+DEFINE_BLEND16(divide, av_clip_uint16(B == 0 ? 65535 : 65535 * A / B))
 DEFINE_BLEND16(dodge,  DODGE(A, B))
 DEFINE_BLEND16(burn,   BURN(A, B))
 DEFINE_BLEND16(softlight,  (A > 32767) ? B + (65535 - B) * (A - 32767.5) / 
32767.5 * (0.5 - fabs(B - 32767.5) / 65535): B - B * ((32767.5 - A) / 32767.5) 
* (0.5 - fabs(B - 32767.5)/65535))
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE2 optimization for divide

[Timothy Gu]

---
 libavfilter/x86/vf_blend.asm| 30 ++
 libavfilter/x86/vf_blend_init.c |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index a5ea74c..303ea3a 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,6 +24,7 @@
 
 SECTION_RODATA
 
+ps_255: times 4 dd 255.0
 pw_1:   times 8 dw 1
 pw_128: times 8 dw 128
 pw_255: times 8 dw 255
@@ -219,6 +220,35 @@ BLEND_INIT hardmix, 5
 jl .loop
 BLEND_END
 
+BLEND_INIT divide, 4
+pxor   m2, m2
+mova   m3, [ps_255]
+.nextrow:
+movxq, widthq
+
+.loop:
+movdm0, [topq + xq]  ; 00xx
+movdm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 0x0x
+punpcklbw   m1, m2
+punpcklwd   m0, m2   ; 000x000x
+punpcklwd   m1, m2
+
+cvtdq2psm0, m0
+cvtdq2psm1, m1
+divps   m0, m1   ; a / b
+mulps   m0, m3   ; a / b * 255
+minps   m0, m3
+cvttps2dq   m0, m0
+
+packssdwm0, m0   ; 0x0x
+packuswbm0, m0   ; 00xx
+movd   [dstq + xq], m0
+add xq, mmsize / 4
+
+jl .loop
+BLEND_END
+
 BLEND_INIT phoenix, 4
 mova   m3, [pb_255]
 .nextrow:
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index a6baf94..677e759 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -39,6 +39,7 @@ BLEND_FUNC(difference128, sse2)
 BLEND_FUNC(multiply, sse2)
 BLEND_FUNC(screen, sse2)
 BLEND_FUNC(hardmix, sse2)
+BLEND_FUNC(divide, sse2)
 BLEND_FUNC(lighten, sse2)
 BLEND_FUNC(or, sse2)
 BLEND_FUNC(phoenix, sse2)
@@ -61,6 +62,7 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_AVERAGE:  param->blend = ff_blend_average_sse2;  break;
 case BLEND_DARKEN:   param->blend = ff_blend_darken_sse2;   break;
 case BLEND_DIFFERENCE128: param->blend = ff_blend_difference128_sse2; 
break;
+case BLEND_DIVIDE:   param->blend = ff_blend_divide_sse2;   break;
 case BLEND_HARDMIX:  param->blend = ff_blend_hardmix_sse2;  break;
 case BLEND_LIGHTEN:  param->blend = ff_blend_lighten_sse2;  break;
 case BLEND_MULTIPLY: param->blend = ff_blend_multiply_sse2; break;
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE4.1 optimization for divide

[Timothy Gu]

I've already answered these on IRC but for the sake of completion I'll include
the answers here as well.

On Sat, Feb 13, 2016 at 10:26:58PM -0300, James Almer wrote:
> On 2/13/2016 9:27 PM, Timothy Gu wrote:
> > ---
> > 
> > The reason why this function uses SSE4.1 is the roundps instruction. Would
> > love to find a way to truncate a float to integer in SSE2.

CVTTPS2DQ—Convert with Truncation Packed Single-Precision FP Values to Packed
Dword Integers

> > +punpcklwd   m0, m2   ; 000x000x
> > +punpcklwd   m1, m2
> > +
> > +cvtdq2psm0, m0
> > +cvtdq2psm1, m1
> > +divps   m0, m1   ; a / b
> > +mulps   m0, m3   ; a / b * 255
> > +roundps m0, m0, 3; truncate
> > +minps   m0, m3
> 
> Are these two really needed? After a quick glance GCC seems to simply 
> generate more
> or less the same code you're using here sans these two. (convert to float, 
> div, mul,
> convert to int, saturate to uint8_t).

roundps becomes unnecessary after cvttps2dq. minps is needed for divide-by-0
cases.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fate/source: Do not use GNU extensions in sed

[Timothy Gu]

---

Tested on FreeBSD 10.2.

---
 cmdutils.h | 4 ++--
 tests/fate/source-check.sh | 8 +---
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/cmdutils.h b/cmdutils.h
index 7f3db2a..83ea4ad 100644
--- a/cmdutils.h
+++ b/cmdutils.h
@@ -19,8 +19,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#ifndef FFMPEG_CMDUTILS_H
-#define FFMPEG_CMDUTILS_H
+#ifndef CMDUTILS_H
+#define CMDUTILS_H
 
 #include 
 
diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
index 1947b52..33affae 100755
--- a/tests/fate/source-check.sh
+++ b/tests/fate/source-check.sh
@@ -19,10 +19,12 @@ git grep -L -E "This file is part of FFmpeg|This file is 
part of libswresample|"
 echo Headers without standard inclusion guards:
 for f in `git ls-files | grep '\.h$'` ; do
 macro="`echo $f | sed \
--e '/\/\|^ff/!{s/\(.*\)/ffmpeg\/\1/}' \
 -e 's/^lib//' \
--e 's/[^A-Za-z0-9]\{1\,\}/_/g' \
--e 's/_\(a\|v\|av\)f_/_/' \
+-e 's/[^A-Za-z0-9]\{1,\}/_/g' \
+-e 's/_af_/_/' \
+-e 's/_vf_/_/' \
+-e 's/_avf_/_/' \
+-e 's/_vaf_/_/' \
 | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
 
 grep -L "^#define $macro$" $f
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fate/source: Attempt to fix BSD sed

[Timothy Gu]

I apparently used a GNU extension in the !{} syntax. Remove that rule
and the cause of it.
---
 cmdutils.h | 4 ++--
 tests/fate/source-check.sh | 1 -
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/cmdutils.h b/cmdutils.h
index 7f3db2a..83ea4ad 100644
--- a/cmdutils.h
+++ b/cmdutils.h
@@ -19,8 +19,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#ifndef FFMPEG_CMDUTILS_H
-#define FFMPEG_CMDUTILS_H
+#ifndef CMDUTILS_H
+#define CMDUTILS_H
 
 #include 
 
diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
index 1947b52..50939f9 100755
--- a/tests/fate/source-check.sh
+++ b/tests/fate/source-check.sh
@@ -19,7 +19,6 @@ git grep -L -E "This file is part of FFmpeg|This file is part 
of libswresample|"
 echo Headers without standard inclusion guards:
 for f in `git ls-files | grep '\.h$'` ; do
 macro="`echo $f | sed \
--e '/\/\|^ff/!{s/\(.*\)/ffmpeg\/\1/}' \
 -e 's/^lib//' \
 -e 's/[^A-Za-z0-9]\{1\,\}/_/g' \
 -e 's/_\(a\|v\|av\)f_/_/' \
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] x86/vf_blend: Move multiplying to a macro

[Timothy Gu]

On Wed, Feb 10, 2016 at 08:09:07PM +0100, Paul B Mahol wrote:
> On 2/9/16, Timothy Gu <timothyg...@gmail.com> wrote:
> > ---
> >  libavfilter/x86/vf_blend.asm | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> 
> ok

Pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] checkasm: Add vf_blend tests

[Timothy Gu]

---
 tests/checkasm/Makefile   |   1 +
 tests/checkasm/checkasm.c |   3 ++
 tests/checkasm/checkasm.h |   1 +
 tests/checkasm/vf_blend.c | 111 ++
 4 files changed, 116 insertions(+)
 create mode 100644 tests/checkasm/vf_blend.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 07fe5bc..bfd7c11 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -1,5 +1,6 @@
 # libavcodec tests
 AVCODECOBJS-$(CONFIG_ALAC_DECODER) += alacdsp.o
+AVCODECOBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
 AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
 AVCODECOBJS-$(CONFIG_DCA_DECODER) += synth_filter.o
 AVCODECOBJS-$(CONFIG_FLACDSP)  += flacdsp.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 49fd2af..1e73e34 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -68,6 +68,9 @@ static const struct {
 #if CONFIG_ALAC_DECODER
 { "alacdsp", checkasm_check_alacdsp },
 #endif
+#if CONFIG_BLEND_FILTER
+{ "vf_blend", checkasm_check_blend },
+#endif
 #if CONFIG_BSWAPDSP
 { "bswapdsp", checkasm_check_bswapdsp },
 #endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 5c07f89..0c8bc2d 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -31,6 +31,7 @@
 #include "libavutil/timer.h"
 
 void checkasm_check_alacdsp(void);
+void checkasm_check_blend(void);
 void checkasm_check_bswapdsp(void);
 void checkasm_check_flacdsp(void);
 void checkasm_check_fmtconvert(void);
diff --git a/tests/checkasm/vf_blend.c b/tests/checkasm/vf_blend.c
new file mode 100644
index 000..51c4999
--- /dev/null
+++ b/tests/checkasm/vf_blend.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2016 Tiancheng "Timothy" Gu
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include 
+#include "checkasm.h"
+#include "libavfilter/blend.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define WIDTH 64
+#define LINESIZE 64
+#define HEIGHT 8
+#define BUF_UNITS 9
+#define SIZE_PER_UNIT (LINESIZE * HEIGHT)
+#define BUF_SIZE (BUF_UNITS * SIZE_PER_UNIT)
+
+#define randomize_buffers() \
+do {\
+int i;  \
+for (i = 0; i < BUF_SIZE; i += 4) { \
+uint32_t r = rnd(); \
+AV_WN32A(top1 + i, r);  \
+AV_WN32A(top2 + i, r);  \
+r = rnd();  \
+AV_WN32A(bot1 + i, r);  \
+AV_WN32A(bot2 + i, r);  \
+r = rnd();  \
+AV_WN32A(dst1 + i, r);  \
+AV_WN32A(dst2 + i, r);  \
+}   \
+} while (0)
+
+#define check_blend_func() 
\
+do {   
\
+int i; 
\
+declare_func(void, const uint8_t *top, ptrdiff_t top_linesize, 
\
+ const uint8_t *bottom, ptrdiff_t bottom_linesize, 
\
+ uint8_t *dst, ptrdiff_t dst_linesize, 
\
+ ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,  
\
+ struct FilterParams *param, double *values);  
\
+   
\
+for (i = 0; i < BUF_UNITS - 1; i++) {  
\
+int src_offset = i * SIZE_PER_UNIT + i; /* Test various alignments 
*/  \
+int dst_offset = i * SIZE_PER_UNIT; /* dst must be aligned */  
\
+randomize_buffers();   
\
+call_ref(top1 + src_offset, LINESIZE, bot1 + src_off

Re: [FFmpeg-devel] [PATCH 4/4] tests: Add test for proper header guard

[Timothy Gu]

On Sun, Jan 31, 2016 at 3:47 PM Timothy Gu <timothyg...@gmail.com> wrote:

> On Fri, Jan 29, 2016 at 10:10:48AM +0100, Clément Bœsch wrote:
> > On Thu, Jan 28, 2016 at 06:33:56PM -0800, Timothy Gu wrote:
> > > ---
> > >  tests/fate/source-check.sh | 11 +++
> > >  tests/ref/fate/source  | 12 
> > >  2 files changed, 23 insertions(+)
> > >
> > > diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
> > > index fb7af98..5524236 100755
> > > --- a/tests/fate/source-check.sh
> > > +++ b/tests/fate/source-check.sh
> > > @@ -16,5 +16,16 @@ git grep -L -E "This file is part of FFmpeg|This
> file is part of libswresample|"
> > >  "This program is free software; you can redistribute it and/or
> modify|"\
> > >  "This file is placed in the public domain" | grep -E
> '\.c$|\.h$|\.S$|\.asm$'
> > >
> > > +echo Headers without standard inclusion guards:
> > > +for f in `git ls-files | grep '\.h$'` ; do
> > > +macro="`echo $f | sed \
> > > +-e '/\/\|^ff/!{s/\(.*\)/ffmpeg\/\1/}' \
> > > +-e 's/^lib//' \
> > > +-e 's/[^A-Za-z0-9]\{1\,\}/_/g' \
> > > +-e 's/_\(a\|v\|av\)f_/_/' \
> >
> > > +| tr '[:lower:]' '[:upper:]'`"
> >
> > Not sure about the portability of these arguments. I think it might be
> > safer to copy/use toupper() from the configure.
>
> Changed locally.
>

Reviewed by Clément on IRC and pushed.

01:07 <@ubitux> Timothy_Gu: no other comment from me, i like the idea

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] x86/vf_blend: Move multiplying to a macro

[Timothy Gu]

---
 libavfilter/x86/vf_blend.asm | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 9388a74..50b5f8a 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -102,6 +102,15 @@ BLEND_INIT difference128, 4
 jl .loop
 BLEND_END
 
+%macro MULTIPLY 3 ; a, b, pw_1
+pmullw  %1, %2   ;   a * b
+paddw   %1, %3
+mova%2, %1
+psrlw   %2, 8
+paddw   %1, %2
+psrlw   %1, 8; 00xx00xx  a * b / 255
+%endmacro
+
 BLEND_INIT multiply, 4
 pxor   m2, m2
 mova   m3, [pw_1]
@@ -116,12 +125,7 @@ BLEND_INIT multiply, 4
 punpcklbw   m0, m2   ; 00xx00xx
 punpcklbw   m1, m2
 
-pmullw  m0, m1   ;   a * b
-paddw   m0, m3
-movam1, m0
-psrlw   m1, 8
-paddw   m0, m1
-psrlw   m0, 8; 00xx00xx  a * b / 255
+MULTIPLYm0, m1, m3
 
 packuswbm0, m0   ; 
 movh   [dstq + xq], m0
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] x86/vf_blend: Add SSE2 optimization for screen

[Timothy Gu]

---
 libavfilter/x86/vf_blend.asm| 29 +
 libavfilter/x86/vf_blend_init.c |  2 ++
 2 files changed, 31 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 50b5f8a..a5ea74c 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -111,6 +111,13 @@ BLEND_END
 psrlw   %1, 8; 00xx00xx  a * b / 255
 %endmacro
 
+%macro SCREEN 4   ; a, b, pw_1, pw_255
+pxor%1, %4   ; 00xx00xx  255 - a
+pxor%2, %4
+MULTIPLY%1, %2, %3
+pxor%1, %4   ; 00xx00xx  255 - x / 255
+%endmacro
+
 BLEND_INIT multiply, 4
 pxor   m2, m2
 mova   m3, [pw_1]
@@ -134,6 +141,28 @@ BLEND_INIT multiply, 4
 jl .loop
 BLEND_END
 
+BLEND_INIT screen, 5
+pxor   m2, m2
+mova   m3, [pw_1]
+mova   m4, [pw_255]
+.nextrow:
+movxq, widthq
+
+.loop:
+movhm0, [topq + xq]  ; 
+movhm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 00xx00xx
+punpcklbw   m1, m2
+
+SCREEN  m0, m1, m3, m4
+
+packuswbm0, m0   ; 
+movh   [dstq + xq], m0
+add xq, mmsize / 2
+
+jl .loop
+BLEND_END
+
 BLEND_INIT average, 3
 pxor   m2, m2
 .nextrow:
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index 8ac526a..a6baf94 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -37,6 +37,7 @@ BLEND_FUNC(and, sse2)
 BLEND_FUNC(darken, sse2)
 BLEND_FUNC(difference128, sse2)
 BLEND_FUNC(multiply, sse2)
+BLEND_FUNC(screen, sse2)
 BLEND_FUNC(hardmix, sse2)
 BLEND_FUNC(lighten, sse2)
 BLEND_FUNC(or, sse2)
@@ -65,6 +66,7 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_MULTIPLY: param->blend = ff_blend_multiply_sse2; break;
 case BLEND_OR:   param->blend = ff_blend_or_sse2;   break;
 case BLEND_PHOENIX:  param->blend = ff_blend_phoenix_sse2;  break;
+case BLEND_SCREEN:   param->blend = ff_blend_screen_sse2; break;
 case BLEND_SUBTRACT: param->blend = ff_blend_subtract_sse2; break;
 case BLEND_XOR:  param->blend = ff_blend_xor_sse2;  break;
 case BLEND_DIFFERENCE: param->blend = ff_blend_difference_sse2; break;
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vf_blend: Add SSE2 optimization for multiply

[Timothy Gu]

5 times faster than C, 3 times overall.
---

Removes constant.c changes in accordance with James's comments

---
 libavfilter/x86/vf_blend.asm| 29 +
 libavfilter/x86/vf_blend_init.c |  2 ++
 2 files changed, 31 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 730be77..9388a74 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,6 +24,7 @@
 
 SECTION_RODATA
 
+pw_1:   times 8 dw 1
 pw_128: times 8 dw 128
 pw_255: times 8 dw 255
 pb_127: times 16 db 127
@@ -101,6 +102,34 @@ BLEND_INIT difference128, 4
 jl .loop
 BLEND_END
 
+BLEND_INIT multiply, 4
+pxor   m2, m2
+mova   m3, [pw_1]
+.nextrow:
+movxq, widthq
+
+.loop:
+ ; word
+ ; |--|
+movhm0, [topq + xq]  ; 
+movhm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 00xx00xx
+punpcklbw   m1, m2
+
+pmullw  m0, m1   ;   a * b
+paddw   m0, m3
+movam1, m0
+psrlw   m1, 8
+paddw   m0, m1
+psrlw   m0, 8; 00xx00xx  a * b / 255
+
+packuswbm0, m0   ; 
+movh   [dstq + xq], m0
+add xq, mmsize / 2
+
+jl .loop
+BLEND_END
+
 BLEND_INIT average, 3
 pxor   m2, m2
 .nextrow:
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index dc29547..8ac526a 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -36,6 +36,7 @@ BLEND_FUNC(average, sse2)
 BLEND_FUNC(and, sse2)
 BLEND_FUNC(darken, sse2)
 BLEND_FUNC(difference128, sse2)
+BLEND_FUNC(multiply, sse2)
 BLEND_FUNC(hardmix, sse2)
 BLEND_FUNC(lighten, sse2)
 BLEND_FUNC(or, sse2)
@@ -61,6 +62,7 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_DIFFERENCE128: param->blend = ff_blend_difference128_sse2; 
break;
 case BLEND_HARDMIX:  param->blend = ff_blend_hardmix_sse2;  break;
 case BLEND_LIGHTEN:  param->blend = ff_blend_lighten_sse2;  break;
+case BLEND_MULTIPLY: param->blend = ff_blend_multiply_sse2; break;
 case BLEND_OR:   param->blend = ff_blend_or_sse2;   break;
 case BLEND_PHOENIX:  param->blend = ff_blend_phoenix_sse2;  break;
 case BLEND_SUBTRACT: param->blend = ff_blend_subtract_sse2; break;
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel