Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> I'm not sure it's that easy. If that were correct, it would become
> GPL-compatible to distribute a GPL-licensed program linked with a
> proprietary library by simply inserting a MIT licensed header in the middle.

But yes, it is that easy. Well, if you want to use -lfoo instead of
dlopen(), you need libfoo.so too, not just foo.h. But the gist of it is that
with dynamic linking, the copyleft limitations of the GPL are trivial to
circumvent.

This is in fact, a good thing, because that shows that copyright is weak.
Remember that the GPL is not a good thing, it is an evil thing: using the
weapons of your enemies against them. If the weapons are weaker than
expected, so much the better.

> The GPL-3 requires that the 'Corresponding Source' of the distributed object 
> code
> is also distributed. This is defined as [1]:
> The “Corresponding Source” for a work in object code form means all the source
> code needed to generate, install, and (for an executable work) run the object
> code[...]

Remember that copyright is for works of art. Art has no obligation to work.
If you can run the program until it crashes with "error while loading shared
libraries", then technically it fulfills the requirements of the GPL.
Otherwise, you would be violating the GPL each time you make a bug.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 10.12.2015 19:48, Matt Oliver wrote:
> On 11 December 2015 at 04:23, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> On 10.12.2015 17:42, Matt Oliver wrote:
>>> Im not sure that Debian not including libcuda is a valid argument for it
>>> not being a system library as thats just one OS.
>>
>> The GPL defines a system library only in the context of a specific
>> operating system. So what is a system library differs from one OS to
>> another.
>> Therefore one can't just claim something is a system library and thus it's
>> fine to use it, unless specifying the specific OS one talks about.
>>
> 
> So does that mean that the discussion is not so much about whether it is a
> system lib or not but on what OSs it can be considered a system lib?

Yes, that's the relevant topic.

>> So I dont believe that just because
>>> some systems dont have it doesnt stop it from being a system library.
>>
>> You're treating being a system library as something OS-agnostic, which
>> it isn't. A library can be a system library on Windows, but not on Android.
>>
>> Whether or not it's a system library on Windows doesn't matter for any
>> other OS.
>>
> 
> OK so by that logic does that mean we can say that it IS a system lib on
> Windows and is therefore GPL compliant?

If it is a system library on Windows (which I don't know), it is
GPL-compatible to distribute a FFmpeg binary for Windows with nvenc enabled.

> So then the issue becomes what OSs can we say it is a system lib on.
> If the option is disabled by default on
> these other OSs then would you agree that ffmpeg is remaining GPL compliant
> and its upto the OS distributors who enable the nvenc option when packaging
> ffmpeg to be doing so as they also have the appropriate nvenc system libs.

Yes, the FFmpeg project doesn't distribute binaries itself, only sources,
which is GPL compliant.
Thus nvenc is only a potential problem for distributors of compiled ffmpeg
binaries.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 10.12.2015 19:03, Nicolas George wrote:
> Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> I'm not sure it's that easy. If that were correct, it would become
>> GPL-compatible to distribute a GPL-licensed program linked with a
>> proprietary library by simply inserting a MIT licensed header in the middle.
> 
> But yes, it is that easy. Well, if you want to use -lfoo instead of
> dlopen(), you need libfoo.so too, not just foo.h.

Using the header, one could create a dummy libfoo.so containing only
stub functions.

> But the gist of it is that with dynamic linking, the copyleft limitations
> of the GPL are trivial to circumvent.

I don't think the FSF would agree [1].

> This is in fact, a good thing, because that shows that copyright is weak.
> Remember that the GPL is not a good thing, it is an evil thing: using the
> weapons of your enemies against them. If the weapons are weaker than
> expected, so much the better.

This is not about good or evil.

>> The GPL-3 requires that the 'Corresponding Source' of the distributed object 
>> code
>> is also distributed. This is defined as [1]:
>> The “Corresponding Source” for a work in object code form means all the 
>> source
>> code needed to generate, install, and (for an executable work) run the object
>> code[...]
> 
> Remember that copyright is for works of art. Art has no obligation to work.
> If you can run the program until it crashes with "error while loading shared
> libraries", then technically it fulfills the requirements of the GPL.
> Otherwise, you would be violating the GPL each time you make a bug.

The GPL does not require that programs can run, only that distributors
provide the source code of everything that is needed to run the program,
except system libraries.

So you can distribute e.g. a GPL binary linking with libfoo.so, without
distributing libfoo.so, as long as you distribute the source code
of libfoo.so.
However, claiming that libfoo.so is not required to run the binary
would be bizarre.

Best regards,
Andreas


1: https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> Using the header, one could create a dummy libfoo.so containing only
> stub functions.

Exactly.

> I don't think the FSF would agree [1].

They do not make the law. Claiming that the GPL enforces more than it can is
obviously their game.

> The GPL does not require that programs can run, only that distributors
> provide the source code of everything that is needed to run the program,
> except system libraries.
> 
> So you can distribute e.g. a GPL binary linking with libfoo.so, without
> distributing libfoo.so, as long as you distribute the source code
> of libfoo.so.
> However, claiming that libfoo.so is not required to run the binary
> would be bizarre.

Once again, exactly. I agree that having the program not work at all would
probably not be sustainable. But for an optional feature (a codec, for
example), having a GPL-compatible stub libfoo.so that just prints "feature
not available" is perfectly legal. And then, you just have to propose the
customers to download, on their own responsibility, a proprietary libfoo.so.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 10.12.2015 20:37, Nicolas George wrote:
> Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> Using the header, one could create a dummy libfoo.so containing only
>> stub functions.
> 
> Exactly.
> 
>> I don't think the FSF would agree [1].
> 
> They do not make the law.

Neither do you or I.

> Claiming that the GPL enforces more than it can is obviously their game.

Ultimately, the only definitive answer can come from a court decision,
which will hopefully not be needed here.

>> The GPL does not require that programs can run, only that distributors
>> provide the source code of everything that is needed to run the program,
>> except system libraries.
>>
>> So you can distribute e.g. a GPL binary linking with libfoo.so, without
>> distributing libfoo.so, as long as you distribute the source code
>> of libfoo.so.
>> However, claiming that libfoo.so is not required to run the binary
>> would be bizarre.
> 
> Once again, exactly. I agree that having the program not work at all would
> probably not be sustainable. But for an optional feature (a codec, for
> example), having a GPL-compatible stub libfoo.so that just prints "feature
> not available" is perfectly legal.

One could argue endlessly about where to draw the line...

On the other hand I think we agreed to not enable nvenc by default,
so lets just do it that way.

That leaves the question of whether or not to include the header,
but I have no strong opinion on that.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Matt Oliver]

On 11 December 2015 at 04:23, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> On 10.12.2015 17:42, Matt Oliver wrote:
> >>
> >> What is a system library depends on the system.
> >> For example, Debian (main) does not even include libcuda or
> >> libnvidia-encode, so they certainly cannot be system libraries
> there.
> >
> >>
> >
> > Im not sure that Debian not including libcuda is a valid argument for it
> > not being a system library as thats just one OS.
>
> The GPL defines a system library only in the context of a specific
> operating system. So what is a system library differs from one OS to
> another.
> Therefore one can't just claim something is a system library and thus it's
> fine to use it, unless specifying the specific OS one talks about.
>

So does that mean that the discussion is not so much about whether it is a
system lib or not but on what OSs it can be considered a system lib?

> To me thats the same as
> > saying that win32 stuff is not part of a system library because Debian
> > doesnt have it (for obvious reasons).
>
> That's not correct, because Debian does have wine. ;)
>

lol, good point, probably wasnt the best example to use (its very late here
so ill use that as an excuse for brain not working)

> So I dont believe that just because
> > some systems dont have it doesnt stop it from being a system library.
>
> You're treating being a system library as something OS-agnostic, which
> it isn't. A library can be a system library on Windows, but not on Android.
>
> Whether or not it's a system library on Windows doesn't matter for any
> other OS.
>

OK so by that logic does that mean we can say that it IS a system lib on
Windows and is therefore GPL compliant? So then the issue becomes what OSs
can we say it is a system lib on. If the option is disabled by default on
these other OSs then would you agree that ffmpeg is remaining GPL compliant
and its upto the OS distributors who enable the nvenc option when packaging
ffmpeg to be doing so as they also have the appropriate nvenc system libs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/8] avfilter/vf_overlay: fix memory leaks

[Ganesh Ajjanagadde]

On Thu, Dec 10, 2015 at 7:54 AM, Ganesh Ajjanagadde  wrote:
> On Thu, Dec 10, 2015 at 3:47 AM, Paul B Mahol  wrote:
>> On 12/10/15, Ganesh Ajjanagadde  wrote:
>>> On Wed, Dec 9, 2015 at 6:09 PM, Paul B Mahol  wrote:
 On 12/9/15, Ganesh Ajjanagadde  wrote:
> On Fri, Dec 4, 2015 at 9:39 AM, Ganesh Ajjanagadde
>  wrote:
>> Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and
>> 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning
>> up usage of the formats API, and in particular fixed possible NULL
>> pointer
>> dereferences.
>>
>> This commit addresses the issue of possible resource leaks when some
>> intermediate
>> call fails.
>>
>> Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual
>> simulation
>> of malloc/realloc failures.
>>
>> Fixes: CID 1338327.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/vf_overlay.c | 32 +++-
>>  1 file changed, 23 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
>> index 3c61731..68cfb1b 100644
>> --- a/libavfilter/vf_overlay.c
>> +++ b/libavfilter/vf_overlay.c
>> @@ -252,23 +252,31 @@ static int query_formats(AVFilterContext *ctx)
>>  switch (s->format) {
>>  case OVERLAY_FORMAT_YUV420:
>>  if (!(main_formats=
>> ff_make_format_list(main_pix_fmts_yuv420)) ||
>> -!(overlay_formats =
>> ff_make_format_list(overlay_pix_fmts_yuv420)))
>> -return AVERROR(ENOMEM);
>> +!(overlay_formats =
>> ff_make_format_list(overlay_pix_fmts_yuv420))) {
>> +ret = AVERROR(ENOMEM);
>> +goto fail;
>> +}
>>  break;
>>  case OVERLAY_FORMAT_YUV422:
>>  if (!(main_formats=
>> ff_make_format_list(main_pix_fmts_yuv422)) ||
>> -!(overlay_formats =
>> ff_make_format_list(overlay_pix_fmts_yuv422)))
>> -return AVERROR(ENOMEM);
>> +!(overlay_formats =
>> ff_make_format_list(overlay_pix_fmts_yuv422))) {
>> +ret = AVERROR(ENOMEM);
>> +goto fail;
>> +}
>>  break;
>>  case OVERLAY_FORMAT_YUV444:
>>  if (!(main_formats=
>> ff_make_format_list(main_pix_fmts_yuv444)) ||
>> -!(overlay_formats =
>> ff_make_format_list(overlay_pix_fmts_yuv444)))
>> -return AVERROR(ENOMEM);
>> +!(overlay_formats =
>> ff_make_format_list(overlay_pix_fmts_yuv444))) {
>> +ret = AVERROR(ENOMEM);
>> +goto fail;
>> +}
>>  break;
>>  case OVERLAY_FORMAT_RGB:
>>  if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb))
>> ||
>> -!(overlay_formats =
>> ff_make_format_list(overlay_pix_fmts_rgb)))
>> -return AVERROR(ENOMEM);
>> +!(overlay_formats =
>> ff_make_format_list(overlay_pix_fmts_rgb))) {
>> +ret = AVERROR(ENOMEM);
>> +goto fail;
>> +}
>>  break;
>>  default:
>>  av_assert0(0);
>> @@ -277,9 +285,15 @@ static int query_formats(AVFilterContext *ctx)
>>  if ((ret = ff_formats_ref(main_formats   ,
>> >inputs[MAIN]->out_formats   )) < 0 ||
>>  (ret = ff_formats_ref(overlay_formats,
>> >inputs[OVERLAY]->out_formats)) < 0 ||
>>  (ret = ff_formats_ref(main_formats   ,
>> >outputs[MAIN]->in_formats   )) < 0)
>> -return ret;
>> +goto fail;
>>
>>  return 0;
>> +fail:
>> +av_freep(_formats->formats);
>> +av_freep(_formats);
>> +av_freep(_formats->formats);
>> +av_freep(_formats);
>> +return ret;
>>  }
>>
>>  static const enum AVPixelFormat alpha_pix_fmts[] = {
>> --
>> 2.6.3
>>
>
> pushed, with the necessary modification described by Clement

 This tries to dereference uninitialized value.
>>>
>>> See right above; I did the desired modification and believe there is no
>>> issue.
>>> I might be wrong; but if so, could you please refer to the relevant
>>> cvslog message?
>>> Thanks.
>>
>> libavfilter/vf_overlay.c:275:13: warning: variable 'overlay_formats'
>> is used uninitialized whenever '||' condition is true
>> [-Wsometimes-uninitialized]
>> if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) ||
>> ^~~
>> libavfilter/vf_overlay.c:295:9: note: uninitialized use occurs here
>> 

Re: [FFmpeg-devel] [PATCH 1/8] avfilter/vf_overlay: fix memory leaks

[Paul B Mahol]

On 12/10/15, Ganesh Ajjanagadde  wrote:
> On Wed, Dec 9, 2015 at 6:09 PM, Paul B Mahol  wrote:
>> On 12/9/15, Ganesh Ajjanagadde  wrote:
>>> On Fri, Dec 4, 2015 at 9:39 AM, Ganesh Ajjanagadde
>>>  wrote:
 Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and
 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning
 up usage of the formats API, and in particular fixed possible NULL
 pointer
 dereferences.

 This commit addresses the issue of possible resource leaks when some
 intermediate
 call fails.

 Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual
 simulation
 of malloc/realloc failures.

 Fixes: CID 1338327.

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  libavfilter/vf_overlay.c | 32 +++-
  1 file changed, 23 insertions(+), 9 deletions(-)

 diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
 index 3c61731..68cfb1b 100644
 --- a/libavfilter/vf_overlay.c
 +++ b/libavfilter/vf_overlay.c
 @@ -252,23 +252,31 @@ static int query_formats(AVFilterContext *ctx)
  switch (s->format) {
  case OVERLAY_FORMAT_YUV420:
  if (!(main_formats=
 ff_make_format_list(main_pix_fmts_yuv420)) ||
 -!(overlay_formats =
 ff_make_format_list(overlay_pix_fmts_yuv420)))
 -return AVERROR(ENOMEM);
 +!(overlay_formats =
 ff_make_format_list(overlay_pix_fmts_yuv420))) {
 +ret = AVERROR(ENOMEM);
 +goto fail;
 +}
  break;
  case OVERLAY_FORMAT_YUV422:
  if (!(main_formats=
 ff_make_format_list(main_pix_fmts_yuv422)) ||
 -!(overlay_formats =
 ff_make_format_list(overlay_pix_fmts_yuv422)))
 -return AVERROR(ENOMEM);
 +!(overlay_formats =
 ff_make_format_list(overlay_pix_fmts_yuv422))) {
 +ret = AVERROR(ENOMEM);
 +goto fail;
 +}
  break;
  case OVERLAY_FORMAT_YUV444:
  if (!(main_formats=
 ff_make_format_list(main_pix_fmts_yuv444)) ||
 -!(overlay_formats =
 ff_make_format_list(overlay_pix_fmts_yuv444)))
 -return AVERROR(ENOMEM);
 +!(overlay_formats =
 ff_make_format_list(overlay_pix_fmts_yuv444))) {
 +ret = AVERROR(ENOMEM);
 +goto fail;
 +}
  break;
  case OVERLAY_FORMAT_RGB:
  if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb))
 ||
 -!(overlay_formats =
 ff_make_format_list(overlay_pix_fmts_rgb)))
 -return AVERROR(ENOMEM);
 +!(overlay_formats =
 ff_make_format_list(overlay_pix_fmts_rgb))) {
 +ret = AVERROR(ENOMEM);
 +goto fail;
 +}
  break;
  default:
  av_assert0(0);
 @@ -277,9 +285,15 @@ static int query_formats(AVFilterContext *ctx)
  if ((ret = ff_formats_ref(main_formats   ,
 >inputs[MAIN]->out_formats   )) < 0 ||
  (ret = ff_formats_ref(overlay_formats,
 >inputs[OVERLAY]->out_formats)) < 0 ||
  (ret = ff_formats_ref(main_formats   ,
 >outputs[MAIN]->in_formats   )) < 0)
 -return ret;
 +goto fail;

  return 0;
 +fail:
 +av_freep(_formats->formats);
 +av_freep(_formats);
 +av_freep(_formats->formats);
 +av_freep(_formats);
 +return ret;
  }

  static const enum AVPixelFormat alpha_pix_fmts[] = {
 --
 2.6.3

>>>
>>> pushed, with the necessary modification described by Clement
>>
>> This tries to dereference uninitialized value.
>
> See right above; I did the desired modification and believe there is no
> issue.
> I might be wrong; but if so, could you please refer to the relevant
> cvslog message?
> Thanks.

libavfilter/vf_overlay.c:275:13: warning: variable 'overlay_formats'
is used uninitialized whenever '||' condition is true
[-Wsometimes-uninitialized]
if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) ||
^~~
libavfilter/vf_overlay.c:295:9: note: uninitialized use occurs here
if (overlay_formats)
^~~
libavfilter/vf_overlay.c:275:13: note: remove the '||' if its
condition is always false
if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) ||
^~
libavfilter/vf_overlay.c:268:13: warning: variable 'overlay_formats'
is used uninitialized whenever '||' condition is true

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Hendrik Leppkes]

On Thu, Dec 10, 2015 at 10:16 AM, Sven Dueking  wrote:
> This patch expose 3 QSV functions as public.
> This is needed because the VPP needs access to these functions too.
>
> Please review.
>

public API is not allowed to use config.h, it needs to be config and
OS agnostic.

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

Re: [FFmpeg-devel] Detecting invalid filter parameters

[Jean Delvare]

On Thu, 10 Dec 2015 08:58:05 +0100, Nicolas George wrote:
> Le decadi 20 frimaire, an CCXXIV, Jean Delvare a écrit :
> > This brings two additional questions:
> > 
> > 1* Can a filter declare which midstream changes it does or does not
> > support?
> > 
> > 2* Can a filter be called back on midstream changes, or does it have to
> > detect it by itself?
> 
> Midstream changes are not supported yet at all. They work by chance for a
> few selected whitelisted filters, that is all. No need to worry yet.

OK, thanks. That will make things easier. I'll write down a note before
the checks on what would need to be done if support is ever added.

-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mov: Enable parser for mp3s by old HandBrake

[Moritz Barsnick]

On Wed, Dec 09, 2015 at 22:24:08 +0100, Michael Niedermayer wrote:
> +if (sscanf(str, "HandBrake %d.%d.%d", , , ) == 
> 3) {
> +c->handbrake_version = 100*major + 1000*minor + micro;
[...]
> +if (mov->handbrake_version &&
> +mov->handbrake_version <= 100*0 + 1000*10 + 0 &&

Really hard to read for all the '1's and '0'. You're checking for "<=
0.10.0"? Perhaps better to clearly document that.

So starting with 0.10.1, behavior is different?

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

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Ivan Uskov]

Hello Hendrik,

Thursday, December 10, 2015, 12:19:23 PM, you wrote:

HL> On Thu, Dec 10, 2015 at 10:16 AM, Sven Dueking  wrote:
>> This patch expose 3 QSV functions as public.
>> This is needed because the VPP needs access to these functions too.
>>
>> Please review.
>>

HL> public API is not allowed to use config.h, it needs to be config and
HL> OS agnostic.
Any qsv_* function can not be public since are all under CONFIG_QSV, correct?

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

[FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Sven Dueking]

This patch expose 3 QSV functions as public. 
This is needed because the VPP needs access to these functions too.

Please review.

Thanks,
Sven


0001-make-some-internal-QSV-routines-public.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] diracdec: Fix FPE on invalid low_delay data

[Michael Niedermayer]

On Wed, Dec 09, 2015 at 12:56:02AM +, Kieran Kunhya wrote:
> ---
>  libavcodec/diracdec.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
> index 6a53f38..0542ad7 100644
> --- a/libavcodec/diracdec.c
> +++ b/libavcodec/diracdec.c
> @@ -2043,6 +2043,11 @@ static int dirac_decode_data_unit(AVCodecContext 
> *avctx, const uint8_t *buf, int
>  if (s->version.minor == 2 && parse_code == 0x88)
>  s->ld_picture = 1;
>  
> +if (s->low_delay && !(s->ld_picture || s->hq_picture) ) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid low delay flag\n");
> +return AVERROR_INVALIDDATA;
> +}

this should be merged with the patch needing this bugfix or commited
before it

LGTM

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avutil/random_seed: use arc4random() when available

[Ganesh Ajjanagadde]

On Wed, Dec 9, 2015 at 8:08 AM, Ganesh Ajjanagadde
 wrote:
> On Sun, Dec 6, 2015 at 10:56 PM, Ganesh Ajjanagadde
>  wrote:
>> arc4random() was designed as a superior interface for system random
>> number generation, designed for OpenBSD. It is thus an improvement to
>> use it whenever available.
>>
>> As a side note, this may or may not get included in glibc, and there is
>> a proposal to create a posix_random family based on these ideas:
>> http://austingroupbugs.net/view.php?id=859.
>>
>> Untested as I lack OpenBSD.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  configure   | 2 ++
>>  libavutil/random_seed.c | 4 
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/configure b/configure
>> index 7530c88..e676269 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1840,6 +1840,7 @@ MATH_FUNCS="
>>  SYSTEM_FUNCS="
>>  access
>>  aligned_malloc
>> +arc4random
>>  clock_gettime
>>  closesocket
>>  CommandLineToArgvW
>> @@ -5218,6 +5219,7 @@ check_func  ${malloc_prefix}memalign&& 
>> enable memalign
>>  check_func  ${malloc_prefix}posix_memalign  && enable posix_memalign
>>
>>  check_func  access
>> +check_func  arc4random
>>  check_func_headers time.h clock_gettime || { check_func_headers time.h 
>> clock_gettime -lrt && add_extralibs -lrt && LIBRT="-lrt"; }
>>  check_func  fcntl
>>  check_func  fork
>> diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
>> index 8aa8c38..205a636 100644
>> --- a/libavutil/random_seed.c
>> +++ b/libavutil/random_seed.c
>> @@ -121,6 +121,10 @@ uint32_t av_get_random_seed(void)
>>  }
>>  #endif
>>
>> +#if HAVE_ARC4RANDOM
>> +return arc4random();
>> +#endif
>> +
>>  if (read_random(, "/dev/urandom") == sizeof(seed))
>>  return seed;
>>  if (read_random(, "/dev/random")  == sizeof(seed))
>> --
>> 2.6.3
>>
>
> any objections to this: all objections so far have been for 2/2, i.e
> for the more controversial one that harnesses libbsd for non-native
> functionality?

To clarify, none of wm4's comments apply here. It will provide
benefits not just to OpenBSD, but also to other BSD's, Mac OS X, and
some alternative libc's (not glibc, which refused and continues to
refuse arc4random).

@Ronald, or anyone else with a Mac: can you please try at least a build test?

I have now shelved 2/2, as it has got drawn into a stalemate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avformat/mpegtsenc: Add basic multi program support

[Michael Niedermayer]

From: Michael Niedermayer 

Signed-off-by: Michael Niedermayer 
---
 libavformat/mpegtsenc.c |   57 ++-
 1 file changed, 42 insertions(+), 15 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 055e441..19032f3 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -273,6 +273,12 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 MpegTSWriteStream *ts_st = st->priv_data;
 AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", NULL, 
0);
 
+if (s->nb_programs) {
+AVProgram *program = av_find_program_from_stream(s, NULL, i);
+if (program->id != service->sid)
+continue;
+}
+
 if (q - data > SECTION_LENGTH - 32) {
 err = 1;
 break;
@@ -719,22 +725,43 @@ static int mpegts_write_header(AVFormatContext *s)
 
 ts->tsid = ts->transport_stream_id;
 ts->onid = ts->original_network_id;
-/* allocate a single DVB service */
-title = av_dict_get(s->metadata, "service_name", NULL, 0);
-if (!title)
-title = av_dict_get(s->metadata, "title", NULL, 0);
-service_name  = title ? title->value : DEFAULT_SERVICE_NAME;
-provider  = av_dict_get(s->metadata, "service_provider", NULL, 0);
-provider_name = provider ? provider->value : DEFAULT_PROVIDER_NAME;
-service   = mpegts_add_service(ts, ts->service_id,
-   provider_name, service_name);
-
-if (!service)
-return AVERROR(ENOMEM);
+if (!s->nb_programs) {
+/* allocate a single DVB service */
+title = av_dict_get(s->metadata, "service_name", NULL, 0);
+if (!title)
+title = av_dict_get(s->metadata, "title", NULL, 0);
+service_name  = title ? title->value : DEFAULT_SERVICE_NAME;
+provider  = av_dict_get(s->metadata, "service_provider", NULL, 0);
+provider_name = provider ? provider->value : DEFAULT_PROVIDER_NAME;
+service   = mpegts_add_service(ts, ts->service_id,
+   provider_name, service_name);
+
+if (!service)
+return AVERROR(ENOMEM);
+
+service->pmt.write_packet = section_write_packet;
+service->pmt.opaque   = s;
+service->pmt.cc   = 15;
+} else {
+for (i = 0; i < s->nb_programs; i++) {
+AVProgram *program = s->programs[i];
+title = av_dict_get(program->metadata, "service_name", NULL, 0);
+if (!title)
+title = av_dict_get(program->metadata, "title", NULL, 0);
+service_name  = title ? title->value : DEFAULT_SERVICE_NAME;
+provider  = av_dict_get(program->metadata, "service_provider", 
NULL, 0);
+provider_name = provider ? provider->value : DEFAULT_PROVIDER_NAME;
+service   = mpegts_add_service(ts, program->id,
+   provider_name, service_name);
+
+if (!service)
+return AVERROR(ENOMEM);
 
-service->pmt.write_packet = section_write_packet;
-service->pmt.opaque   = s;
-service->pmt.cc   = 15;
+service->pmt.write_packet = section_write_packet;
+service->pmt.opaque   = s;
+service->pmt.cc   = 15;
+}
+}
 
 ts->pat.pid  = PAT_PID;
 /* Initialize at 15 so that it wraps and is equal to 0 for the
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/3] avformat: Add av_program_add_stream_index()

[Michael Niedermayer]

From: Michael Niedermayer 

This will be used by the subsequent commit(s)

Signed-off-by: Michael Niedermayer 
---
 doc/APIchanges |3 +++
 libavformat/avformat.h |2 ++
 libavformat/hls.c  |2 +-
 libavformat/internal.h |2 --
 libavformat/mpegts.c   |4 ++--
 libavformat/utils.c|2 +-
 6 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 5b91bb4..499bff8 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2015-08-28
 
 
 API changes, most recent first:
+2015-12-XX - xxx - lavf xx.xx.xxx - avformat.h
+  Add av_program_add_stream_index()
+
 2015-11-29 - xxx - lavc 57.16.101 - avcodec.h
   Deprecate rtp_callback without replacement, i.e. it won't be possible to
   get image slices before the full frame is encoded any more. The libavformat
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 36f9d02..ddf07b1 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2114,6 +2114,8 @@ int avformat_find_stream_info(AVFormatContext *ic, 
AVDictionary **options);
  */
 AVProgram *av_find_program_from_stream(AVFormatContext *ic, AVProgram *last, 
int s);
 
+void av_program_add_stream_index(AVFormatContext *ac, int progid, unsigned int 
idx);
+
 /**
  * Find the "best" stream in the file.
  * The best stream is determined according to various heuristics as the most
diff --git a/libavformat/hls.c b/libavformat/hls.c
index ccae270..2d4ee13 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1668,7 +1668,7 @@ static int hls_read_header(AVFormatContext *s)
 for (k = 0; k < pls->ctx->nb_streams; k++) {
 struct AVStream *st = s->streams[pls->stream_offset + k];
 
-ff_program_add_stream_index(s, i, pls->stream_offset + k);
+av_program_add_stream_index(s, i, pls->stream_offset + k);
 
 /* Set variant_bitrate for streams unique to this variant */
 if (!is_shared && v->bandwidth)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 90f0a61..4297cb8 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -156,8 +156,6 @@ char *ff_data_to_hex(char *buf, const uint8_t *src, int 
size, int lowercase);
  */
 int ff_hex_to_data(uint8_t *data, const char *p);
 
-void ff_program_add_stream_index(AVFormatContext *ac, int progid, unsigned int 
idx);
-
 /**
  * Add packet to AVFormatContext->packet_buffer list, determining its
  * interleaved position using compare() function argument.
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 4a6a5e5..7a905a4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1958,7 +1958,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 
 add_pid_to_pmt(ts, h->id, pid);
 
-ff_program_add_stream_index(ts->stream, h->id, st->index);
+av_program_add_stream_index(ts->stream, h->id, st->index);
 
 desc_list_len = get16(, p_end);
 if (desc_list_len < 0)
@@ -1975,7 +1975,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 
 if (pes && prog_reg_desc == AV_RL32("HDMV") &&
 stream_type == 0x83 && pes->sub_st) {
-ff_program_add_stream_index(ts->stream, h->id,
+av_program_add_stream_index(ts->stream, h->id,
 pes->sub_st->index);
 pes->sub_st->codec->codec_tag = st->codec->codec_tag;
 }
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 1103a64..2f864c6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3915,7 +3915,7 @@ AVChapter *avpriv_new_chapter(AVFormatContext *s, int id, 
AVRational time_base,
 return chapter;
 }
 
-void ff_program_add_stream_index(AVFormatContext *ac, int progid, unsigned idx)
+void av_program_add_stream_index(AVFormatContext *ac, int progid, unsigned idx)
 {
 int i, j;
 AVProgram *program = NULL;
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 08/11] diracdec: Support new extended quantiser range

[Michael Niedermayer]

On Wed, Dec 09, 2015 at 12:05:34AM +, Kieran Kunhya wrote:
> ---
>  libavcodec/diracdec.c | 58 
> ---
>  1 file changed, 37 insertions(+), 21 deletions(-)

LGTM

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] ffmpeg: Add basic support to mux multiple programs

[Michael Niedermayer]

From: Michael Niedermayer 

TODO: add docs

Signed-off-by: Michael Niedermayer 
---
 ffmpeg.h |2 ++
 ffmpeg_opt.c |   38 ++
 2 files changed, 40 insertions(+)

diff --git a/ffmpeg.h b/ffmpeg.h
index 82ab1ee..fa24910 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -216,6 +216,8 @@ typedef struct OptionsContext {
 intnb_discard;
 SpecifierOpt *disposition;
 intnb_disposition;
+SpecifierOpt *program;
+intnb_program;
 } OptionsContext;
 
 typedef struct InputFilter {
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 131dd89..0102113 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -2414,6 +2414,42 @@ loop_end:
 }
 }
 
+/* process manually set programs */
+for (i = 0; i < o->nb_program; i++) {
+const char *p = o->program[i].u.str;
+int progid = i+1;
+AVProgram *program = av_new_program(oc, progid);
+
+while(*p) {
+const char *p2 = av_get_token(, ":");
+char *key;
+if (!p2)
+break;
+if(*p) p++;
+
+key = av_get_token(, "=");
+if (!key) {
+av_log(NULL, AV_LOG_FATAL,
+   "No '=' character in program string %s.\n",
+   p2);
+exit_program(1);
+}
+if (!*p2)
+exit_program(1);
+p2++;
+
+if (!strcmp(key, "title")) {
+av_dict_set(>metadata, "title", p2, 0);
+} else if (!strcmp(key, "st")) {
+int st_num = strtol(p2, NULL, 0);
+av_program_add_stream_index(oc, progid, st_num);
+} else {
+av_log(NULL, AV_LOG_FATAL, "Unknown program key %s.\n", key);
+exit_program(1);
+}
+}
+}
+
 return 0;
 }
 
@@ -3093,6 +3129,8 @@ const OptionDef options[] = {
 "set the recording timestamp ('now' to set the current time)", "time" 
},
 { "metadata",   HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, { .off = 
OFFSET(metadata) },
 "add metadata", "string=string" },
+{ "program",HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, { .off = 
OFFSET(program) },
+"add program with specified streams", "string=name:st0:st1:..." },
 { "dframes",HAS_ARG | OPT_PERFILE | OPT_EXPERT |
 OPT_OUTPUT,  { 
.func_arg = opt_data_frames },
 "set the number of data frames to output", "number" },
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 10/11] diracdec: Read picture types by using parse_code

[Michael Niedermayer]

On Wed, Dec 09, 2015 at 12:05:36AM +, Kieran Kunhya wrote:
> ---
>  libavcodec/diracdec.c | 57 
> +--
>  1 file changed, 42 insertions(+), 15 deletions(-)

should be ok

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

On Fri, Dec 11, 2015 at 12:03 AM, Carl Eugen Hoyos  wrote:
> On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
>> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>>
>>  die_license_disabled nonfree libaacplus
>>  die_license_disabled nonfree libfaac
>> -die_license_disabled nonfree nvenc
>
> Sorry, but this makes absolutely no sense imo:
> I asked you if nvenc is a system library and your answer did
> not indicate that you are certain it is a system library (and
> I did ask you if I maybe misunderstood your answer),
>
> If it is not a system library, you must not remove this line.
>
> If it is a system library, please enable auto-detection as we
> already have enough untested features and as we generally do
> autodetect system libraries.
>

You should read the entire discussion, we have already touched on all
of these points.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c

[Mats Peterson]

I'm not very versed at (or planning to become) using Git and its utilites, 
that's why I provide a patch here for you to examine. I hope this approach is 
accepted. And although it's about two different issues, they are both 
concerning the same file, i.e. matroskadec.c.
Mats
 -- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
  From: Michael Niedermayer 
 To: FFmpeg development discussions and patches  
 Sent: Friday, December 11, 2015 1:30 AM
 Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound 
sample descriptions and store the palette in matroskadec.c
   
On Thu, Dec 10, 2015 at 11:06:58AM +, Mats Peterson wrote:


> I've attached a unified diff of the latest Git version of matroskadec.c that 
> does two things:
> 1. It allows FFmpeg to recognize QuickTime version 0 sound sample 
> descriptions by using 36 instead of 86 as the minimum private data size for 
> A_QUICKTIME.
> 2. The palette, in QuickTime video that has one, is put in extradata, to make 
> MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER.
> This patch is an improvement and tidying-up of a proposed patch by Martin 
> Storsjö, for the record. The version 0 sound sample description stuff is made 
> by me long ago, though.
> 
> Comments welcome.

This sounds like 2 independant changes
each independant change should be in its own patch and commit.
you can easily split changes into commits with git add -p and
git commit
this also produces git compatible patches with commit messages
(with git format-patch or git send-email)

[...]

-- 
Michael    GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c

[Hendrik Leppkes]

On Thu, Dec 10, 2015 at 12:06 PM, Mats Peterson
 wrote:
> I've attached a unified diff of the latest Git version of matroskadec.c that 
> does two things:
> 1. It allows FFmpeg to recognize QuickTime version 0 sound sample 
> descriptions by using 36 instead of 86 as the minimum private data size for 
> A_QUICKTIME.
> 2. The palette, in QuickTime video that has one, is put in extradata, to make 
> MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER.
> This patch is an improvement and tidying-up of a proposed patch by Martin 
> Storsjö, for the record. The version 0 sound sample description stuff is made 
> by me long ago, though.
>

This is an extremely ugly hack. Replacing priv_data and calling into
the mov demuxer? Rather come up with a better solution without the
potential for a whole load of side-effects.

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

[FFmpeg-devel] [PATCH 2/3] x86/hevc_sao: simplify sao_edge_filter 10/12bit

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/x86/hevc_sao_10bit.asm | 150 ++
 1 file changed, 54 insertions(+), 96 deletions(-)

diff --git a/libavcodec/x86/hevc_sao_10bit.asm 
b/libavcodec/x86/hevc_sao_10bit.asm
index 3a7048a..79776ac 100644
--- a/libavcodec/x86/hevc_sao_10bit.asm
+++ b/libavcodec/x86/hevc_sao_10bit.asm
@@ -221,46 +221,6 @@ HEVC_SAO_BAND_FILTER 12, 64, 4
 addb_strideq, tmpq
 %endmacro
 
-%macro HEVC_SAO_EDGE_FILTER_COMPUTE 0
-PMINUWm4, m1, m2, m6
-PMINUWm5, m1, m3, m7
-pcmpeqw   m2, m4
-pcmpeqw   m3, m5
-pcmpeqw   m4, m1
-pcmpeqw   m5, m1
-psubw m4, m2
-psubw m5, m3
-
-paddw m4, m5
-pcmpeqw   m2, m4, [pw_m2]
-%if ARCH_X86_64
-pcmpeqw   m3, m4, m13
-pcmpeqw   m5, m4, m0
-pcmpeqw   m6, m4, m14
-pcmpeqw   m7, m4, m15
-pand  m2, m8
-pand  m3, m9
-pand  m5, m10
-pand  m6, m11
-pand  m7, m12
-%else
-pcmpeqw   m3, m4, [pw_m1]
-pcmpeqw   m5, m4, m0
-pcmpeqw   m6, m4, [pw_1]
-pcmpeqw   m7, m4, [pw_2]
-pand  m2, [rsp+MMSIZE*0]
-pand  m3, [rsp+MMSIZE*1]
-pand  m5, [rsp+MMSIZE*2]
-pand  m6, [rsp+MMSIZE*3]
-pand  m7, [rsp+MMSIZE*4]
-%endif
-paddw m2, m3
-paddw m5, m6
-paddw m2, m7
-paddw m2, m1
-paddw m2, m5
-%endmacro
-
 ;void ff_hevc_sao_edge_filter___(uint8_t *_dst, uint8_t 
*_src, ptrdiff_t stride_dst, int16_t *sao_offset_val,
 ;   int eo, int width, int 
height);
 %macro HEVC_SAO_EDGE_FILTER 3
@@ -274,7 +234,6 @@ cglobal hevc_sao_edge_filter_%2_%1, 4, 9, 16, dst, src, 
dststride, offset, eo, a
 
 %else ; ARCH_X86_32
 cglobal hevc_sao_edge_filter_%2_%1, 1, 6, 8, 5*mmsize, dst, src, dststride, 
a_stride, b_stride, height
-%assign MMSIZE mmsize
 %define eoq   srcq
 %define tmpq  heightq
 %define tmp2q dststrideq
@@ -325,54 +284,53 @@ cglobal hevc_sao_edge_filter_%2_%1, 1, 6, 8, 5*mmsize, 
dst, src, dststride, a_st
 align 16
 .loop:
 
-%if %2 == 8
-mova  m1, [srcq]
-movu  m2, [srcq+a_strideq]
-movu  m3, [srcq+b_strideq]
-
-HEVC_SAO_EDGE_FILTER_COMPUTE
-CLIPW m2, m0, [pw_mask %+ %1]
-movu  [dstq], m2
-%endif
-
 %assign i 0
 %rep %3
 mova  m1, [srcq + i]
 movu  m2, [srcq+a_strideq + i]
 movu  m3, [srcq+b_strideq + i]
-HEVC_SAO_EDGE_FILTER_COMPUTE
-CLIPW m2, m0, [pw_mask %+ %1]
-mova  [dstq + i], m2
+PMINUWm4, m1, m2, m6
+PMINUWm5, m1, m3, m7
+pcmpeqw   m2, m4
+pcmpeqw   m3, m5
+pcmpeqw   m4, m1
+pcmpeqw   m5, m1
+psubw m4, m2
+psubw m5, m3
 
-mova  m1, [srcq + i + mmsize]
-movu  m2, [srcq+a_strideq + i + mmsize]
-movu  m3, [srcq+b_strideq + i + mmsize]
-HEVC_SAO_EDGE_FILTER_COMPUTE
+paddw m4, m5
+pcmpeqw   m2, m4, [pw_m2]
+%if ARCH_X86_64
+pcmpeqw   m3, m4, m13
+pcmpeqw   m5, m4, m0
+pcmpeqw   m6, m4, m14
+pcmpeqw   m7, m4, m15
+pand  m2, m8
+pand  m3, m9
+pand  m5, m10
+pand  m6, m11
+pand  m7, m12
+%else
+pcmpeqw   m3, m4, [pw_m1]
+pcmpeqw   m5, m4, m0
+pcmpeqw   m6, m4, [pw_1]
+pcmpeqw   m7, m4, [pw_2]
+pand  m2, [rsp+mmsize*0]
+pand  m3, [rsp+mmsize*1]
+pand  m5, [rsp+mmsize*2]
+pand  m6, [rsp+mmsize*3]
+pand  m7, [rsp+mmsize*4]
+%endif
+paddw m2, m3
+paddw m5, m6
+paddw m2, m7
+paddw m2, m1
+paddw m2, m5
 CLIPW m2, m0, [pw_mask %+ %1]
-mova [dstq + i + mmsize], m2
-%assign i i+mmsize*2
+mova  [dstq + i], m2
+%assign i i+mmsize
 %endrep
 
-%if %2 == 48
-INIT_XMM cpuname
-mova  m1, [srcq + i]
-movu  m2, [srcq+a_strideq + i]
-movu  m3, [srcq+b_strideq + i]
-HEVC_SAO_EDGE_FILTER_COMPUTE
-CLIPW m2, m0, [pw_mask %+ %1]
-mova  [dstq + i], m2
-
-mova  m1, [srcq + i + mmsize]
-movu  m2, [srcq+a_strideq + i + mmsize]
-movu  m3, [srcq+b_strideq + i + mmsize]
-HEVC_SAO_EDGE_FILTER_COMPUTE
-CLIPW m2, m0, [pw_mask %+ %1]
-mova [dstq + i + mmsize], m2
-%if cpuflag(avx2)
-INIT_YMM 

[FFmpeg-devel] [PATCH 3/3] x86/hevc_sao: add ff_hevc_sao_edge_filter_{8, 16}_{10, 12}

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/x86/hevc_sao_10bit.asm | 9 -
 libavcodec/x86/hevcdsp_init.c | 8 ++--
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/libavcodec/x86/hevc_sao_10bit.asm 
b/libavcodec/x86/hevc_sao_10bit.asm
index 79776ac..f81e2d5 100644
--- a/libavcodec/x86/hevc_sao_10bit.asm
+++ b/libavcodec/x86/hevc_sao_10bit.asm
@@ -252,7 +252,7 @@ cglobal hevc_sao_edge_filter_%2_%1, 1, 6, 8, 5*mmsize, dst, 
src, dststride, a_st
 
 %endif ; ARCH
 
-%if cpuflag(avx2)
+%if mmsize > 16
 SPLATWm8, [offsetq+2]
 SPLATWm9, [offsetq+4]
 SPLATW   m10, [offsetq+0]
@@ -352,11 +352,18 @@ HEVC_SAO_EDGE_FILTER 12, 48, 6
 HEVC_SAO_EDGE_FILTER 12, 64, 8
 
 %if HAVE_AVX2_EXTERNAL
+INIT_XMM avx2
+HEVC_SAO_EDGE_FILTER 10,  8, 1
 INIT_YMM avx2
+HEVC_SAO_EDGE_FILTER 10, 16, 1
 HEVC_SAO_EDGE_FILTER 10, 32, 2
 HEVC_SAO_EDGE_FILTER 10, 48, 3
 HEVC_SAO_EDGE_FILTER 10, 64, 4
 
+INIT_XMM avx2
+HEVC_SAO_EDGE_FILTER 12,  8, 1
+INIT_YMM avx2
+HEVC_SAO_EDGE_FILTER 12, 16, 1
 HEVC_SAO_EDGE_FILTER 12, 32, 2
 HEVC_SAO_EDGE_FILTER 12, 48, 3
 HEVC_SAO_EDGE_FILTER 12, 64, 4
diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
index 2181f6d..0de0163 100644
--- a/libavcodec/x86/hevcdsp_init.c
+++ b/libavcodec/x86/hevcdsp_init.c
@@ -1045,9 +1045,7 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int 
bit_depth)
 c->put_hevc_qpel_bi[9][1][1] = 
ff_hevc_put_hevc_bi_qpel_hv64_10_avx2;
 }
 SAO_BAND_INIT(10, avx2);
-c->sao_edge_filter[2] = ff_hevc_sao_edge_filter_32_10_avx2;
-c->sao_edge_filter[3] = ff_hevc_sao_edge_filter_48_10_avx2;
-c->sao_edge_filter[4] = ff_hevc_sao_edge_filter_64_10_avx2;
+SAO_EDGE_INIT(10, avx2);
 
 c->transform_add[2] = ff_hevc_transform_add16_10_avx2;
 c->transform_add[3] = ff_hevc_transform_add32_10_avx2;
@@ -1101,9 +1099,7 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int 
bit_depth)
 c->idct_dc[3] = ff_hevc_idct32x32_dc_12_avx2;
 
 SAO_BAND_INIT(12, avx2);
-c->sao_edge_filter[2] = ff_hevc_sao_edge_filter_32_12_avx2;
-c->sao_edge_filter[3] = ff_hevc_sao_edge_filter_48_12_avx2;
-c->sao_edge_filter[4] = ff_hevc_sao_edge_filter_64_12_avx2;
+SAO_EDGE_INIT(12, avx2);
 }
 }
 }
-- 
2.6.3

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

Re: [FFmpeg-devel] [PATCH]lavc/libvo-aac: Mark the encoder as experimental

[Carl Eugen Hoyos]

On Wednesday 09 December 2015 09:24:06 pm Hendrik Leppkes wrote:
> On Wed, Dec 9, 2015 at 7:09 PM, James Almer  wrote:
> > On 12/5/2015 9:31 PM, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> I prefer attached patch over removing the encoder immediately.

> And its quality is horrible.
>
> No idea why we would mark it experimental however. The built-in
> encoder will always take precedence, so a user has to explicitly
> request it as it is.

I am thinking of the many scripts using libvo-aac and the many 
users who automatically request it with -c:a whenever they encode 
aac.

I will commit in a few days if there are no objections.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] aacsbr: ensure strictly monotone time borders

[Andreas Cadhalpun]

On 02.12.2015 20:57, Andreas Cadhalpun wrote:
> On 08.11.2015 22:04, Andreas Cadhalpun wrote:
>> This fixes a SIGFPE crash in the aac_fixed decoder.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/aacsbr_template.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
>> index 66f4159..f69d2f8 100644
>> --- a/libavcodec/aacsbr_template.c
>> +++ b/libavcodec/aacsbr_template.c
>> @@ -718,8 +718,8 @@ static int read_sbr_grid(AACContext *ac, 
>> SpectralBandReplication *sbr,
>>  }
>>  
>>  for (i = 1; i <= ch_data->bs_num_env; i++) {
>> -if (ch_data->t_env[i-1] > ch_data->t_env[i]) {
>> -av_log(ac->avctx, AV_LOG_ERROR, "Non monotone time borders\n");
>> +if (ch_data->t_env[i-1] >= ch_data->t_env[i]) {
>> +av_log(ac->avctx, AV_LOG_ERROR, "Not strictly monotone time 
>> borders\n");
>>  return -1;
>>  }
>>  }
>>
> 
> Ping.
> 
> Unless there are objections, I'll push this soon, as it fixes crashes.

I pushed this now.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] sbr_qmf_analysis: sanitize input for 32-bit imdct

[Andreas Cadhalpun]

On 02.12.2015 20:58, Andreas Cadhalpun wrote:
> On 19.11.2015 01:02, Andreas Cadhalpun wrote:
>> If the input contains too many too large values, the imdct can overflow.
>> Even if it didn't, the output would be larger than the valid range of 29
>> bits.
>>
>> Note that this is a very delicate limit: Allowing values up to 1<<25
>> does not prevent input larger than 1<<29 from arriving at
>> sbr_sum_square, while limiting values to 1<<23 breaks the
>> fate-aac-fixed-al_sbr_hq_cm_48_5.1 test.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>
>> Nedeljko, do you have an explanation why larger input values here
>> are invalid?
>>
>> By the way, the imdct calculations in imdct_and_windowing and
>> sbr_qmf_synthesis can also overflow, so maybe need a similar check.
>>
>> ---
>>  libavcodec/aacsbr_template.c | 18 ++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
>> index 66f4159..f48ddd0 100644
>> --- a/libavcodec/aacsbr_template.c
>> +++ b/libavcodec/aacsbr_template.c
>> @@ -1153,6 +1153,9 @@ static void sbr_qmf_analysis(AVFloatDSPContext *dsp, 
>> FFTContext *mdct,
>>   INTFLOAT z[320], INTFLOAT W[2][32][32][2], int 
>> buf_idx)
>>  {
>>  int i;
>> +#if USE_FIXED
>> +int j;
>> +#endif
>>  memcpy(x, x+1024, (320-32)*sizeof(x[0]));
>>  memcpy(x+288, in, 1024*sizeof(x[0]));
>>  for (i = 0; i < 32; i++) { // numTimeSlots*RATE = 16*2 as 960 sample 
>> frames
>> @@ -1160,6 +1163,21 @@ static void sbr_qmf_analysis(AVFloatDSPContext *dsp, 
>> FFTContext *mdct,
>>  dsp->vector_fmul_reverse(z, sbr_qmf_window_ds, x, 320);
>>  sbrdsp->sum64x5(z);
>>  sbrdsp->qmf_pre_shuffle(z);
>> +#if USE_FIXED
>> +for (j = 64; j < 128; j++) {
>> +if (z[j] > 1<<24) {
>> +av_log(NULL, AV_LOG_WARNING,
>> +   "sbr_qmf_analysis: value %09d too large, setting to 
>> %09d\n",
>> +   z[j], 1<<24);
>> +z[j] = 1<<24;
>> +} else if (z[j] < -(1<<24)) {
>> +av_log(NULL, AV_LOG_WARNING,
>> +   "sbr_qmf_analysis: value %09d too small, setting to 
>> %09d\n",
>> +   z[j], -(1<<24));
>> +z[j] = -(1<<24);
>> +}
>> +}
>> +#endif
>>  mdct->imdct_half(mdct, z, z+64);
>>  sbrdsp->qmf_post_shuffle(W[buf_idx][i], z);
>>  x += 32;
>>
> 
> Ping.
> 
> If nobody objects, I'll push this soon, as it fixes crashes.

I pushed this now.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aac_fixed: fix overflow in sbr_sum_square_c

[Andreas Cadhalpun]

On 02.12.2015 20:58, Andreas Cadhalpun wrote:
> On 19.11.2015 01:01, Andreas Cadhalpun wrote:
>> Subject: [PATCH] sbrdsp_fixed: assert that input values for sbr_sum_square_c
>>  are valid
>>
>> Larger values can cause overflows, leading to this function returning a
>> negative value.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/sbrdsp_fixed.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/sbrdsp_fixed.c b/libavcodec/sbrdsp_fixed.c
>> index 5b7b7a6..f4e3de0 100644
>> --- a/libavcodec/sbrdsp_fixed.c
>> +++ b/libavcodec/sbrdsp_fixed.c
>> @@ -38,9 +38,14 @@ static SoftFloat sbr_sum_square_c(int (*x)[2], int n)
>>  int i, nz, round;
>>  
>>  for (i = 0; i < n; i += 2) {
>> +// Larger values are inavlid and could cause overflows of accu.
>> +av_assert2(FFABS(x[i + 0][0]) >> 29 == 0);
>>  accu += (int64_t)x[i + 0][0] * x[i + 0][0];
>> +av_assert2(FFABS(x[i + 0][1]) >> 29 == 0);
>>  accu += (int64_t)x[i + 0][1] * x[i + 0][1];
>> +av_assert2(FFABS(x[i + 1][0]) >> 29 == 0);
>>  accu += (int64_t)x[i + 1][0] * x[i + 1][0];
>> +av_assert2(FFABS(x[i + 1][1]) >> 29 == 0);
>>  accu += (int64_t)x[i + 1][1] * x[i + 1][1];
>>  }
>>  
> 
> Ping.

I pushed this now.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-08 02:53, Timo Rothenpieler wrote:
Nvidia finaly decided to put a propper MIT license on their nvenc 
header, so

it can be included, removing any external dependencies for nvenc and
making it no longer require the non-free flag.

nvenc.h is the original nvEncodeApi.h from the NVENC SDK 6.0.1, with a
slight modification to make it work on cygwin.


Works for me.

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

[FFmpeg-devel] [PATCH]lavf/matroskadec: Set codec_tag also for audio codecs

[Carl Eugen Hoyos]

Hi!

Attached patch is definitely a good idea imo, the mov demuxer also 
sets codec_tag reading the same atom, for "A_MS/ACM" codec_tag is 
already set.

Please comment, Carl Eugen
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index aad567a..95cebdd 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2124,6 +2124,7 @@ static int matroska_parse_tracks(AVFormatContext *s)
 }
 } else if (track->type == MATROSKA_TRACK_TYPE_AUDIO) {
 st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codec->codec_tag   = fourcc;
 st->codec->sample_rate = track->audio.out_samplerate;
 st->codec->channels= track->audio.channels;
 if (!st->codec->bits_per_coded_sample)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Carl Eugen Hoyos]

On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>
>  die_license_disabled nonfree libaacplus
>  die_license_disabled nonfree libfaac
> -die_license_disabled nonfree nvenc

Sorry, but this makes absolutely no sense imo:
I asked you if nvenc is a system library and your answer did 
not indicate that you are certain it is a system library (and 
I did ask you if I maybe misunderstood your answer),

If it is not a system library, you must not remove this line.

If it is a system library, please enable auto-detection as we 
already have enough untested features and as we generally do 
autodetect system libraries.

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

Re: [FFmpeg-devel] [PATCH] avutil/softfloat: Assert that the exponent did not overflow the legal range in av_normalize1_sf()

[Michael Niedermayer]

On Mon, Nov 09, 2015 at 09:17:34PM +0100, Andreas Cadhalpun wrote:
> On 08.11.2015 21:51, Andreas Cadhalpun wrote:
> > On 08.11.2015 13:41, Michael Niedermayer wrote:
> >> From: Michael Niedermayer 
> >>
> >> Signed-off-by: Michael Niedermayer 
> >> ---
> >>  libavutil/softfloat.h |1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavutil/softfloat.h b/libavutil/softfloat.h
> >> index 023ccd0..ed1aab3 100644
> >> --- a/libavutil/softfloat.h
> >> +++ b/libavutil/softfloat.h
> >> @@ -79,6 +79,7 @@ static inline av_const SoftFloat 
> >> av_normalize1_sf(SoftFloat a){
> >>  a.mant>>=1;
> >>  }
> >>  av_assert2(a.mant < 0x4000 && a.mant > -0x4000);
> >> +av_assert2(a.exp <= MAX_EXP);
> >>  return a;
> >>  #elif 1
> >>  int t= a.mant + 0x4000 < 0;
> >>
> > 
> > This assert would be triggered by more than 15% of my test samples for 
> > aac_fixed.
> > So unless that changes, this assert shouldn't be added.
> 
> I've sent a patch fixing this. Once the patch is applied, this assert should 
> be fine.

i assume this has been fixed so ill apply this soon

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c

[Michael Niedermayer]

On Thu, Dec 10, 2015 at 11:06:58AM +, Mats Peterson wrote:
> I've attached a unified diff of the latest Git version of matroskadec.c that 
> does two things:
> 1. It allows FFmpeg to recognize QuickTime version 0 sound sample 
> descriptions by using 36 instead of 86 as the minimum private data size for 
> A_QUICKTIME.
> 2. The palette, in QuickTime video that has one, is put in extradata, to make 
> MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER.
> This patch is an improvement and tidying-up of a proposed patch by Martin 
> Storsjö, for the record. The version 0 sound sample description stuff is made 
> by me long ago, though.
> 
> Comments welcome.

This sounds like 2 independant changes
each independant change should be in its own patch and commit.
you can easily split changes into commits with git add -p and
git commit
this also produces git compatible patches with commit messages
(with git format-patch or git send-email)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Fw: [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c

[Mats Peterson]

I should say "QuickTime video in a Matroska file", not "QuickTime file". -- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
 - Forwarded Message -
 From: Mats Peterson 
 To: FFmpeg development discussions and patches  
 Sent: Friday, December 11, 2015 2:00 AM
 Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound 
sample descriptions and store the palette in matroskadec.c
   
It's not replacing the private data at all.It allocates extradata separately 
from it. No program I know of uses this extradata *in Quicktime video in 
Matroska using a palette* for anything but tacking the palette onto a 
BITMAPINFOHEADER, like MPlayer. This is by far the best solution to make 
MPlayer recognize the palette in a QuickTime file, just like it does with 
V_MS/VFW/FOURCC. The problem is that it can't use an offset into the private 
data for QuickTime video as it does with V_MS/VFW/FOURCC, since the QT video 
often doesn't have any palette in the private data, has to get the default 
Macintosh palette. It's not my hack for the record. But it's a hack that works.
Mats
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
 

 From: Hendrik Leppkes 
 To: FFmpeg development discussions and patches  
 Sent: Friday, December 11, 2015 1:53 AM
 Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound 
sample descriptions and store the palette in matroskadec.c
  
On Thu, Dec 10, 2015 at 12:06 PM, Mats Peterson
 wrote:
> I've attached a unified diff of the latest Git version of matroskadec.c that 
> does two things:
> 1. It allows FFmpeg to recognize QuickTime version 0 sound sample 
> descriptions by using 36 instead of 86 as the minimum private data size for 
> A_QUICKTIME.
> 2. The palette, in QuickTime video that has one, is put in extradata, to make 
> MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER.
> This patch is an improvement and tidying-up of a proposed patch by Martin 
> Storsjö, for the record. The version 0 sound sample description stuff is made 
> by me long ago, though.
>

This is an extremely ugly hack. Replacing priv_data and calling into
the mov demuxer? Rather come up with a better solution without the
potential for a whole load of side-effects.

- Hendrik


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


  

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

[FFmpeg-devel] [PATCH] avfilter: add SOFAlizer audio filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
Lite version of one sent to VLC mailing list with only slow but high quality 
mode present.
To use you need recent netCDF library, SOFA file(s), multichannel audio and 
headphones.
---
 configure  |   4 +
 libavfilter/Makefile   |   1 +
 libavfilter/af_sofalizer.c | 932 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/formats.c  |  11 +
 libavfilter/formats.h  |   3 +
 6 files changed, 952 insertions(+)
 create mode 100644 libavfilter/af_sofalizer.c

diff --git a/configure b/configure
index afac1bc..71b2d36 100755
--- a/configure
+++ b/configure
@@ -279,6 +279,7 @@ External library support:
   --disable-lzma   disable lzma [autodetect]
   --enable-decklinkenable Blackmagic DeckLink I/O support [no]
   --enable-mmalenable decoding via MMAL [no]
+  --enable-netcdf  enable NetCDF, needed for sofalizer filter [no]
   --enable-nvenc   enable NVIDIA NVENC support [no]
   --enable-openal  enable OpenAL 1.1 capture support [no]
   --enable-opencl  enable OpenCL code
@@ -1504,6 +1505,7 @@ EXTERNAL_LIBRARY_LIST="
 libzvbi
 lzma
 mmal
+netcdf
 nvenc
 openal
 opencl
@@ -2891,6 +2893,7 @@ showfreqs_filter_deps="avcodec"
 showfreqs_filter_select="fft"
 showspectrum_filter_deps="avcodec"
 showspectrum_filter_select="rdft"
+sofalizer_filter_deps="netcdf"
 spp_filter_deps="gpl avcodec"
 spp_filter_select="fft idctdsp fdctdsp me_cmp pixblockdsp"
 stereo3d_filter_deps="gpl"
@@ -5502,6 +5505,7 @@ enabled mmal  && { check_lib 
interface/mmal/mmal.h mmal_port_connect
 check_lib interface/mmal/mmal.h 
mmal_port_connect ; }
 check_lib interface/mmal/mmal.h 
mmal_port_connect ; } ||
die "ERROR: mmal not found"; }
+enabled netcdf&& require_pkg_config netcdf netcdf.h nc_inq_libvers
 enabled nvenc && { check_header nvEncodeAPI.h || die "ERROR: 
nvEncodeAPI.h not found."; } &&
  { check_cpp_condition nvEncodeAPI.h 
"NVENCAPI_MAJOR_VERSION >= 5" ||
die "ERROR: NVENC API version 4 or older is not 
supported"; } &&
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8884d1d..d7a3f61 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -87,6 +87,7 @@ OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER)  += 
af_sidechaincompress.o
 OBJS-$(CONFIG_SIDECHAINGATE_FILTER)  += af_agate.o
 OBJS-$(CONFIG_SILENCEDETECT_FILTER)  += af_silencedetect.o
 OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += af_silenceremove.o
+OBJS-$(CONFIG_SOFALIZER_FILTER)  += af_sofalizer.o
 OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
 OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o
 OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
diff --git a/libavfilter/af_sofalizer.c b/libavfilter/af_sofalizer.c
new file mode 100644
index 000..52cd09c
--- /dev/null
+++ b/libavfilter/af_sofalizer.c
@@ -0,0 +1,932 @@
+/*
+ * sofalizer.c : SOFAlizer filter for virtual binaural acoustics
+ *
+ * Copyright (C) 2013-2015 Andreas Fuchs, Wolfgang Hrauda,
+ * Acoustics Research Institute (ARI), Vienna, Austria
+ *
+ * Authors: Andreas Fuchs 
+ *  Wolfgang Hrauda 
+ *
+ * SOFAlizer project coordinator at ARI, main developer of SOFA:
+ *  Piotr Majdak 
+ *
+ * This program 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.
+ *
+ * This program 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 this program; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301, USA.
+ */
+
+#include 
+#include 
+
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "audio.h"
+
+typedef struct NCSofa {  /* contains data of one SOFA file */
+int ncid;/* netCDF ID of the opened SOFA file */
+int n_samples;   /* length of one impulse response (IR) */
+int m_dim;   /* number of measurement positions 

[FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/x86/hevc_sao_10bit.asm | 142 +++---
 1 file changed, 57 insertions(+), 85 deletions(-)

diff --git a/libavcodec/x86/hevc_sao_10bit.asm 
b/libavcodec/x86/hevc_sao_10bit.asm
index f45fc56..3a7048a 100644
--- a/libavcodec/x86/hevc_sao_10bit.asm
+++ b/libavcodec/x86/hevc_sao_10bit.asm
@@ -83,7 +83,6 @@ SECTION .text
 mova  [rsp+mmsize*6], m6
 mova  m1, [pw_mask %+ %1]
 pxor  m0, m0
-%assign MMSIZE mmsize
 %define m14 m0
 %define m13 m1
 %define  m9 m2
@@ -93,37 +92,6 @@ DEFINE_ARGS dst, src, dststride, srcstride, offset, height
 mov  heightd, r7m
 %endmacro
 
-%macro HEVC_SAO_BAND_FILTER_COMPUTE 3
-psraw %2, %3, %1-5
-%if ARCH_X86_64
-pcmpeqw  m10, %2, m0
-pcmpeqw  m11, %2, m1
-pcmpeqw  m12, %2, m2
-pcmpeqw   %2, m3
-pand m10, m4
-pand m11, m5
-pand m12, m6
-pand  %2, m7
-por  m10, m11
-por  m12, %2
-por  m10, m12
-paddw %3, m10
-%else ; ARCH_X86_32
-pcmpeqw   m4, %2, [rsp+MMSIZE*0]
-pcmpeqw   m5, %2, [rsp+MMSIZE*1]
-pcmpeqw   m6, %2, [rsp+MMSIZE*2]
-pcmpeqw   %2, [rsp+MMSIZE*3]
-pand  m4, [rsp+MMSIZE*4]
-pand  m5, [rsp+MMSIZE*5]
-pand  m6, [rsp+MMSIZE*6]
-pand  %2, m7
-por   m4, m5
-por   m6, %2
-por   m4, m6
-paddw %3, m4
-%endif ; ARCH
-%endmacro
-
 ;void ff_hevc_sao_band_filter___(uint8_t *_dst, uint8_t 
*_src, ptrdiff_t _stride_dst, ptrdiff_t _stride_src,
 ;   int16_t *sao_offset_val, 
int sao_left_class, int width, int height);
 %macro HEVC_SAO_BAND_FILTER 3
@@ -132,43 +100,47 @@ cglobal hevc_sao_band_filter_%2_%1, 6, 6, 15, 
7*mmsize*ARCH_X86_32, dst, src, ds
 
 align 16
 .loop:
-%if %2 == 8
-movu  m8, [srcq]
-HEVC_SAO_BAND_FILTER_COMPUTE %1, m9, m8
-CLIPW m8, m14, m13
-movu  [dstq], m8
-%endif
 
 %assign i 0
+%assign j 0
 %rep %3
-mova  m8, [srcq + i]
-HEVC_SAO_BAND_FILTER_COMPUTE %1, m9, m8
-CLIPW m8, m14, m13
-mova  [dstq + i], m8
-
-mova  m9, [srcq + i + mmsize]
-HEVC_SAO_BAND_FILTER_COMPUTE %1, m8, m9
-CLIPW m9, m14, m13
-mova  [dstq + i + mmsize], m9
-%assign i i+mmsize*2
+%assign k 8+(j&1)
+%assign l 9-(j&1)
+mova  m %+ k, [srcq + i]
+psraw m %+ l, m %+ k, %1-5
+%if ARCH_X86_64
+pcmpeqw  m10, m %+ l, m0
+pcmpeqw  m11, m %+ l, m1
+pcmpeqw  m12, m %+ l, m2
+pcmpeqw   m %+ l, m3
+pand m10, m4
+pand m11, m5
+pand m12, m6
+pand  m %+ l, m7
+por  m10, m11
+por  m12, m %+ l
+por  m10, m12
+paddw m %+ k, m10
+%else ; ARCH_X86_32
+pcmpeqw   m4, m %+ l, [rsp+mmsize*0]
+pcmpeqw   m5, m %+ l, [rsp+mmsize*1]
+pcmpeqw   m6, m %+ l, [rsp+mmsize*2]
+pcmpeqw   m %+ l, [rsp+mmsize*3]
+pand  m4, [rsp+mmsize*4]
+pand  m5, [rsp+mmsize*5]
+pand  m6, [rsp+mmsize*6]
+pand  m %+ l, m7
+por   m4, m5
+por   m6, m %+ l
+por   m4, m6
+paddw m %+ k, m4
+%endif ; ARCH
+CLIPW m %+ k, m14, m13
+mova  [dstq + i], m %+ k
+%assign i i+mmsize
+%assign j j+1
 %endrep
 
-%if %2 == 48
-INIT_XMM cpuname
-mova  m8, [srcq + i]
-HEVC_SAO_BAND_FILTER_COMPUTE %1, m9, m8
-CLIPW m8, m14, m13
-mova  [dstq + i], m8
-
-mova  m9, [srcq + i + mmsize]
-HEVC_SAO_BAND_FILTER_COMPUTE %1, m8, m9
-CLIPW m9, m14, m13
-mova  [dstq + i + mmsize], m9
-%if cpuflag(avx2)
-INIT_YMM cpuname
-%endif
-%endif ; %1 == 48
-
 add dstq, dststrideq
 add srcq, srcstrideq
 dec  heightd
@@ -177,17 +149,17 @@ INIT_YMM cpuname
 %endmacro
 
 %macro HEVC_SAO_BAND_FILTER_FUNCS 0
-HEVC_SAO_BAND_FILTER 10,  8, 0
-HEVC_SAO_BAND_FILTER 10, 16, 1
-HEVC_SAO_BAND_FILTER 10, 32, 2
-HEVC_SAO_BAND_FILTER 10, 48, 2
-HEVC_SAO_BAND_FILTER 10, 64, 4
-
-HEVC_SAO_BAND_FILTER 12,  8, 0
-HEVC_SAO_BAND_FILTER 12, 16, 1
-HEVC_SAO_BAND_FILTER 12, 32, 2
-HEVC_SAO_BAND_FILTER 12, 48, 2
-HEVC_SAO_BAND_FILTER 12, 64, 4
+HEVC_SAO_BAND_FILTER 10,  8, 1
+HEVC_SAO_BAND_FILTER 10, 16, 2
+HEVC_SAO_BAND_FILTER 10, 32, 4
+HEVC_SAO_BAND_FILTER 10, 48, 6
+HEVC_SAO_BAND_FILTER 10, 64, 8
+
+HEVC_SAO_BAND_FILTER 12,  8, 1
+HEVC_SAO_BAND_FILTER 12, 16, 2
+HEVC_SAO_BAND_FILTER 12, 32, 4
+HEVC_SAO_BAND_FILTER 12, 48, 6

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 11.12.2015 00:03, Carl Eugen Hoyos wrote:
> On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
>> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>>
>>  die_license_disabled nonfree libaacplus
>>  die_license_disabled nonfree libfaac
>> -die_license_disabled nonfree nvenc
> 
> Sorry, but this makes absolutely no sense imo:
> I asked you if nvenc is a system library and your answer did 
> not indicate that you are certain it is a system library (and 
> I did ask you if I maybe misunderstood your answer),

Well, the problem is that the answer may depend on the system.

> If it is not a system library, you must not remove this line.
> 
> If it is a system library, please enable auto-detection as we 
> already have enough untested features and as we generally do 
> autodetect system libraries.

What should be done if it is a system library on Windows, but
not on Debian?

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH]lavc/libvo-aac: Mark the encoder as experimental

[Hendrik Leppkes]

On Fri, Dec 11, 2015 at 12:07 AM, Carl Eugen Hoyos  wrote:
> On Wednesday 09 December 2015 09:24:06 pm Hendrik Leppkes wrote:
>> On Wed, Dec 9, 2015 at 7:09 PM, James Almer  wrote:
>> > On 12/5/2015 9:31 PM, Carl Eugen Hoyos wrote:
>> >> Hi!
>> >>
>> >> I prefer attached patch over removing the encoder immediately.
>
>> And its quality is horrible.
>>
>> No idea why we would mark it experimental however. The built-in
>> encoder will always take precedence, so a user has to explicitly
>> request it as it is.
>
> I am thinking of the many scripts using libvo-aac and the many
> users who automatically request it with -c:a whenever they encode
> aac.
>

So you intentionally want to break all the scripts? Doesn't sound like
a good thing.

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

Re: [FFmpeg-devel] [PATCH] avfilter: add SOFAlizer audio filter

[Michael Niedermayer]

On Fri, Dec 11, 2015 at 12:03:34AM +0100, Paul B Mahol wrote:
[...]
> +static int query_formats(AVFilterContext *ctx)
> +{
> +struct SOFAlizerContext *s = ctx->priv;
> +AVFilterFormats *formats = NULL;
> +AVFilterChannelLayouts *layouts = NULL;

> +static int sample_rates[] = { 48000, -1 };

[...]
> +sample_rates[0] = s->sample_rate;
> +formats = ff_make_format_list(sample_rates);

is this intended to be a non constant static/global ?

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c

[Mats Peterson]

It's not replacing the private data at all.It allocates extradata separately 
from it. No program I know of uses this extradata *in Quicktime video in 
Matroska using a palette* for anything but tacking the palette onto a 
BITMAPINFOHEADER, like MPlayer. This is by far the best solution to make 
MPlayer recognize the palette in a QuickTime file, just like it does with 
V_MS/VFW/FOURCC. The problem is that it can't use an offset into the private 
data for QuickTime video as it does with V_MS/VFW/FOURCC, since the QT video 
often doesn't have any palette in the private data, has to get the default 
Macintosh palette. It's not my hack for the record. But it's a hack that works.
Mats
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
  From: Hendrik Leppkes 
 To: FFmpeg development discussions and patches  
 Sent: Friday, December 11, 2015 1:53 AM
 Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound 
sample descriptions and store the palette in matroskadec.c
   
On Thu, Dec 10, 2015 at 12:06 PM, Mats Peterson
 wrote:
> I've attached a unified diff of the latest Git version of matroskadec.c that 
> does two things:
> 1. It allows FFmpeg to recognize QuickTime version 0 sound sample 
> descriptions by using 36 instead of 86 as the minimum private data size for 
> A_QUICKTIME.
> 2. The palette, in QuickTime video that has one, is put in extradata, to make 
> MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER.
> This patch is an improvement and tidying-up of a proposed patch by Martin 
> Storsjö, for the record. The version 0 sound sample description stuff is made 
> by me long ago, though.
>

This is an extremely ugly hack. Replacing priv_data and calling into
the mov demuxer? Rather come up with a better solution without the
potential for a whole load of side-effects.

- Hendrik


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


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

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Hendrik Leppkes]

On Thu, Dec 10, 2015 at 11:01 AM, Ivan Uskov  wrote:
> Hello Hendrik,
>
> Thursday, December 10, 2015, 12:19:23 PM, you wrote:
>
> HL> On Thu, Dec 10, 2015 at 10:16 AM, Sven Dueking  wrote:
>>> This patch expose 3 QSV functions as public.
>>> This is needed because the VPP needs access to these functions too.
>>>
>>> Please review.
>>>
>
> HL> public API is not allowed to use config.h, it needs to be config and
> HL> OS agnostic.
> Any qsv_* function can not be public since are all under CONFIG_QSV, correct?
>

Thats not necessarily true, if its supposed to be public API, it just
has to always be present, so it would have to be changed to just do
nothing and return an error if QSV is not enabled, but the functions
still exist.
Using config.h in public headers is not something you can somehow work
around however. The public interface needs to be stable, independent
of how ffmpeg was built.

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

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Ivan Uskov]

Hello Hendrik,

Thursday, December 10, 2015, 1:10:59 PM, you wrote:

 This patch expose 3 QSV functions as public.
 This is needed because the VPP needs access to these functions too.

 Please review.

>>
>> HL> public API is not allowed to use config.h, it needs to be config and
>> HL> OS agnostic.
>> Any qsv_* function can not be public since are all under CONFIG_QSV, correct?
>>

HL> Thats not necessarily true, if its supposed to be public API, it just
HL> has to always be present, so it would have to be changed to just do
HL> nothing and return an error if QSV is not enabled, but the functions
HL> still exist.
But   it  is exactly that Sven did, there are dummies for all public function
into the qsv_api.c for the case if CONFIG_QSV==0
What is wrong then?



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

[FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c

[Mats Peterson]

I've attached a unified diff of the latest Git version of matroskadec.c that 
does two things:
1. It allows FFmpeg to recognize QuickTime version 0 sound sample descriptions 
by using 36 instead of 86 as the minimum private data size for A_QUICKTIME.
2. The palette, in QuickTime video that has one, is put in extradata, to make 
MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER.
This patch is an improvement and tidying-up of a proposed patch by Martin 
Storsjö, for the record. The version 0 sound sample description stuff is made 
by me long ago, though.

Comments welcome.

Mats
 -- 
Mats Peterson
http://matsp888.no-ip.org/~mats/--- matroskadec.c.orig	2015-12-08 11:01:40.640478749 +0100
+++ matroskadec.c	2015-12-08 13:56:46.0 +0100
@@ -310,10 +310,12 @@
 /* File has SSA subtitles which prevent incremental cluster parsing. */
 int contains_ssa;
 
 /* WebM DASH Manifest live flag/ */
 int is_live;
+
+uint8_t *pal;
 } MatroskaDemuxContext;
 
 typedef struct MatroskaBlock {
 uint64_t duration;
 int64_t  reference;
@@ -1853,22 +1855,27 @@
 if (ret < 0)
 return ret;
 codec_id = st->codec->codec_id;
 extradata_offset = FFMIN(track->codec_priv.size, 18);
 } else if (!strcmp(track->codec_id, "A_QUICKTIME")
-   && (track->codec_priv.size >= 86)
+   && (track->codec_priv.size >= 36)
&& (track->codec_priv.data)) {
 fourcc = AV_RL32(track->codec_priv.data + 4);
 codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
 if (ff_codec_get_id(ff_codec_movaudio_tags, AV_RL32(track->codec_priv.data))) {
 fourcc = AV_RL32(track->codec_priv.data);
 codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
 }
 } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
(track->codec_priv.size >= 21)  &&
(track->codec_priv.data)) {
-fourcc   = AV_RL32(track->codec_priv.data + 4);
+AVIOContext pb;
+MOVContext *mc;
+MOVStreamContext *msc;
+void *priv_data;
+int nb_streams;
+fourcc = AV_RL32(track->codec_priv.data + 4);
 codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
 if (ff_codec_get_id(ff_codec_movvideo_tags, AV_RL32(track->codec_priv.data))) {
 fourcc   = AV_RL32(track->codec_priv.data);
 codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
 }
@@ -1878,10 +1885,49 @@
 char buf[32];
 av_get_codec_tag_string(buf, sizeof(buf), fourcc);
 av_log(matroska->ctx, AV_LOG_ERROR,
"mov FourCC not found %s.\n", buf);
 }
+priv_data = st->priv_data;
+nb_streams = s->nb_streams;
+mc = av_mallocz(sizeof(*mc));
+if (! mc)
+return AVERROR(ENOMEM);
+mc->fc = s;
+st->priv_data = msc = av_mallocz(sizeof(MOVStreamContext));
+if (!msc) {
+av_free(mc);
+st->priv_data = priv_data;
+return AVERROR(ENOMEM);
+}
+ffio_init_context(, track->codec_priv.data, track->codec_priv.size, 0, NULL, NULL, NULL, NULL);
+/* ff_mov_read_stsd_entries updates stream s->nb_streams-1,
+ * so set it temporarily to indicate which stream to update. */
+s->nb_streams = st->index + 1;
+ff_mov_read_stsd_entries(mc, , 1);
+if (msc->has_palette) {
+if ((matroska->pal = av_malloc(AVPALETTE_SIZE))) {
+memcpy(matroska->pal, msc->palette, AVPALETTE_SIZE);
+if ((extradata = av_malloc(AVPALETTE_SIZE))) {
+memcpy(extradata, msc->palette, AVPALETTE_SIZE);
+extradata_size = AVPALETTE_SIZE;
+}
+}
+if (!matroska->pal || !extradata) {
+av_free(msc);
+av_free(mc);
+if (matroska->pal) av_freep(>pal);
+if (extradata) av_freep();
+st->priv_data = priv_data;
+s->nb_streams = nb_streams;
+return AVERROR(ENOMEM);
+}
+}
+av_free(msc);
+av_free(mc);
+st->priv_data = priv_data;
+s->nb_streams = nb_streams;
 } else if (codec_id == AV_CODEC_ID_PCM_S16BE) {
 switch (track->audio.bitdepth) {
 case  8:
 codec_id = AV_CODEC_ID_PCM_U8;
 break;
@@ -2322,10 +2368,19 @@
AVPacket *pkt)
 {
 if (matroska->num_packets > 0) {
 memcpy(pkt, 

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Hendrik Leppkes]

On Thu, Dec 10, 2015 at 11:20 AM, Ivan Uskov  wrote:
> Hello Hendrik,
>
> Thursday, December 10, 2015, 1:10:59 PM, you wrote:
>
> This patch expose 3 QSV functions as public.
> This is needed because the VPP needs access to these functions too.
>
> Please review.
>
>>>
>>> HL> public API is not allowed to use config.h, it needs to be config and
>>> HL> OS agnostic.
>>> Any qsv_* function can not be public since are all under CONFIG_QSV, 
>>> correct?
>>>
>
> HL> Thats not necessarily true, if its supposed to be public API, it just
> HL> has to always be present, so it would have to be changed to just do
> HL> nothing and return an error if QSV is not enabled, but the functions
> HL> still exist.
> But   it  is exactly that Sven did, there are dummies for all public function
> into the qsv_api.c for the case if CONFIG_QSV==0
> What is wrong then?

The public qsv.h uses config.h, thats not allowed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Ivan Uskov]

Hello Hendrik,

Thursday, December 10, 2015, 2:00:51 PM, you wrote:
>> What is wrong then?

HL> The public qsv.h uses config.h, thats not allowed.
ah, got it, thank.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

Re: [FFmpeg-devel] Ideas to replace the options system

[Nicolas George]

Replying to everybody at once:


To Ronald, regarding "rewrite EVERYTHING!!!" versus "added as extensions of
the current API":

My gut feeling is that starting from scratch would prove less efforts in
total. The current code is already quite convoluted, even adding a single
type requires adding code in various places, and it is already not easy to
know what places are mandatory and what places are optional or squarely
redundant. There are functions with similar names because one was added
after the other, etc.

The way I see it, just getting the current code into shape for serious
extensions would require a big refactoring. I believe this is a situation
where the desired new features are significantly larger that the current
code base, and in these case, not worrying with the existing, taking only
what is useful as it comes seems easier.

But of course, this is up to whoever does the work.


To Paul, about dynamic options changing:

This one, I think, is rather orthogonal to what I am suggesting. Right now,
you could call av_opt_set() on a filter or a codec that is already in use.
It would give awful results, but not because of the options system, because
filters and codec are not ready for options changing below their feet.

Of course, some support from the options system would help, like a flag
telling us if an option can be changed later or not (dynamic read/write
status), but the bulk of the effort seems to be getting filters into shape.


To James, regarding allowing only simple string arguments:

I do not quite understand what you are proposing. How would the user specify
a PAN matrix like "FL

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

Am 10.12.2015 17:10 schrieb "Andreas Cadhalpun" <
andreas.cadhal...@googlemail.com>:
>
> On 10.12.2015 16:49, Hendrik Leppkes wrote:
> > On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun
> >  wrote:
> >> The GPL-3 requires that the 'Corresponding Source' of the distributed
object code
> >> is also distributed. This is defined as [1]:
> >> The “Corresponding Source” for a work in object code form means all
the source
> >> code needed to generate, install, and (for an executable work) run the
object
> >> code[...]
> >> For example, Corresponding Source includes [...] the source code for
[...]
> >> dynamically linked subprograms that the work is specifically designed
to require,
> >> such as by intimate data communication or control flow between those
subprograms
> >> and other parts of the work.
> >>
> >
> > This rule does not apply to system libraries,
>
> Yes.
>
> > which I still am quite
> > sure a hardware driver would fall under (and we can argue about that
> > all day, you won't get any "proof" either way)
> > If a particular system does not actually package this particular
> > library, then their distribution of FFmpeg should probably just not
> > enable nvenc, its of no use without the library anyway.
>
> But if it did, it would certainly not fall under the system library
exception.
> If that's the only thing that allows distribution of compiled nvenc.c,
> it shouldn't be enabled by default.
>

I don't mind disabling it by default, if that alleviates some concerns.

> > You could argue the same thing for QuickSync, the only difference is
> > that it depends on some sort of "dispatcher" library that sits between
> > FFmpeg and the closed-source library.
>
> Yes, that looks like a similar problem.
>
> > Does the existence of a tiny dispatcher library suddenly "fix" these
> > rules?
>
> I don't think so, but I haven't looked at the code.
>
> > That would be silly. Yet it is widely accepted that linking
> > against libmfx for qsv is fine.
>
> If it is 'widely accepted' that distribution of the resulting object
> code is GPL compatible, then you can certainly provide links
> to statements from experts saying so, e.g. from someone from the FSF.
> Unless you do, 'widely accepted' is a void argument.
>
> Best regards,
> Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Matt Oliver]

>
>
> I don't mind disabling it by default, if that alleviates some concerns.
>

One caveat to my previous comments is that just like avisynth I think that
nvenc should be disabled by default aswell.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 10.12.2015 17:34, Hendrik Leppkes wrote:
> Am 10.12.2015 17:10 schrieb "Andreas Cadhalpun" <
> andreas.cadhal...@googlemail.com>:
>> If that's the only thing that allows distribution of compiled nvenc.c,
>> it shouldn't be enabled by default.
>>
> 
> I don't mind disabling it by default, if that alleviates some concerns.

If it's enabled by default, it could cause problems for distributors,
where the system library exception doesn't apply.
So not enabling it is a safer default.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 10.12.2015 17:42, Matt Oliver wrote:
>>
>> What is a system library depends on the system.
>> For example, Debian (main) does not even include libcuda or
>> libnvidia-encode, so they certainly cannot be system libraries there.
>
>>
> 
> Im not sure that Debian not including libcuda is a valid argument for it
> not being a system library as thats just one OS.

The GPL defines a system library only in the context of a specific
operating system. So what is a system library differs from one OS to another.
Therefore one can't just claim something is a system library and thus it's
fine to use it, unless specifying the specific OS one talks about.

> To me thats the same as
> saying that win32 stuff is not part of a system library because Debian
> doesnt have it (for obvious reasons).

That's not correct, because Debian does have wine. ;)

> So I dont believe that just because
> some systems dont have it doesnt stop it from being a system library.

You're treating being a system library as something OS-agnostic, which
it isn't. A library can be a system library on Windows, but not on Android.

> And
> if a system doesnt have the required propriety libs then they wont be
> loaded at runtime and therefore no proprietary code is ever used at all.

But distributors of compiled nvenc still have to comply with the GPL.

>>> The ffmpeg binary that results from including nvEncodeAPI.h is GPL
 compatible because nvEncodeAPI.h is MIT licenced.
>>>
>>> I'm not sure it's that easy. If that were correct, it would become
>>> GPL-compatible to distribute a GPL-licensed program linked with a
>>> proprietary library by simply inserting a MIT licensed header in the
>> middle.
>>
> 
> In this case thats not what is being said as we are not actually linking
> against anything.

Linking via ld.so or dlopen isn't really different from a license point of
view.

> As if we did link against a propriety lib then you would
> be correct and this would brake GPL but that is not the case as the nvenc
> binaries are only accessed at runtime. All were doing here is including a
> single header file.

And again: including the header is not the problem.

>>> The only time the GPL ffmpeg and the proprietary licenced nvidia
>> libraries
 are combined is on the end user system so no distribution occurs, so
>> the
 GPL language doesn't apply at that stage.
>>>
>>> However, the object code compiled from nvenc.c would get distributed as
>> part of
>>> the ffmpeg binaries, which is governed by the GPL.
>>
> 
> The object code from nvenc.c is written using LGPL and just includes
> declarations (no actual code definitions) from a MIT header file which to
> me suggests that the part of ffmpeg that would be distributed is still GPL
> compliant. At no point during the entire compilation and linking stage is
> any proprietary component touched so I dont see how this brakes anything.

However, running most of the generated object code from nvenc.c requires
the non-free blobs. And the GPL specifically also requires the source
code for libraries only required at run-time.

> So sorry for being verbose (and potential just stating the obvious) but the
> only argument here is whether we can consider the libs accessed at runtime
> as system libs or not.

Yes.

> To use windows as a further example all the actual binary code required for
> nvenc to work is part of the graphics drivers. So the only time anything
> not GPL compliant is ever used is when the dll's are loaded at runtime from
> the driver. This definitely puts it in the category of a system component
> in my mind. If drivers are not considered system libs then we have far more
> serious problems than nvenc ;)

Whether or not it's a system library on Windows doesn't matter for any other OS.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Set codec_tag also for audio codecs

[Michael Niedermayer]

On Thu, Dec 10, 2015 at 11:50:45PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch is definitely a good idea imo, the mov demuxer also 
> sets codec_tag reading the same atom, for "A_MS/ACM" codec_tag is 
> already set.
> 
> Please comment, Carl Eugen

>  matroskadec.c |1 +
>  1 file changed, 1 insertion(+)
> 2304ec17547647dad8121a55cac95f099a8e6ef1  patchmkvaudiofourcc.diff
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index aad567a..95cebdd 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -2124,6 +2124,7 @@ static int matroska_parse_tracks(AVFormatContext *s)
>  }
>  } else if (track->type == MATROSKA_TRACK_TYPE_AUDIO) {
>  st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
> +st->codec->codec_tag   = fourcc;
>  st->codec->sample_rate = track->audio.out_samplerate;
>  st->codec->channels= track->audio.channels;
>  if (!st->codec->bits_per_coded_sample)

this changes things like:
 Stream #0:7(jpn): Audio: adpcm_ima_wav ([17][0][0][0] / 0x0011), 11025 Hz, 2 
channels, s16p, 88 kb/s
to
 Stream #0:7(jpn): Audio: adpcm_ima_wav, 11025 Hz, 2 channels, s16p, 88 kb/s

in [CCCP]_Mega_Weird_Audio_Test.mkv

is that intended ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] nvenc set slice number to 1 to improve encoding quality and clamp initial qp value to [1, 51]

[Agatha Hu]

---
 libavcodec/nvenc.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 43b8e78..6365434 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -762,6 +762,17 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
 }
 }
 
+switch (avctx->codec->id) {
+case AV_CODEC_ID_H264:
+ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3;
+ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1;
+break;
+case AV_CODEC_ID_H265:
+ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3;
+ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1;
+break;
+}
+
 /* when there're b frames, set dts offset */
 if (ctx->encode_config.frameIntervalP >= 2)
 ctx->last_dts = -2;
@@ -843,10 +854,10 @@ static av_cold int nvenc_encode_init(AVCodecContext 
*avctx)
 ctx->encode_config.rcParams.initialRCQP.qpInterP  = qp_inter_p;
 
 if(avctx->i_quant_factor != 0.0 && avctx->b_quant_factor != 0.0) {
-ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p * 
fabs(avctx->i_quant_factor);
-ctx->encode_config.rcParams.initialRCQP.qpIntra += 
avctx->i_quant_offset;
-ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p * 
fabs(avctx->b_quant_factor);
-ctx->encode_config.rcParams.initialRCQP.qpInterB += 
avctx->b_quant_offset;
+ctx->encode_config.rcParams.initialRCQP.qpIntra = av_clip(
+qp_inter_p * fabs(avctx->i_quant_factor) + 
avctx->i_quant_offset, 0, 51);
+ctx->encode_config.rcParams.initialRCQP.qpInterB = av_clip(
+qp_inter_p * fabs(avctx->b_quant_factor) + 
avctx->b_quant_offset, 0, 51);
 } else {
 ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p;
 ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p;
-- 
1.9.5.github.0

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

[FFmpeg-devel] Fw: Fw: [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c

[Mats Peterson]

I do agree that calling ff_mov_read_stsd_entries() in mov.c is an ugly hack, 
though. But don't blame me, I didn't write it ;) It would be better to manage 
the palette inside of matroskadec.c, of course, even if it seems to work just 
fine as it is right now. Mats

-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
 - Forwarded Message -
 From: Mats Peterson 
 To: FFmpeg Development Discussions and Patches  
 Sent: Friday, December 11, 2015 2:02 AM
 Subject: [FFmpeg-devel] Fw: [PATCH] Make FFmpeg recognize QT version 0 sound 
sample descriptions and store the palette in matroskadec.c
   
I should say "QuickTime video in a Matroska file", not "QuickTime file". -- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
    - Forwarded Message -


 From: Mats Peterson 
 To: FFmpeg development discussions and patches  
 Sent: Friday, December 11, 2015 2:00 AM
 Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound 
sample descriptions and store the palette in matroskadec.c
  
It's not replacing the private data at all.It allocates extradata separately 
from it. No program I know of uses this extradata *in Quicktime video in 
Matroska using a palette* for anything but tacking the palette onto a 
BITMAPINFOHEADER, like MPlayer. This is by far the best solution to make 
MPlayer recognize the palette in a QuickTime file, just like it does with 
V_MS/VFW/FOURCC. The problem is that it can't use an offset into the private 
data for QuickTime video as it does with V_MS/VFW/FOURCC, since the QT video 
often doesn't have any palette in the private data, has to get the default 
Macintosh palette. It's not my hack for the record. But it's a hack that works.
Mats
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
 

    From: Hendrik Leppkes 
 To: FFmpeg development discussions and patches  
 Sent: Friday, December 11, 2015 1:53 AM
 Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound 
sample descriptions and store the palette in matroskadec.c
  
On Thu, Dec 10, 2015 at 12:06 PM, Mats Peterson
 wrote:
> I've attached a unified diff of the latest Git version of matroskadec.c that 
> does two things:
> 1. It allows FFmpeg to recognize QuickTime version 0 sound sample 
> descriptions by using 36 instead of 86 as the minimum private data size for 
> A_QUICKTIME.
> 2. The palette, in QuickTime video that has one, is put in extradata, to make 
> MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER.
> This patch is an improvement and tidying-up of a proposed patch by Martin 
> Storsjö, for the record. The version 0 sound sample description stuff is made 
> by me long ago, though.
>

This is an extremely ugly hack. Replacing priv_data and calling into
the mov demuxer? Rather come up with a better solution without the
potential for a whole load of side-effects.

- Hendrik


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


  

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


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

[FFmpeg-devel] [PATCH] nvenc set slice number to 1 to improve encoding quality and clamp initial qp value to [1, 51]

[Agatha Hu]

---
 libavcodec/nvenc.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 43b8e78..6365434 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -762,6 +762,17 @@ static av_cold int nvenc_encode_init(AVCodecContext 
*avctx)

 }
 }

+switch (avctx->codec->id) {
+case AV_CODEC_ID_H264:
+ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3;
+ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1;
+break;
+case AV_CODEC_ID_H265:
+ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3;
+ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1;
+break;
+}
+
 /* when there're b frames, set dts offset */
 if (ctx->encode_config.frameIntervalP >= 2)
 ctx->last_dts = -2;
@@ -843,10 +854,10 @@ static av_cold int 
nvenc_encode_init(AVCodecContext *avctx)

 ctx->encode_config.rcParams.initialRCQP.qpInterP  = qp_inter_p;

 if(avctx->i_quant_factor != 0.0 && avctx->b_quant_factor != 0.0) {
-ctx->encode_config.rcParams.initialRCQP.qpIntra = 
qp_inter_p * fabs(avctx->i_quant_factor);
-ctx->encode_config.rcParams.initialRCQP.qpIntra += 
avctx->i_quant_offset;
-ctx->encode_config.rcParams.initialRCQP.qpInterB = 
qp_inter_p * fabs(avctx->b_quant_factor);
-ctx->encode_config.rcParams.initialRCQP.qpInterB += 
avctx->b_quant_offset;

+ctx->encode_config.rcParams.initialRCQP.qpIntra = av_clip(
+qp_inter_p * fabs(avctx->i_quant_factor) + 
avctx->i_quant_offset, 0, 51);

+ctx->encode_config.rcParams.initialRCQP.qpInterB = av_clip(
+qp_inter_p * fabs(avctx->b_quant_factor) + 
avctx->b_quant_offset, 0, 51);

 } else {
 ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p;
 ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p;
--
1.9.5.github.0



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

Re: [FFmpeg-devel] [PATCH] nvenc set slice number to 1 to improve encoding quality and clamp initial qp value to [1, 51]

[Agatha Hu]

On 2015/12/11 11:10, Agatha Hu wrote:


---
  libavcodec/nvenc.c | 19 +++
  1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 43b8e78..6365434 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -762,6 +762,17 @@ static av_cold int nvenc_encode_init(AVCodecContext
*avctx)
  }
  }

+switch (avctx->codec->id) {
+case AV_CODEC_ID_H264:
+ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3;
+ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1;
+break;
+case AV_CODEC_ID_H265:
+ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3;
+ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1;
+break;
+}
+
  /* when there're b frames, set dts offset */
  if (ctx->encode_config.frameIntervalP >= 2)
  ctx->last_dts = -2;
@@ -843,10 +854,10 @@ static av_cold int
nvenc_encode_init(AVCodecContext *avctx)
  ctx->encode_config.rcParams.initialRCQP.qpInterP  = qp_inter_p;

  if(avctx->i_quant_factor != 0.0 && avctx->b_quant_factor !=
0.0) {
-ctx->encode_config.rcParams.initialRCQP.qpIntra =
qp_inter_p * fabs(avctx->i_quant_factor);
-ctx->encode_config.rcParams.initialRCQP.qpIntra +=
avctx->i_quant_offset;
-ctx->encode_config.rcParams.initialRCQP.qpInterB =
qp_inter_p * fabs(avctx->b_quant_factor);
-ctx->encode_config.rcParams.initialRCQP.qpInterB +=
avctx->b_quant_offset;
+ctx->encode_config.rcParams.initialRCQP.qpIntra = av_clip(
+qp_inter_p * fabs(avctx->i_quant_factor) +
avctx->i_quant_offset, 0, 51);
+ctx->encode_config.rcParams.initialRCQP.qpInterB = av_clip(
+qp_inter_p * fabs(avctx->b_quant_factor) +
avctx->b_quant_offset, 0, 51);
  } else {
  ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p;
  ctx->encode_config.rcParams.initialRCQP.qpInterB =
qp_inter_p;


Hi all, before switching to the new released nvenc6.0 header, can you 
take a look at this fix?


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

Re: [FFmpeg-devel] [PATCH 7/9] avcodec/mdct_template: use lrint instead of floor hack

[Ganesh Ajjanagadde]

On Sun, Dec 6, 2015 at 8:20 AM, Ganesh Ajjanagadde
 wrote:
> On Tue, Dec 1, 2015 at 7:27 PM, Ganesh Ajjanagadde
>  wrote:
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/mdct_template.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/mdct_template.c b/libavcodec/mdct_template.c
>> index e7e5f62..ecdeb54 100644
>> --- a/libavcodec/mdct_template.c
>> +++ b/libavcodec/mdct_template.c
>> @@ -23,6 +23,7 @@
>>  #include 
>>  #include "libavutil/common.h"
>>  #include "libavutil/mathematics.h"
>> +#include "libavutil/libm.h"
>>  #include "fft.h"
>>  #include "fft-internal.h"
>>
>> @@ -82,8 +83,8 @@ av_cold int ff_mdct_init(FFTContext *s, int nbits, int 
>> inverse, double scale)
>>  for(i=0;i>  alpha = 2 * M_PI * (i + theta) / n;
>>  #if FFT_FIXED_32
>> -s->tcos[i*tstep] = (FFTSample)floor(-cos(alpha) * 2147483648.0 + 
>> 0.5);
>> -s->tsin[i*tstep] = (FFTSample)floor(-sin(alpha) * 2147483648.0 + 
>> 0.5);
>> +s->tcos[i*tstep] = lrint(-cos(alpha) * 2147483648.0);
>> +s->tsin[i*tstep] = lrint(-sin(alpha) * 2147483648.0);
>>  #else
>>  s->tcos[i*tstep] = FIX15(-cos(alpha) * scale);
>>  s->tsin[i*tstep] = FIX15(-sin(alpha) * scale);
>> --
>> 2.6.2
>>
>
> Ping for this one, it is relatively important among the lrint patches
> as this is frequently used and table may be large, making speed
> benefit somewhat useful.
> I have noted the header alphabetical include order mistake above.

This is going in soon, as it actually fixes a bug since cos, sin can
be positive in the relevant ranges here. Last call.
Note: I think there might be undefined behavior here (before and after
the patch) since cos(alpha) can be -1 (or very close it) here. That is
a separate issue that I will examine some time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/8] avfilter/vf_overlay: fix memory leaks

[Ganesh Ajjanagadde]

On Thu, Dec 10, 2015 at 3:47 AM, Paul B Mahol  wrote:
> On 12/10/15, Ganesh Ajjanagadde  wrote:
>> On Wed, Dec 9, 2015 at 6:09 PM, Paul B Mahol  wrote:
>>> On 12/9/15, Ganesh Ajjanagadde  wrote:
 On Fri, Dec 4, 2015 at 9:39 AM, Ganesh Ajjanagadde
  wrote:
> Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and
> 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning
> up usage of the formats API, and in particular fixed possible NULL
> pointer
> dereferences.
>
> This commit addresses the issue of possible resource leaks when some
> intermediate
> call fails.
>
> Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual
> simulation
> of malloc/realloc failures.
>
> Fixes: CID 1338327.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/vf_overlay.c | 32 +++-
>  1 file changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> index 3c61731..68cfb1b 100644
> --- a/libavfilter/vf_overlay.c
> +++ b/libavfilter/vf_overlay.c
> @@ -252,23 +252,31 @@ static int query_formats(AVFilterContext *ctx)
>  switch (s->format) {
>  case OVERLAY_FORMAT_YUV420:
>  if (!(main_formats=
> ff_make_format_list(main_pix_fmts_yuv420)) ||
> -!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv420)))
> -return AVERROR(ENOMEM);
> +!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv420))) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
>  break;
>  case OVERLAY_FORMAT_YUV422:
>  if (!(main_formats=
> ff_make_format_list(main_pix_fmts_yuv422)) ||
> -!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv422)))
> -return AVERROR(ENOMEM);
> +!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv422))) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
>  break;
>  case OVERLAY_FORMAT_YUV444:
>  if (!(main_formats=
> ff_make_format_list(main_pix_fmts_yuv444)) ||
> -!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv444)))
> -return AVERROR(ENOMEM);
> +!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv444))) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
>  break;
>  case OVERLAY_FORMAT_RGB:
>  if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb))
> ||
> -!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_rgb)))
> -return AVERROR(ENOMEM);
> +!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_rgb))) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
>  break;
>  default:
>  av_assert0(0);
> @@ -277,9 +285,15 @@ static int query_formats(AVFilterContext *ctx)
>  if ((ret = ff_formats_ref(main_formats   ,
> >inputs[MAIN]->out_formats   )) < 0 ||
>  (ret = ff_formats_ref(overlay_formats,
> >inputs[OVERLAY]->out_formats)) < 0 ||
>  (ret = ff_formats_ref(main_formats   ,
> >outputs[MAIN]->in_formats   )) < 0)
> -return ret;
> +goto fail;
>
>  return 0;
> +fail:
> +av_freep(_formats->formats);
> +av_freep(_formats);
> +av_freep(_formats->formats);
> +av_freep(_formats);
> +return ret;
>  }
>
>  static const enum AVPixelFormat alpha_pix_fmts[] = {
> --
> 2.6.3
>

 pushed, with the necessary modification described by Clement
>>>
>>> This tries to dereference uninitialized value.
>>
>> See right above; I did the desired modification and believe there is no
>> issue.
>> I might be wrong; but if so, could you please refer to the relevant
>> cvslog message?
>> Thanks.
>
> libavfilter/vf_overlay.c:275:13: warning: variable 'overlay_formats'
> is used uninitialized whenever '||' condition is true
> [-Wsometimes-uninitialized]
> if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) ||
> ^~~
> libavfilter/vf_overlay.c:295:9: note: uninitialized use occurs here
> if (overlay_formats)
> ^~~
> libavfilter/vf_overlay.c:275:13: note: remove the '||' if its
> condition is always false
> if (!(main_formats= 

Re: [FFmpeg-devel] [RFC][WIP][PATCH] avfilter: add SOFAlizer audio filter

[Michael Niedermayer]

On Thu, Dec 10, 2015 at 12:43:58AM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/Makefile   |   1 +
>  libavfilter/af_sofalizer.c | 816 
> +
>  libavfilter/allfilters.c   |   1 +
>  3 files changed, 818 insertions(+)
>  create mode 100644 libavfilter/af_sofalizer.c
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 8884d1d..d7a3f61 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -87,6 +87,7 @@ OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER)  += 
> af_sidechaincompress.o
>  OBJS-$(CONFIG_SIDECHAINGATE_FILTER)  += af_agate.o
>  OBJS-$(CONFIG_SILENCEDETECT_FILTER)  += af_silencedetect.o
>  OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += af_silenceremove.o
> +OBJS-$(CONFIG_SOFALIZER_FILTER)  += af_sofalizer.o
>  OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
>  OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o
>  OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
> diff --git a/libavfilter/af_sofalizer.c b/libavfilter/af_sofalizer.c
> new file mode 100644
> index 000..8e4da74
> --- /dev/null
> +++ b/libavfilter/af_sofalizer.c
> @@ -0,0 +1,816 @@
> +/*
> + * sofalizer.c : SOFAlizer filter for virtual binaural acoustics
> + 
> *
> + * Copyright (C) 2013-2015 Andreas Fuchs, Wolfgang Hrauda,
> + * Acoustics Research Institute (ARI), Vienna, 
> Austria
> + *
> + * Authors: Andreas Fuchs 
> + *  Wolfgang Hrauda 
> + *
> + * SOFAlizer project coordinator at ARI, main developer of SOFA:
> + *  Piotr Majdak 
> + *
> + * This program 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.
> + *
> + * This program 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 this program; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301, USA.
> + 
> */
> +
> +#include 

make distclean ; ./configure && make -j12

libavfilter/af_sofalizer.c:28:20: fatal error: netcdf.h: No such file or 
directory
compilation terminated.

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mov: Enable parser for mp3s by old HandBrake

[Michael Niedermayer]

On Thu, Dec 10, 2015 at 10:37:42AM +0100, Moritz Barsnick wrote:
> On Wed, Dec 09, 2015 at 22:24:08 +0100, Michael Niedermayer wrote:
> > +if (sscanf(str, "HandBrake %d.%d.%d", , , ) 
> > == 3) {
> > +c->handbrake_version = 100*major + 1000*minor + micro;
> [...]
> > +if (mov->handbrake_version &&
> > +mov->handbrake_version <= 100*0 + 1000*10 + 0 &&
> 
> Really hard to read for all the '1's and '0'. You're checking for "<=
> 0.10.0"? Perhaps better to clearly document that.

comment added


> 
> So starting with 0.10.1, behavior is different?

we have a file from 0.10.0 which is affected, i do not know if
later versions are affected, if somone knows or someone submits
files from later versions which are affected then this can be
updated

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] compile ffmpeg errors

[????????]

I use below commands to compile ffmpeg, but make command reports some errors.


git clone https://github.com/FFmpeg/FFmpeg.git
cd FFmpeg
git checkout origin/release/2.8

PKG_CONFIG_PATH="${DEST}/build/lib/pkgconfig" ./configure 
--prefix="${DEST}/build" \
--extra-cflags="-I${DEST}/build/include" --extra-ldflags="-L${DEST}/build/lib" 
bindir="${DEST}/bin" \
--pkg-config-flags="--static" --enable-shared --enable-pic --enable-gpl 
--enable-nonfree --enable-libfdk-aac --enable-libfreetype \
--enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx 
--enable-libx264 --enable-libx265
make



libavfilter/avf_showcqt.c:38:10: error: #include expects "FILENAME" or 

libavfilter/vf_drawtext.c:69:10: error: #include expects "FILENAME" or 

libavfilter/vf_drawtext.c:70:10: error: #include expects "FILENAME" or 

libavfilter/vf_drawtext.c:71:10: error: #include expects "FILENAME" or 

libavfilter/vf_drawtext.c:275:10: error: #include expects "FILENAME" or 

ffplay.c:3217:46: error: missing binary operator before token "("
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun
 wrote:
> On 10.12.2015 15:18, Philip Langdale wrote:
>> On 2015-12-10 06:05, Andreas Cadhalpun wrote:
>>> On 09.12.2015 17:38, Hendrik Leppkes wrote:
 On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler  
 wrote:
> If I understand carl right, the question is not about the header, but
> about if dlopen'ing a non-free library, the CUDA and NVENC ones in this
> case, makes ffmpeg non-free, or if they are system libraries and thus
> it's ok to link against them.
>

 The generated binary contains no non-free code, not even used a
 non-free header, nor does it depend on any non-free binary to run.
>>>
>>> Well, most of the binary code generated from nvenc.c requires the
>>> non-free libcuda.so and libnvidia-encode.so.1 blobs to run.
>>>
 And even if you want to cite that particular rule - if drivers are not
 considered part of the system, then I don't know what is.
>>>
>>> What is a system library depends on the system.
>>> For example, Debian (main) does not even include libcuda or
>>> libnvidia-encode, so they certainly cannot be system libraries there.
>>
>> I am not a lawyer, etc, so make of this what you will, but:
>
> Neither am I and I'm not giving any legal advice here.
> I just wanted to point out that the system library exception obviously
> doesn't apply and since your rationale below doesn't mention it,
> I think you agree.
>
>> The GPL controls distribution of the work and derived works because that's
>> what the licence can control.
>
> Agreed.
>
>> The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg
>> and the nvEncodeAPI.h is also clearly not a derived work.
>
> True.
>
>> The ffmpeg binary that results from including nvEncodeAPI.h is GPL
>> compatible because nvEncodeAPI.h is MIT licenced.
>
> I'm not sure it's that easy. If that were correct, it would become
> GPL-compatible to distribute a GPL-licensed program linked with a
> proprietary library by simply inserting a MIT licensed header in the middle.
>
>> The only time the GPL ffmpeg and the proprietary licenced nvidia libraries
>> are combined is on the end user system so no distribution occurs, so the
>> GPL language doesn't apply at that stage.
>
> However, the object code compiled from nvenc.c would get distributed as part 
> of
> the ffmpeg binaries, which is governed by the GPL.
>
>> The whole deal with proprietary drivers for the linux kernel is controversial
>> because the proprietary driver can be considered a derived work of the kernel
>> because it implements kernel interfaces and uses kernel code and is intended
>> for use with the kernel. Clearly the nvenc library and API have no 
>> relationship
>> with ffmpeg - they are independently developed works with other consumers and
>> using them from ffmpeg does not change this fact.
>
> That's unrelated to the problem at hand.
>
>> Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to
>> modify or replace any part of ffmpeg as they wish, including modifying it to
>> no longer have anything to do with nvenc.
>
> Including nvEncodeAPI.h is not causing the license problem, distributing the
> object code generated from nvenc.c is.
>
>> So really, I'm not sure what the rationale is for thinking it's a GPL 
>> violation
>> to include the MIT licenced nvEncodeAPI.h and to distribute a binary with 
>> nvenc
>> support in it. I'd be interested to hear the reasoning.
>
> The GPL-3 requires that the 'Corresponding Source' of the distributed object 
> code
> is also distributed. This is defined as [1]:
> The “Corresponding Source” for a work in object code form means all the source
> code needed to generate, install, and (for an executable work) run the object
> code[...]
> For example, Corresponding Source includes [...] the source code for [...]
> dynamically linked subprograms that the work is specifically designed to 
> require,
> such as by intimate data communication or control flow between those 
> subprograms
> and other parts of the work.
>

This rule does not apply to system libraries, which I still am quite
sure a hardware driver would fall under (and we can argue about that
all day, you won't get any "proof" either way)
If a particular system does not actually package this particular
library, then their distribution of FFmpeg should probably just not
enable nvenc, its of no use without the library anyway.

You could argue the same thing for QuickSync, the only difference is
that it depends on some sort of "dispatcher" library that sits between
FFmpeg and the closed-source library.
Does the existence of a tiny dispatcher library suddenly "fix" these
rules? That would be silly. Yet it is widely accepted that linking
against libmfx for qsv is fine.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 10.12.2015 16:49, Hendrik Leppkes wrote:
> On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun
>  wrote:
>> The GPL-3 requires that the 'Corresponding Source' of the distributed object 
>> code
>> is also distributed. This is defined as [1]:
>> The “Corresponding Source” for a work in object code form means all the 
>> source
>> code needed to generate, install, and (for an executable work) run the object
>> code[...]
>> For example, Corresponding Source includes [...] the source code for [...]
>> dynamically linked subprograms that the work is specifically designed to 
>> require,
>> such as by intimate data communication or control flow between those 
>> subprograms
>> and other parts of the work.
>>
> 
> This rule does not apply to system libraries,

Yes.

> which I still am quite
> sure a hardware driver would fall under (and we can argue about that
> all day, you won't get any "proof" either way)
> If a particular system does not actually package this particular
> library, then their distribution of FFmpeg should probably just not
> enable nvenc, its of no use without the library anyway.

But if it did, it would certainly not fall under the system library exception.
If that's the only thing that allows distribution of compiled nvenc.c,
it shouldn't be enabled by default.

> You could argue the same thing for QuickSync, the only difference is
> that it depends on some sort of "dispatcher" library that sits between
> FFmpeg and the closed-source library.

Yes, that looks like a similar problem.

> Does the existence of a tiny dispatcher library suddenly "fix" these
> rules?

I don't think so, but I haven't looked at the code.

> That would be silly. Yet it is widely accepted that linking
> against libmfx for qsv is fine.

If it is 'widely accepted' that distribution of the resulting object
code is GPL compatible, then you can certainly provide links
to statements from experts saying so, e.g. from someone from the FSF.
Unless you do, 'widely accepted' is a void argument.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-10 06:05, Andreas Cadhalpun wrote:

On 09.12.2015 17:38, Hendrik Leppkes wrote:
On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler 
 wrote:

If I understand carl right, the question is not about the header, but
about if dlopen'ing a non-free library, the CUDA and NVENC ones in 
this

case, makes ffmpeg non-free, or if they are system libraries and thus
it's ok to link against them.



The generated binary contains no non-free code, not even used a
non-free header, nor does it depend on any non-free binary to run.


Well, most of the binary code generated from nvenc.c requires the
non-free libcuda.so and libnvidia-encode.so.1 blobs to run.


And even if you want to cite that particular rule - if drivers are not
considered part of the system, then I don't know what is.


What is a system library depends on the system.
For example, Debian (main) does not even include libcuda or
libnvidia-encode, so they certainly cannot be system libraries there.


I am not a lawyer, etc, so make of this what you will, but:

The GPL controls distribution of the work and derived works because 
that's
what the licence can control. The nvidia cuda and nvenc libraries are 
clearly
not derived works of ffmpeg and the nvEncodeAPI.h is also clearly not a 
derived

work. The ffmpeg binary that results from including nvEncodeAPI.h is GPL
compatible because nvEncodeAPI.h is MIT licenced. The only time the GPL 
ffmpeg
and the proprietary licenced nvidia libraries are combined is on the end 
user
system so no distribution occurs, so the GPL language doesn't apply at 
that

stage.

The whole deal with proprietary drivers for the linux kernel is 
controversial
because the proprietary driver can be considered a derived work of the 
kernel
because it implements kernel interfaces and uses kernel code and is 
intended
for use with the kernel. Clearly the nvenc library and API have no 
relationship
with ffmpeg - they are independently developed works with other 
consumers and

using them from ffmpeg does not change this fact.

Additionally, including nvEncodeAPI.h does not inhibit anybody's ability 
to
modify or replace any part of ffmpeg as they wish, including modifying 
it to

no longer have anything to do with nvenc.

So really, I'm not sure what the rationale is for thinking it's a GPL 
violation
to include the MIT licenced nvEncodeAPI.h and to distribute a binary 
with nvenc

support in it. I'd be interested to hear the reasoning.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-09 21:34, wm4 wrote:

On Mon, 7 Dec 2015 19:34:20 +0100
Timo Rothenpieler  wrote:


> I don't remember if this was discussed when avisynth and other headers
> where included, but what's the advantage of directly including the
> header and burden the FFmpeg sources, rather than asking the user to
> download them in case of need?

The nvenc sdk isn't exactly a common thing that distributions provide.
As distributions can now easily ship ffmpeg with nvenc support, this
propably helps users who now no longer need to build ffmpeg themselves
for nvenc support.


So why would distros build with nvenc support, if they can't even do a
simple thing like installing a single header file?

Are we really talking about including a huge 3rd party header because
distros are so lazy? What's next, do we add Windows headers to the
FFmpeg tree, because MinGW lags severely behind the newest definitions
like HEVC DXVA support?

We could just provide a download link for the nvenc header somewhere if
the problem is finding the header.


Admittedly, we are solving someone else's problem, but the header is
buried inside the SDK download which is hidden behind a click-through on
nvidia's web page. So it's not made available in a way that is readily
consumable by an end user or by a distribution vendor.

With the new licencing, a distro vendor *could* take the header and 
package
it up themselves, but that's the sort of them that's exceptionally hard 
to

convince them to do.

And in the case of windows (where nvenc works too), there is no distro 
vendor
and nvidia certainly won't make the header more accessible than it 
already is.


If the goal is to make the feature as available as possible to as many 
users

as possible, then this is the way to do it.

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

[FFmpeg-devel] [PATCH RFC] avfilter/vf_delogo: Use AVPixFmtDescriptor.nb_components

[Jean Delvare]

Relying on AVPixFmtDescriptor.nb_components is cleaner and faster than
checking data and linesize for every possible plane.

Signed-off-by: Jean Delvare 
---
I see that most filters use AVPixFmtDescriptor.nb_components while
others still check data and linesize. Am I correct assuming that the
former is faster and preferred?

 libavfilter/vf_delogo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- ffmpeg.orig/libavfilter/vf_delogo.c 2015-12-10 13:06:16.212908502 +0100
+++ ffmpeg/libavfilter/vf_delogo.c  2015-12-10 13:07:04.877966120 +0100
@@ -256,7 +256,7 @@ static int filter_frame(AVFilterLink *in
 if (!sar.num)
 sar.num = sar.den = 1;
 
-for (plane = 0; plane < 4 && in->data[plane] && in->linesize[plane]; 
plane++) {
+for (plane = 0; plane < desc->nb_components; plane++) {
 int hsub = plane == 1 || plane == 2 ? hsub0 : 0;
 int vsub = plane == 1 || plane == 2 ? vsub0 : 0;
 


-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 10.12.2015 15:18, Philip Langdale wrote:
> On 2015-12-10 06:05, Andreas Cadhalpun wrote:
>> On 09.12.2015 17:38, Hendrik Leppkes wrote:
>>> On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler  
>>> wrote:
 If I understand carl right, the question is not about the header, but
 about if dlopen'ing a non-free library, the CUDA and NVENC ones in this
 case, makes ffmpeg non-free, or if they are system libraries and thus
 it's ok to link against them.

>>>
>>> The generated binary contains no non-free code, not even used a
>>> non-free header, nor does it depend on any non-free binary to run.
>>
>> Well, most of the binary code generated from nvenc.c requires the
>> non-free libcuda.so and libnvidia-encode.so.1 blobs to run.
>>
>>> And even if you want to cite that particular rule - if drivers are not
>>> considered part of the system, then I don't know what is.
>>
>> What is a system library depends on the system.
>> For example, Debian (main) does not even include libcuda or
>> libnvidia-encode, so they certainly cannot be system libraries there.
> 
> I am not a lawyer, etc, so make of this what you will, but:

Neither am I and I'm not giving any legal advice here.
I just wanted to point out that the system library exception obviously
doesn't apply and since your rationale below doesn't mention it,
I think you agree.

> The GPL controls distribution of the work and derived works because that's
> what the licence can control.

Agreed.

> The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg
> and the nvEncodeAPI.h is also clearly not a derived work.

True.

> The ffmpeg binary that results from including nvEncodeAPI.h is GPL
> compatible because nvEncodeAPI.h is MIT licenced.

I'm not sure it's that easy. If that were correct, it would become
GPL-compatible to distribute a GPL-licensed program linked with a
proprietary library by simply inserting a MIT licensed header in the middle.

> The only time the GPL ffmpeg and the proprietary licenced nvidia libraries
> are combined is on the end user system so no distribution occurs, so the
> GPL language doesn't apply at that stage.

However, the object code compiled from nvenc.c would get distributed as part of
the ffmpeg binaries, which is governed by the GPL.

> The whole deal with proprietary drivers for the linux kernel is controversial
> because the proprietary driver can be considered a derived work of the kernel
> because it implements kernel interfaces and uses kernel code and is intended
> for use with the kernel. Clearly the nvenc library and API have no 
> relationship
> with ffmpeg - they are independently developed works with other consumers and
> using them from ffmpeg does not change this fact.

That's unrelated to the problem at hand.

> Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to
> modify or replace any part of ffmpeg as they wish, including modifying it to
> no longer have anything to do with nvenc.

Including nvEncodeAPI.h is not causing the license problem, distributing the
object code generated from nvenc.c is.

> So really, I'm not sure what the rationale is for thinking it's a GPL 
> violation
> to include the MIT licenced nvEncodeAPI.h and to distribute a binary with 
> nvenc
> support in it. I'd be interested to hear the reasoning.

The GPL-3 requires that the 'Corresponding Source' of the distributed object 
code
is also distributed. This is defined as [1]:
The “Corresponding Source” for a work in object code form means all the source
code needed to generate, install, and (for an executable work) run the object
code[...]
For example, Corresponding Source includes [...] the source code for [...]
dynamically linked subprograms that the work is specifically designed to 
require,
such as by intimate data communication or control flow between those subprograms
and other parts of the work.

Why should that not apply to the dynamically linked libcuda/libnvidia-encode?

Best regards,
Andreas


1: https://www.gnu.org/licenses/gpl-3.0-standalone.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserdec: replace pow by exp2

[Michael Niedermayer]

On Wed, Dec 09, 2015 at 07:02:02PM -0500, Ganesh Ajjanagadde wrote:
> exp2 suffices here.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/nellymoserdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Matt Oliver]

>
> > >>> What is a system library depends on the system.
> > >>> For example, Debian (main) does not even include libcuda or
> > >>> libnvidia-encode, so they certainly cannot be system libraries there.
> > >>
>

Im not sure that Debian not including libcuda is a valid argument for it
not being a system library as thats just one OS. To me thats the same as
saying that win32 stuff is not part of a system library because Debian
doesnt have it (for obvious reasons). So I dont believe that just because
some systems dont have it doesnt stop it from being a system library. And
if a system doesnt have the required propriety libs then they wont be
loaded at runtime and therefore no proprietary code is ever used at all.

> > The ffmpeg binary that results from including nvEncodeAPI.h is GPL
> > > compatible because nvEncodeAPI.h is MIT licenced.
> >
> > I'm not sure it's that easy. If that were correct, it would become
> > GPL-compatible to distribute a GPL-licensed program linked with a
> > proprietary library by simply inserting a MIT licensed header in the
> middle.
>

In this case thats not what is being said as we are not actually linking
against anything. As if we did link against a propriety lib then you would
be correct and this would brake GPL but that is not the case as the nvenc
binaries are only accessed at runtime. All were doing here is including a
single header file.

> > The only time the GPL ffmpeg and the proprietary licenced nvidia
> libraries
> > > are combined is on the end user system so no distribution occurs, so
> the
> > > GPL language doesn't apply at that stage.
> >
> > However, the object code compiled from nvenc.c would get distributed as
> part of
> > the ffmpeg binaries, which is governed by the GPL.
>

The object code from nvenc.c is written using LGPL and just includes
declarations (no actual code definitions) from a MIT header file which to
me suggests that the part of ffmpeg that would be distributed is still GPL
compliant. At no point during the entire compilation and linking stage is
any proprietary component touched so I dont see how this brakes anything.
So sorry for being verbose (and potential just stating the obvious) but the
only argument here is whether we can consider the libs accessed at runtime
as system libs or not.

To use windows as a further example all the actual binary code required for
nvenc to work is part of the graphics drivers. So the only time anything
not GPL compliant is ever used is when the dll's are loaded at runtime from
the driver. This definitely puts it in the category of a system component
in my mind. If drivers are not considered system libs then we have far more
serious problems than nvenc ;)

Admittedly, we are solving someone else's problem, but the header is
> buried inside the SDK download which is hidden behind a click-through on
> nvidia's web page. So it's not made available in a way that is readily
> consumable by an end user or by a distribution vendor.
>
> With the new licencing, a distro vendor *could* take the header and package
> it up themselves, but that's the sort of them that's exceptionally hard to
> convince them to do.
>
> And in the case of windows (where nvenc works too), there is no distro
> vendor
> and nvidia certainly won't make the header more accessible than it already
> is.


I agree with Philip here as the nvEncodeApi header is not part of a cuda
sdk install and requires a separate download. One which is not as easily
accessible and one that requires a good 90MB download just to use 1 header
file. Since the header is all that is needed and it is not part of a
standard sdk then I think the inclusion of avisynths headers already sets a
precedent to also include this one. Including it also allows ffmpeg to
ensure that the correct newer MIT licensed version is the only one being
used. Of course this does put the burden on ffmpeg to ensure that the
header is kept up to date but as long as someone does that then I support
its inclusion (I dont see an issue with keeping it up to date as anyone
adding new features will inherently update it and any breakage would be a
result of the interfaces changing which would brake ffmpeg anyway).

So the updated patch looks good to me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel