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

[Stephen Hutchinson]

On 5/6/2016 6:08 AM, Hendrik Leppkes wrote:

On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu  wrote:

On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:


On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:

On 1/30/2016 7:15 PM, Timothy Gu wrote:

FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.


Perhaps this should be restricted to x86?


Fair enough.



Pushed.



Just to document it, this has caused build breakage in various
scenarios, even in GCC 5.3 (6.1 not tested).

The latest reported on IRC just today here:
libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
libavcodec/sbrdsp.c:47:13: internal compiler error: in
vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
  static void sbr_neg_odd_64_c(float *x)

There are various other cases which usually involve inline asm when
building with SIMD (ie. --cpu=host) and the optimizer running out of
registers, for example:
libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints

IMHO this feature is not quite ready to be enabled unconditionally in
our code base, and we should re-evaluate this change.

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



It may also be miscompiling the code on i686 (or specifically MinGW-w64 
builds on i686), since I was encountering segfaults at random at 
startup* in builds of mpv linked against affected FFmpeg builds, but not 
in ffmpeg.exe itself.  Disabling tree vectorization in extra-cflags 
resolved it.


It might work seemingly correctly the first couple invocations,
then start crashing on #4 onward.  But then at a different
time, it would always fail, or work a different number of
times before failing. That was on Silvermont* with 2 GBs of RAM;
on my old Pentium III and 512 MBs of RAM, it seemed to always
fail.

*still 32-bit Windows, though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/riff: add M102 FourCC

[Michael Niedermayer]

On Fri, May 06, 2016 at 10:48:32PM +0200, Piotr Bandurski wrote:
> From b365a1b2544e5e70652f41e7e8bf4066fb778b4c Mon Sep 17 00:00:00 2001
> From: Piotr Bandurski 
> Date: Fri, 6 May 2016 22:43:00 +0200
> Subject: [PATCH] avformat/riff: add M102 FourCC
> 
> ---
>  libavformat/riff.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/libavformat/riff.c b/libavformat/riff.c
> index ccbe608..dd20aff 100644
> --- a/libavformat/riff.c
> +++ b/libavformat/riff.c
> @@ -420,6 +420,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
>  { AV_CODEC_ID_RSCC, MKTAG('I', 'S', 'C', 'C') },
>  { AV_CODEC_ID_CFHD, MKTAG('C', 'F', 'H', 'D') },
>  { AV_CODEC_ID_M101, MKTAG('M', '1', '0', '1') },
> +{ AV_CODEC_ID_M101, MKTAG('M', '1', '0', '2') },
>  
>  { AV_CODEC_ID_NONE, 0 }

applied

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

Re: [FFmpeg-devel] [PATCH] hevc: fix size condition in ptl parsing

[Michael Niedermayer]

On Fri, May 06, 2016 at 07:15:06PM +0200, Hendrik Leppkes wrote:
> When only one sublayer is present, no information is coded. Only when at 
> least two
> are present, all 8 sublayers are written.
> ---
>  libavcodec/hevc_ps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

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

[James Almer]

On 5/6/2016 9:56 PM, Hendrik Leppkes wrote:
> On Sat, May 7, 2016 at 2:02 AM, James Almer  wrote:
>> On 5/6/2016 8:48 PM, Timothy Gu wrote:
>>> On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote:

 Just to document it, this has caused build breakage in various
 scenarios, even in GCC 5.3 (6.1 not tested).

 The latest reported on IRC just today here:
 libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
 libavcodec/sbrdsp.c:47:13: internal compiler error: in
 vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
  static void sbr_neg_odd_64_c(float *x)

 There are various other cases which usually involve inline asm when
 building with SIMD (ie. --cpu=host) and the optimizer running out of
 registers, for example:
 libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible 
 constraints

 IMHO this feature is not quite ready to be enabled unconditionally in
 our code base, and we should re-evaluate this change.
>>>
>>> I don't have a problem with reverting this commit, but as James mentioned I 
>>> do
>>> prefer the bug to be reported to GCC if possible.
>>>
>>> Have you also considered the possibility to enable this feature only if 
>>> inline
>>> assembly is not enabled?
>>
>> Nobody disables inline asm when using GCC, so it'd be the same as removing 
>> tree
>> vectorization altogether to begin with.
>>
>> This feature gives some nice speed boost on parts of the code that don't have
>> hand written asm, so I'd very much rather keep it and try to get GCC to fix 
>> bugs
>> on their compilers.
> 
> Fixing would be nice of course, but it should then only be enabled in
> versions we know do not have problems, which is none right now.
> 
> - Hendrik

Again, do you know the configure options or compile flags that triggered these 
compiler errors? None of the many GCC 5.3 FATE clients reproduce them, so it 
must
be a specific combination of compile flags.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Hendrik Leppkes]

On Sat, May 7, 2016 at 2:02 AM, James Almer  wrote:
> On 5/6/2016 8:48 PM, Timothy Gu wrote:
>> On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote:
>>>
>>> Just to document it, this has caused build breakage in various
>>> scenarios, even in GCC 5.3 (6.1 not tested).
>>>
>>> The latest reported on IRC just today here:
>>> libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
>>> libavcodec/sbrdsp.c:47:13: internal compiler error: in
>>> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
>>>  static void sbr_neg_odd_64_c(float *x)
>>>
>>> There are various other cases which usually involve inline asm when
>>> building with SIMD (ie. --cpu=host) and the optimizer running out of
>>> registers, for example:
>>> libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible 
>>> constraints
>>>
>>> IMHO this feature is not quite ready to be enabled unconditionally in
>>> our code base, and we should re-evaluate this change.
>>
>> I don't have a problem with reverting this commit, but as James mentioned I 
>> do
>> prefer the bug to be reported to GCC if possible.
>>
>> Have you also considered the possibility to enable this feature only if 
>> inline
>> assembly is not enabled?
>
> Nobody disables inline asm when using GCC, so it'd be the same as removing 
> tree
> vectorization altogether to begin with.
>
> This feature gives some nice speed boost on parts of the code that don't have
> hand written asm, so I'd very much rather keep it and try to get GCC to fix 
> bugs
> on their compilers.

Fixing would be nice of course, but it should then only be enabled in
versions we know do not have problems, which is none right now.

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

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

[James Almer]

On 5/6/2016 8:48 PM, Timothy Gu wrote:
> On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote:
>>
>> Just to document it, this has caused build breakage in various
>> scenarios, even in GCC 5.3 (6.1 not tested).
>>
>> The latest reported on IRC just today here:
>> libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
>> libavcodec/sbrdsp.c:47:13: internal compiler error: in
>> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
>>  static void sbr_neg_odd_64_c(float *x)
>>
>> There are various other cases which usually involve inline asm when
>> building with SIMD (ie. --cpu=host) and the optimizer running out of
>> registers, for example:
>> libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints
>>
>> IMHO this feature is not quite ready to be enabled unconditionally in
>> our code base, and we should re-evaluate this change.
> 
> I don't have a problem with reverting this commit, but as James mentioned I do
> prefer the bug to be reported to GCC if possible.
> 
> Have you also considered the possibility to enable this feature only if inline
> assembly is not enabled?

Nobody disables inline asm when using GCC, so it'd be the same as removing tree
vectorization altogether to begin with.

This feature gives some nice speed boost on parts of the code that don't have
hand written asm, so I'd very much rather keep it and try to get GCC to fix bugs
on their compilers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Timothy Gu]

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

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

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

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

Re: [FFmpeg-devel] [PATCH] fate: add matroska-remux test.

[Michael Niedermayer]

On Fri, May 06, 2016 at 09:27:20AM -0400, Ronald S. Bultje wrote:
> This tests automatic insertion of the vp9_superframe BSF as well as
> ensuring that the colorspace properties in the video header can be
> modified when remuxing (-c:v copy).
> ---
>  tests/Makefile  | 1 +
>  tests/fate/matroska.mak | 9 +
>  2 files changed, 10 insertions(+)
>  create mode 100644 tests/fate/matroska.mak

LGTM

thx

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

You can kill me, but you cannot change the truth.


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/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.

[Michael Niedermayer]

On Fri, May 06, 2016 at 03:44:49PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, May 6, 2016 at 2:55 PM, Michael Niedermayer 
> wrote:
> 
> > On Fri, May 06, 2016 at 01:17:56PM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Fri, May 6, 2016 at 10:14 AM, Michael Niedermayer
> >  > > > wrote:
> > >
> > > > On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote:
> > > > > ---
> > > > >  doc/filters.texi |  13 
> > > > >  libavfilter/colorspacedsp.c  |  13 
> > > > >  libavfilter/colorspacedsp.h  |   6 ++
> > > > >  libavfilter/colorspacedsp_template.c | 128
> > > > +++
> > > > >  libavfilter/vf_colorspace.c  |  64 +-
> > > > >  5 files changed, 221 insertions(+), 3 deletions(-)
> > > >
> > > > i cant test this:
> > > >
> > > > Applying: vf_colorspace: add floyd-steinberg dithering option to full
> > > > conversion.
> > > > fatal: sha1 information is lacking or useless
> > > > (libavfilter/vf_colorspace.c).
> > > > Repository lacks necessary blobs to fall back on 3-way merge.
> > > > Cannot fall back to three-way merge.
> > >
> > >
> > > https://github.com/rbultje/ffmpeg/commits/colorspace
> >
> >
> > --- ./tests/ref/lavf/mov2016-05-05 02:36:06.272607621 +0200
> > +++ tests/data/fate/lavf-mov2016-05-06 20:52:39.831813922 +0200
> > @@ -13,9 +13,9 @@
> >  ebca72c186a4f3ba9bb17d9cb5b74fef *./tests/data/lavf/lavf.mp4
> >  312457 ./tests/data/lavf/lavf.mp4
> >  ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a
> > -9944512475d82d2d601f3c96101bdf9c *./tests/data/lavf/lavf.mp4
> > -321343 ./tests/data/lavf/lavf.mp4
> > -./tests/data/lavf/lavf.mp4 CRC=0xe8130120
> > +38b6bcf55731a5905f58c071e8961d4d *./tests/data/lavf/lavf.mp4
> > +312570 ./tests/data/lavf/lavf.mp4
> > +./tests/data/lavf/lavf.mp4 CRC=0xb5cb0057
> >  7b3e71f294901067046c09f03a426bdc *./tests/data/lavf/lavf.mp4
> >  312001 ./tests/data/lavf/lavf.mp4
> >  ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a
> > Test lavf-mov failed. Look at tests/data/fate/lavf-mov.err for details.
> > make: *** [fate-lavf-mov] Error 1
> > git bisect bad
> > c9b2411cae0e604697b5daf7413077fe325c4208 is the first bad commit
> > commit c9b2411cae0e604697b5daf7413077fe325c4208
> > Author: Ronald S. Bultje 
> > Date:   Mon Feb 15 08:29:40 2016 -0500
> >
> > mov: set variable fps flag.
> 
> 
> I'll remove that commit, it's something unrelated that was dangling in my
> tree...

fate works fine here without the commit

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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/riff: add M102 FourCC

[Piotr Bandurski]

samples are here:

https://www.datafilehost.com/d/1a93d9a6

(some matrox uncompressed samples I posted to ticket #2616 are invalid due to 
bug in the older version of matrox codec which I used to encode them)

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

[FFmpeg-devel] [PATCH] avformat/riff: add M102 FourCC

[Piotr Bandurski]

0001-avformat-riff-add-M102-FourCC.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.

[Ronald S. Bultje]

Hi,

On Fri, May 6, 2016 at 2:55 PM, Michael Niedermayer 
wrote:

> On Fri, May 06, 2016 at 01:17:56PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, May 6, 2016 at 10:14 AM, Michael Niedermayer
>  > > wrote:
> >
> > > On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote:
> > > > ---
> > > >  doc/filters.texi |  13 
> > > >  libavfilter/colorspacedsp.c  |  13 
> > > >  libavfilter/colorspacedsp.h  |   6 ++
> > > >  libavfilter/colorspacedsp_template.c | 128
> > > +++
> > > >  libavfilter/vf_colorspace.c  |  64 +-
> > > >  5 files changed, 221 insertions(+), 3 deletions(-)
> > >
> > > i cant test this:
> > >
> > > Applying: vf_colorspace: add floyd-steinberg dithering option to full
> > > conversion.
> > > fatal: sha1 information is lacking or useless
> > > (libavfilter/vf_colorspace.c).
> > > Repository lacks necessary blobs to fall back on 3-way merge.
> > > Cannot fall back to three-way merge.
> >
> >
> > https://github.com/rbultje/ffmpeg/commits/colorspace
>
>
> --- ./tests/ref/lavf/mov2016-05-05 02:36:06.272607621 +0200
> +++ tests/data/fate/lavf-mov2016-05-06 20:52:39.831813922 +0200
> @@ -13,9 +13,9 @@
>  ebca72c186a4f3ba9bb17d9cb5b74fef *./tests/data/lavf/lavf.mp4
>  312457 ./tests/data/lavf/lavf.mp4
>  ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a
> -9944512475d82d2d601f3c96101bdf9c *./tests/data/lavf/lavf.mp4
> -321343 ./tests/data/lavf/lavf.mp4
> -./tests/data/lavf/lavf.mp4 CRC=0xe8130120
> +38b6bcf55731a5905f58c071e8961d4d *./tests/data/lavf/lavf.mp4
> +312570 ./tests/data/lavf/lavf.mp4
> +./tests/data/lavf/lavf.mp4 CRC=0xb5cb0057
>  7b3e71f294901067046c09f03a426bdc *./tests/data/lavf/lavf.mp4
>  312001 ./tests/data/lavf/lavf.mp4
>  ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a
> Test lavf-mov failed. Look at tests/data/fate/lavf-mov.err for details.
> make: *** [fate-lavf-mov] Error 1
> git bisect bad
> c9b2411cae0e604697b5daf7413077fe325c4208 is the first bad commit
> commit c9b2411cae0e604697b5daf7413077fe325c4208
> Author: Ronald S. Bultje 
> Date:   Mon Feb 15 08:29:40 2016 -0500
>
> mov: set variable fps flag.


I'll remove that commit, it's something unrelated that was dangling in my
tree...

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

Re: [FFmpeg-devel] [PATCH] vf_colorspace: don't enable passthrough if bitdepth doesn't match.

[Ronald S. Bultje]

Hi,

On Fri, May 6, 2016 at 3:23 PM, Michael Niedermayer 
wrote:

> On Fri, May 06, 2016 at 12:27:02PM -0400, Ronald S. Bultje wrote:
> > ---
> >  libavfilter/vf_colorspace.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> > index 7776a61..f932ce9 100644
> > --- a/libavfilter/vf_colorspace.c
> > +++ b/libavfilter/vf_colorspace.c
> > @@ -754,7 +754,8 @@ static int create_filtergraph(AVFilterContext *ctx,
> >  s->yuv2yuv_fastmode = s->rgb2rgb_passthrough && fmt_identical;
> >  s->yuv2yuv_passthrough = s->yuv2yuv_fastmode && s->in_rng ==
> s->out_rng &&
> >   !memcmp(s->in_lumacoef, s->out_lumacoef,
> > - sizeof(*s->in_lumacoef));
> > + sizeof(*s->in_lumacoef)) &&
> > + in_desc->comp[0].depth ==
> out_desc->comp[0].depth;
> >  if (!s->yuv2yuv_passthrough) {
> >  if (redo_yuv2rgb) {
> >  double rgb2yuv[3][3], (*yuv2rgb)[3] = s->yuv2rgb_dbl_coeffs;
>
> LGTM
>
>
> > @@ -986,7 +987,9 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *in)
> >  td.in_ss_h = av_pix_fmt_desc_get(in->format)->log2_chroma_h;
> >  td.out_ss_h = av_pix_fmt_desc_get(out->format)->log2_chroma_h;
> >  if (s->yuv2yuv_passthrough) {
> > -av_frame_copy(out, in);
> > +res = av_frame_copy(out, in);
> > +if (res < 0)
> > +return res;
> >  } else {
>
> unrelated ?
> but LGTM


Hm, it's sort of related to the same bug. What happened is that when
converting from yuv444p to yuv444p10, it would set passthrough=1 (because
of the bug in hunk 1), and then the lack of the check in hunk 2 would cause
the dest buffer to be uninitialized but the function would return as if it
converted succesfully.

So hunk 2 makes it fail correctly, and hunk 1 makes it then not use
passthrough for that conversion so it actually succeeds.

I'll adjust the log message to make that clearer.

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

Re: [FFmpeg-devel] [PATCH] vf_colorspace: don't enable passthrough if bitdepth doesn't match.

[Michael Niedermayer]

On Fri, May 06, 2016 at 12:27:02PM -0400, Ronald S. Bultje wrote:
> ---
>  libavfilter/vf_colorspace.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index 7776a61..f932ce9 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -754,7 +754,8 @@ static int create_filtergraph(AVFilterContext *ctx,
>  s->yuv2yuv_fastmode = s->rgb2rgb_passthrough && fmt_identical;
>  s->yuv2yuv_passthrough = s->yuv2yuv_fastmode && s->in_rng == s->out_rng 
> &&
>   !memcmp(s->in_lumacoef, s->out_lumacoef,
> - sizeof(*s->in_lumacoef));
> + sizeof(*s->in_lumacoef)) &&
> + in_desc->comp[0].depth == 
> out_desc->comp[0].depth;
>  if (!s->yuv2yuv_passthrough) {
>  if (redo_yuv2rgb) {
>  double rgb2yuv[3][3], (*yuv2rgb)[3] = s->yuv2rgb_dbl_coeffs;

LGTM


> @@ -986,7 +987,9 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
>  td.in_ss_h = av_pix_fmt_desc_get(in->format)->log2_chroma_h;
>  td.out_ss_h = av_pix_fmt_desc_get(out->format)->log2_chroma_h;
>  if (s->yuv2yuv_passthrough) {
> -av_frame_copy(out, in);
> +res = av_frame_copy(out, in);
> +if (res < 0)
> +return res;
>  } else {

unrelated ?
but LGTM

thx

[...]
-- 
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

Re: [FFmpeg-devel] [PATCH 2/3] vf_colorspace: add const to yuv_stride[] argument in DSP functions.

[Michael Niedermayer]

On Fri, May 06, 2016 at 09:06:02AM -0400, Ronald S. Bultje wrote:
> ---
>  libavfilter/colorspacedsp.h  | 10 +-
>  libavfilter/colorspacedsp_template.c |  6 +++---
>  libavfilter/colorspacedsp_yuv2yuv_template.c |  4 ++--
>  libavfilter/x86/colorspacedsp_init.c |  8 
>  4 files changed, 14 insertions(+), 14 deletions(-)

LGTM

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH 3/3] vf_colorspace: use enums for bpp/subsampling array indices.

[Michael Niedermayer]

On Fri, May 06, 2016 at 09:06:03AM -0400, Ronald S. Bultje wrote:
> Also add some documentation for each function to colorspacedsp.h.
> ---
>  libavfilter/colorspacedsp.c  | 78 
> ++--
>  libavfilter/colorspacedsp.h  | 31 --
>  libavfilter/x86/colorspacedsp_init.c | 64 ++---
>  3 files changed, 98 insertions(+), 75 deletions(-)

LGTM

thx

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.

[Michael Niedermayer]

On Fri, May 06, 2016 at 01:17:56PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, May 6, 2016 at 10:14 AM, Michael Niedermayer  > wrote:
> 
> > On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote:
> > > ---
> > >  doc/filters.texi |  13 
> > >  libavfilter/colorspacedsp.c  |  13 
> > >  libavfilter/colorspacedsp.h  |   6 ++
> > >  libavfilter/colorspacedsp_template.c | 128
> > +++
> > >  libavfilter/vf_colorspace.c  |  64 +-
> > >  5 files changed, 221 insertions(+), 3 deletions(-)
> >
> > i cant test this:
> >
> > Applying: vf_colorspace: add floyd-steinberg dithering option to full
> > conversion.
> > fatal: sha1 information is lacking or useless
> > (libavfilter/vf_colorspace.c).
> > Repository lacks necessary blobs to fall back on 3-way merge.
> > Cannot fall back to three-way merge.
> 
> 
> https://github.com/rbultje/ffmpeg/commits/colorspace


--- ./tests/ref/lavf/mov2016-05-05 02:36:06.272607621 +0200
+++ tests/data/fate/lavf-mov2016-05-06 20:52:39.831813922 +0200
@@ -13,9 +13,9 @@
 ebca72c186a4f3ba9bb17d9cb5b74fef *./tests/data/lavf/lavf.mp4
 312457 ./tests/data/lavf/lavf.mp4
 ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a
-9944512475d82d2d601f3c96101bdf9c *./tests/data/lavf/lavf.mp4
-321343 ./tests/data/lavf/lavf.mp4
-./tests/data/lavf/lavf.mp4 CRC=0xe8130120
+38b6bcf55731a5905f58c071e8961d4d *./tests/data/lavf/lavf.mp4
+312570 ./tests/data/lavf/lavf.mp4
+./tests/data/lavf/lavf.mp4 CRC=0xb5cb0057
 7b3e71f294901067046c09f03a426bdc *./tests/data/lavf/lavf.mp4
 312001 ./tests/data/lavf/lavf.mp4
 ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a
Test lavf-mov failed. Look at tests/data/fate/lavf-mov.err for details.
make: *** [fate-lavf-mov] Error 1
git bisect bad
c9b2411cae0e604697b5daf7413077fe325c4208 is the first bad commit
commit c9b2411cae0e604697b5daf7413077fe325c4208
Author: Ronald S. Bultje 
Date:   Mon Feb 15 08:29:40 2016 -0500

mov: set variable fps flag.

:04 04 aa38e6352eaab2e76519e92dd4e44fd4945b3568 
8c61d7cbd6d2de18aa5e622cd1bf7e64f32e8186 M  libavformat

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] [PATCH] hevc: fix size condition in ptl parsing

[Hendrik Leppkes]

On Fri, May 6, 2016 at 7:49 PM, Carl Eugen Hoyos  wrote:
> Hendrik Leppkes  gmail.com> writes:
>
>> -get_bits_left(gb) < 8 + 8*2) {
>> +get_bits_left(gb) < 8 + (8*2 * (max_num_sub_layers - 1 > 0))) {
>
> Isnt't "max_num_sub_layers > 1" more readable?
>

Perhaps, but this syntax is used in the function everywhere else.

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

Re: [FFmpeg-devel] [PATCH] h2645_parse: allow partial escaping

[Carl Eugen Hoyos]

Hendrik Leppkes  gmail.com> writes:

> This ports the fix from 033a533 to the new parser module in 
> prepartion of using it for the h264 decoder.h2645_parse: 
> allow partial escaping

Could this patch port ticket #5453 from one codec to the next?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] hevc: fix size condition in ptl parsing

[Carl Eugen Hoyos]

Hendrik Leppkes  gmail.com> writes:

> -get_bits_left(gb) < 8 + 8*2) {
> +get_bits_left(gb) < 8 + (8*2 * (max_num_sub_layers - 1 > 0))) {

Isnt't "max_num_sub_layers > 1" more readable?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.

[Ronald S. Bultje]

Hi,

On Fri, May 6, 2016 at 10:14 AM, Michael Niedermayer  wrote:

> On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote:
> > ---
> >  doc/filters.texi |  13 
> >  libavfilter/colorspacedsp.c  |  13 
> >  libavfilter/colorspacedsp.h  |   6 ++
> >  libavfilter/colorspacedsp_template.c | 128
> +++
> >  libavfilter/vf_colorspace.c  |  64 +-
> >  5 files changed, 221 insertions(+), 3 deletions(-)
>
> i cant test this:
>
> Applying: vf_colorspace: add floyd-steinberg dithering option to full
> conversion.
> fatal: sha1 information is lacking or useless
> (libavfilter/vf_colorspace.c).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.


https://github.com/rbultje/ffmpeg/commits/colorspace

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

[FFmpeg-devel] [PATCH] hevc: fix size condition in ptl parsing

[Hendrik Leppkes]

When only one sublayer is present, no information is coded. Only when at least 
two
are present, all 8 sublayers are written.
---
 libavcodec/hevc_ps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index ce3f3df..83f2ec2 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -280,7 +280,7 @@ static int parse_ptl(GetBitContext *gb, AVCodecContext 
*avctx,
 {
 int i;
 if (decode_profile_tier_level(gb, avctx, >general_ptl) < 0 ||
-get_bits_left(gb) < 8 + 8*2) {
+get_bits_left(gb) < 8 + (8*2 * (max_num_sub_layers - 1 > 0))) {
 av_log(avctx, AV_LOG_ERROR, "PTL information too short\n");
 return -1;
 }
-- 
2.7.2.windows.1

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

Re: [FFmpeg-devel] [PATCH] vf_colorspace: remove debug statement.

[Ronald S. Bultje]

Hi,

On Fri, May 6, 2016 at 12:02 PM, Ronald S. Bultje 
wrote:

> This always disabled lrgb2lrgb passthrough, which slightly decreases
> performance.
> ---
>  libavfilter/vf_colorspace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index d119e36..dd66a4e 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -640,7 +640,7 @@ static int create_filtergraph(AVFilterContext *ctx,
>  return AVERROR(EINVAL);
>  }
>  s->lrgb2lrgb_passthrough = !memcmp(s->in_primaries,
> s->out_primaries,
> -   sizeof(*s->in_primaries)) && 0;
> +   sizeof(*s->in_primaries));
>  if (!s->lrgb2lrgb_passthrough) {
>  double rgb2xyz[3][3], xyz2rgb[3][3], rgb2rgb[3][3];


Ignore this, this was a local tree quirk...

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

Re: [FFmpeg-devel] [Patch] Add input swap functionality to movie filter (src_movie.c)

[Reimar Döffinger]

On 04.05.2016, at 17:01, "Felt, Patrick"  wrote:

> 
> On 5/4/16, 5:52 AM, "ffmpeg-devel on behalf of Clément Bœsch" 
>  wrote:
> 
>> 
>> [...]
>>> +/* libavfilter documentation says that filter init will be called only 
>>> once.  ffmpeg calls the init twice to enable it to validate
>>> + * the complex filtering has the right input and output pads. this allows 
>>> us to bypass the first call if we've specified a stream
>>> + * specifier string */
>>> +static int initRun=0;
>>> +static int uninitRun=0;
>> 
>> You're not allowed to do this, it belongs in the local context.
> 
> I did realize that there will be issues if I tried to load the filter twice.  
> It wouldn’t function as expected with the current solution.  The problem is 
> that ffmpeg calls init twice with two different contexts so any values I set 
> in the context are cleared on the second run.  Indeed, the uninit() function 
> is called after the first round.  Named Pipes don’t like being opened and 
> closed; the ffmpeg process on the other end terminates because the reader 
> left and sent an EOF.  I need a reasonable way to prevent opening a pipe 
> twice.

Just don't open it in init, but only when it's actually needed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] h2645_parse: allow partial escaping

[Michael Niedermayer]

On Fri, May 06, 2016 at 04:30:38PM +0200, Hendrik Leppkes wrote:
> This ports the fix from 033a533 to the new parser module in prepartion
> of using it for the h264 decoder.h2645_parse: allow partial escaping
> ---
>  libavcodec/h2645_parse.c | 4 ++--

LGTM
thx

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

[FFmpeg-devel] [PATCH] vf_colorspace: remove debug statement.

[Ronald S. Bultje]

This always disabled lrgb2lrgb passthrough, which slightly decreases
performance.
---
 libavfilter/vf_colorspace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index d119e36..dd66a4e 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -640,7 +640,7 @@ static int create_filtergraph(AVFilterContext *ctx,
 return AVERROR(EINVAL);
 }
 s->lrgb2lrgb_passthrough = !memcmp(s->in_primaries, s->out_primaries,
-   sizeof(*s->in_primaries)) && 0;
+   sizeof(*s->in_primaries));
 if (!s->lrgb2lrgb_passthrough) {
 double rgb2xyz[3][3], xyz2rgb[3][3], rgb2rgb[3][3];
 
-- 
2.8.1

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

[FFmpeg-devel] [PATCH] vf_colorspace: fix range order.

[Ronald S. Bultje]

---
 libavfilter/vf_colorspace.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index dd66a4e..7776a61 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -805,8 +805,8 @@ static int create_filtergraph(AVFilterContext *ctx,
 s->yuv_offset[1][n] = off;
 fill_rgb2yuv_table(s->out_lumacoef, rgb2yuv);
 bits = 1 << (29 - out_desc->comp[0].depth);
-for (n = 0; n < 3; n++) {
-for (out_rng = s->out_y_rng, m = 0; m < 3; m++, out_rng = 
s->out_uv_rng) {
+for (out_rng = s->out_y_rng, n = 0; n < 3; n++, out_rng = 
s->out_uv_rng) {
+for (m = 0; m < 3; m++) {
 s->rgb2yuv_coeffs[n][m][0] = lrint(bits * out_rng * 
rgb2yuv[n][m] / 28672);
 for (o = 1; o < 8; o++)
 s->rgb2yuv_coeffs[n][m][o] = 
s->rgb2yuv_coeffs[n][m][0];
-- 
2.8.1

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

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

[James Almer]

On 5/6/2016 7:08 AM, Hendrik Leppkes wrote:
> On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu  wrote:
>> On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:
>>>
>>> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
 On 1/30/2016 7:15 PM, Timothy Gu wrote:
> FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.

 Perhaps this should be restricted to x86?
>>>
>>> Fair enough.
>>
>>
>> Pushed.
>>
> 
> Just to document it, this has caused build breakage in various
> scenarios, even in GCC 5.3 (6.1 not tested).
> 
> The latest reported on IRC just today here:
> libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
> libavcodec/sbrdsp.c:47:13: internal compiler error: in
> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
>  static void sbr_neg_odd_64_c(float *x)

What compile flags? How was ffmpeg configured?
I can try to reproduce it and report the bug to gcc.

> 
> There are various other cases which usually involve inline asm when
> building with SIMD (ie. --cpu=host) and the optimizer running out of
> registers, for example:
> libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints
> 
> IMHO this feature is not quite ready to be enabled unconditionally in
> our code base, and we should re-evaluate this change.
> 
> - 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] h2645_parse: allow partial escaping

[Hendrik Leppkes]

On Fri, May 6, 2016 at 4:30 PM, Hendrik Leppkes  wrote:
> This ports the fix from 033a533 to the new parser module in prepartion
> of using it for the h264 decoder.h2645_parse: allow partial escaping

Nevermind the broken message, already fixed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] h2645_parse: allow partial escaping

[Hendrik Leppkes]

This ports the fix from 033a533 to the new parser module in prepartion
of using it for the h264 decoder.h2645_parse: allow partial escaping
---
 libavcodec/h2645_parse.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index d9721a2..b9d9b48 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -38,7 +38,7 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
 nal->skipped_bytes = 0;
 #define STARTCODE_TEST  \
 if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
-if (src[i + 2] != 3) {  \
+if (src[i + 2] != 3 && src[i + 2] != 0) {   \
 /* startcode, so we must be past the end */ \
 length = i; \
 }   \
@@ -103,7 +103,7 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
 if (src[si + 2] > 3) {
 dst[di++] = src[si++];
 dst[di++] = src[si++];
-} else if (src[si] == 0 && src[si + 1] == 0) {
+} else if (src[si] == 0 && src[si + 1] == 0 && src[si + 2] != 0) {
 if (src[si + 2] == 3) { // escape
 dst[di++] = 0;
 dst[di++] = 0;
-- 
2.7.2.windows.1

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

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

[Michael Niedermayer]

On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote:
> On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu  wrote:
> > On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:
> >>
> >> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
> >> > On 1/30/2016 7:15 PM, Timothy Gu wrote:
> >> > > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.
> >> >
> >> > Perhaps this should be restricted to x86?
> >>
> >> Fair enough.
> >
> >
> > Pushed.
> >
> 
> Just to document it, this has caused build breakage in various
> scenarios, even in GCC 5.3 (6.1 not tested).
> 
> The latest reported on IRC just today here:
> libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
> libavcodec/sbrdsp.c:47:13: internal compiler error: in
> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
>  static void sbr_neg_odd_64_c(float *x)
> 
> There are various other cases which usually involve inline asm when
> building with SIMD (ie. --cpu=host) and the optimizer running out of
> registers, for example:
> libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints
> 
> IMHO this feature is not quite ready to be enabled unconditionally in
> our code base, and we should re-evaluate this change.

+1

i had a bad feeling since i saw the patch but failed to find a
case that actually broke with a easy installable compiler at that time
when i tested this back then ...

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.

[Michael Niedermayer]

On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote:
> ---
>  doc/filters.texi |  13 
>  libavfilter/colorspacedsp.c  |  13 
>  libavfilter/colorspacedsp.h  |   6 ++
>  libavfilter/colorspacedsp_template.c | 128 
> +++
>  libavfilter/vf_colorspace.c  |  64 +-
>  5 files changed, 221 insertions(+), 3 deletions(-)

i cant test this:

Applying: vf_colorspace: add floyd-steinberg dithering option to full 
conversion.
fatal: sha1 information is lacking or useless (libavfilter/vf_colorspace.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 vf_colorspace: add floyd-steinberg dithering option to 
full conversion.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".


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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

[FFmpeg-devel] [PATCH] vf_colorspace: make whitepoint adaptation mode configurable.

[Ronald S. Bultje]

Also add von kries whitepoint adaptation, and add 'identity' to turn
whitepoint adaptation off.
---
 doc/filters.texi| 15 +++
 libavfilter/vf_colorspace.c | 39 ---
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 98a002b..beee1cc 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5117,6 +5117,21 @@ No dithering
 Floyd-Steinberg dithering
 @end table
 
+@item wpadapt
+Whitepoint adaptation mode.
+
+The accepted values are:
+@table @samp
+@item bradford
+Bradford whitepoint adaptation
+
+@item vonkries
+von Kries whitepoint adaptation
+
+@item identity
+identity whitepoint adaptation (i.e. no whitepoint adaptation)
+@end table
+
 @end table
 
 The filter converts the transfer characteristics, color space and color
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 0b6fe32..d119e36 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -59,6 +59,14 @@ enum Whitepoint {
 WP_NB,
 };
 
+enum WhitepointAdaptation {
+WP_ADAPT_BRADFORD,
+WP_ADAPT_VON_KRIES,
+NB_WP_ADAPT_NON_IDENTITY,
+WP_ADAPT_IDENTITY = NB_WP_ADAPT_NON_IDENTITY,
+NB_WP_ADAPT,
+};
+
 static const enum AVColorTransferCharacteristic default_trc[CS_NB + 1] = {
 [CS_UNSPECIFIED] = AVCOL_TRC_UNSPECIFIED,
 [CS_BT470M]  = AVCOL_TRC_GAMMA22,
@@ -128,6 +136,7 @@ typedef struct ColorSpaceContext {
 enum AVPixelFormat in_format, user_format;
 int fast_mode;
 enum DitherMode dither;
+enum WhitepointAdaptation wp_adapt;
 
 int16_t *rgb[3];
 ptrdiff_t rgb_stride;
@@ -379,14 +388,21 @@ static void mul3x3(double dst[3][3], const double 
src1[3][3], const double src2[
  * See http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html
  * This function uses the Bradford mechanism.
  */
-static void fill_whitepoint_conv_table(double out[3][3],
+static void fill_whitepoint_conv_table(double out[3][3], enum 
WhitepointAdaptation wp_adapt,
enum Whitepoint src, enum Whitepoint 
dst)
 {
-static const double ma[3][3] = {
-{  0.8951,  0.2664, -0.1614 },
-{ -0.7502,  1.7135,  0.0367 },
-{  0.0389, -0.0685,  1.0296 },
+static const double ma_tbl[NB_WP_ADAPT_NON_IDENTITY][3][3] = {
+[WP_ADAPT_BRADFORD] = {
+{  0.8951,  0.2664, -0.1614 },
+{ -0.7502,  1.7135,  0.0367 },
+{  0.0389, -0.0685,  1.0296 },
+}, [WP_ADAPT_VON_KRIES] = {
+{  0.40024,  0.70760, -0.08081 },
+{ -0.22630,  1.16532,  0.04570 },
+{  0.0,  0.0,  0.91822 },
+},
 };
+const double (*ma)[3] = ma_tbl[wp_adapt];
 const struct WhitepointCoefficients *wp_src = 
_coefficients[src];
 double zw_src = 1.0 - wp_src->xw - wp_src->yw;
 const struct WhitepointCoefficients *wp_dst = 
_coefficients[dst];
@@ -631,10 +647,11 @@ static int create_filtergraph(AVFilterContext *ctx,
 fill_rgb2xyz_table(s->out_primaries, rgb2xyz);
 invert_matrix3x3(rgb2xyz, xyz2rgb);
 fill_rgb2xyz_table(s->in_primaries, rgb2xyz);
-if (s->out_primaries->wp != s->in_primaries->wp) {
+if (s->out_primaries->wp != s->in_primaries->wp &&
+s->wp_adapt != WP_ADAPT_IDENTITY) {
 double wpconv[3][3], tmp[3][3];
 
-fill_whitepoint_conv_table(wpconv, s->in_primaries->wp,
+fill_whitepoint_conv_table(wpconv, s->wp_adapt, 
s->in_primaries->wp,
s->out_primaries->wp);
 mul3x3(tmp, rgb2xyz, wpconv);
 mul3x3(rgb2rgb, tmp, xyz2rgb);
@@ -1098,12 +1115,20 @@ static const AVOption colorspace_options[] = {
 { "fast", "Ignore primary chromaticity and gamma correction",
   OFFSET(fast_mode), AV_OPT_TYPE_BOOL,  { .i64 = 0},
   0, 1, FLAGS },
+
 { "dither",   "Dithering mode",
   OFFSET(dither), AV_OPT_TYPE_INT, { .i64 = DITHER_NONE },
   DITHER_NONE, DITHER_NB - 1, FLAGS, "dither" },
 ENUM("none", DITHER_NONE, "dither"),
 ENUM("fsb",  DITHER_FSB,  "dither"),
 
+{ "wpadapt", "Whitepoint adaptation method",
+  OFFSET(wp_adapt), AV_OPT_TYPE_INT, { .i64 = WP_ADAPT_BRADFORD },
+  WP_ADAPT_BRADFORD, NB_WP_ADAPT - 1, FLAGS, "wpadapt" },
+ENUM("bradford", WP_ADAPT_BRADFORD, "wpadapt"),
+ENUM("vonkries", WP_ADAPT_VON_KRIES, "wpadapt"),
+ENUM("identity", WP_ADAPT_IDENTITY, "wpadapt"),
+
 { NULL }
 };
 
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add M101 decoder

[Michael Niedermayer]

On Thu, May 05, 2016 at 07:45:47PM +0200, Michael Niedermayer wrote:
> TODO: find out which LSB for 10bit go where
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/Makefile |1 +
>  libavcodec/allcodecs.c  |1 +
>  libavcodec/avcodec.h|1 +
>  libavcodec/codec_desc.c |7 +++
>  libavcodec/m101.c   |  120 
> +++
>  5 files changed, 130 insertions(+)
>  create mode 100644 libavcodec/m101.c

fixed various issues, bumped version
applied

[...]
-- 
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] ffmpeg: copy color properties in case of -c:v copy.

[Ronald S. Bultje]

Hi,

On Tue, May 3, 2016 at 10:21 PM, Michael Niedermayer  wrote:

> On Tue, May 03, 2016 at 08:58:07PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, May 3, 2016 at 8:29 PM, Michael Niedermayer
> 
> > wrote:
> >
> > > On Tue, May 03, 2016 at 03:21:00PM -0400, Ronald S. Bultje wrote:
> > > > I have no idea why the first hunk uses ost->enc_ctx, because as far
> as
> > > > I understand, that is never used in case of -c:v copy, but this code
> > > > block is only entered if encoding_needed=0, which means
> stream_copy=1.
> > >
> > > when the code was added it was followed by a
> > > ret = avcodec_copy_context(ost->st->codec, ost->enc_ctx);
> > > later that was removed
> > >
> > >
> > > do you have a testcase for which this hunk makes a differnce?
> >
> >
> > ffmpeg -i any_webm_file -color_trc 4 -strict -2 -c:v copy out.webm
> >
> > Will set the colorspace element in the muxer after, but not before, this
> > patch.
>
> patch should be ok
> can you add a testcase for this to fate ?
> so this doesnt break, nothing in fate tests this
> even commenting the code out entirely made fate still pass


Patch for that sent separately.

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

[FFmpeg-devel] [PATCH] fate: add matroska-remux test.

[Ronald S. Bultje]

This tests automatic insertion of the vp9_superframe BSF as well as
ensuring that the colorspace properties in the video header can be
modified when remuxing (-c:v copy).
---
 tests/Makefile  | 1 +
 tests/fate/matroska.mak | 9 +
 2 files changed, 10 insertions(+)
 create mode 100644 tests/fate/matroska.mak

diff --git a/tests/Makefile b/tests/Makefile
index 6fef0cd..5c5cfee 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -142,6 +142,7 @@ include $(SRC_PATH)/tests/fate/libavutil.mak
 include $(SRC_PATH)/tests/fate/libswresample.mak
 include $(SRC_PATH)/tests/fate/lossless-audio.mak
 include $(SRC_PATH)/tests/fate/lossless-video.mak
+include $(SRC_PATH)/tests/fate/matroska.mak
 include $(SRC_PATH)/tests/fate/microsoft.mak
 include $(SRC_PATH)/tests/fate/monkeysaudio.mak
 include $(SRC_PATH)/tests/fate/mp3.mak
diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
new file mode 100644
index 000..7c69d9f
--- /dev/null
+++ b/tests/fate/matroska.mak
@@ -0,0 +1,9 @@
+# This tests that the matroska demuxer supports modifying the colorspace
+# properties in remuxing (-c:v copy)
+# It also tests automatic insertion of the vp9_superframe bitstream filter
+FATE_MATROSKA-$(call DEMMUX, MATROSKA, MATROSKA) += fate-matroska-remux
+fate-matroska-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/vp9-test-vectors/vp90-2-2pass-akiyo.webm -color_trc 4 -c:v 
copy -fflags +bitexact -strict -2 -f matroska
+fate-matroska-remux: CMP = oneline
+fate-matroska-remux: REF = 2765be5eff4fde7332278a81a7d4e13c
+
+FATE_SAMPLES_AVCONV += $(FATE_MATROSKA-yes)
-- 
2.8.1

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

[FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.

[Ronald S. Bultje]

---
 doc/filters.texi |  13 
 libavfilter/colorspacedsp.c  |  13 
 libavfilter/colorspacedsp.h  |   6 ++
 libavfilter/colorspacedsp_template.c | 128 +++
 libavfilter/vf_colorspace.c  |  64 +-
 5 files changed, 221 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index b17b115..98a002b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5104,6 +5104,19 @@ YUV 4:4:4 planar 12-bits
 Do a fast conversion, which skips gamma/primary correction. This will take
 significantly less CPU, but will be mathematically incorrect. To get output
 compatible with that produced by the colormatrix filter, use fast=1.
+
+@item dither
+Specify dithering mode.
+
+The accepted values are:
+@table @samp
+@item none
+No dithering
+
+@item fsb
+Floyd-Steinberg dithering
+@end table
+
 @end table
 
 The filter converts the transfer characteristics, color space and color
diff --git a/libavfilter/colorspacedsp.c b/libavfilter/colorspacedsp.c
index d4c43c3..735e403 100644
--- a/libavfilter/colorspacedsp.c
+++ b/libavfilter/colorspacedsp.c
@@ -20,6 +20,10 @@
 
 #include "colorspacedsp.h"
 
+/*
+ * SS_W/H stands for "subsampling_w/h"
+ * it's analogous to AVPixFmtDescriptor->log2_chroma_w/h.
+ */
 #define SS_W 0
 #define SS_H 0
 
@@ -114,6 +118,15 @@ void ff_colorspacedsp_init(ColorSpaceDSPContext *dsp)
 init_rgb2yuv_fn(1, 10);
 init_rgb2yuv_fn(2, 12);
 
+#define init_rgb2yuv_fsb_fn(idx, bit) \
+dsp->rgb2yuv_fsb[idx][0] = rgb2yuv_fsb_444p##bit##_c; \
+dsp->rgb2yuv_fsb[idx][1] = rgb2yuv_fsb_422p##bit##_c; \
+dsp->rgb2yuv_fsb[idx][2] = rgb2yuv_fsb_420p##bit##_c
+
+init_rgb2yuv_fsb_fn(0,  8);
+init_rgb2yuv_fsb_fn(1, 10);
+init_rgb2yuv_fsb_fn(2, 12);
+
 #define init_yuv2yuv_fn(idx1, idx2, bit1, bit2) \
 dsp->yuv2yuv[idx1][idx2][0] = yuv2yuv_444p##bit1##to##bit2##_c; \
 dsp->yuv2yuv[idx1][idx2][1] = yuv2yuv_422p##bit1##to##bit2##_c; \
diff --git a/libavfilter/colorspacedsp.h b/libavfilter/colorspacedsp.h
index 4e70c6c..2ca7b19 100644
--- a/libavfilter/colorspacedsp.h
+++ b/libavfilter/colorspacedsp.h
@@ -32,6 +32,11 @@ typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t 
yuv_stride[3],
int16_t *rgb[3], ptrdiff_t rgb_stride,
int w, int h, const int16_t rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8]);
+typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+   int16_t *rgb[3], ptrdiff_t rgb_stride,
+   int w, int h, const int16_t 
rgb2yuv_coeffs[3][3][8],
+   const int16_t yuv_offset[8],
+   int *rnd[3][2]);
 typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3],
uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3],
int w, int h, const int16_t yuv2yuv_coeffs[3][3][8],
@@ -40,6 +45,7 @@ typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t 
yuv_out_stride[3],
 typedef struct ColorSpaceDSPContext {
 yuv2rgb_fn yuv2rgb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 444, 1: 
422, 2: 420 */];
 rgb2yuv_fn rgb2yuv[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 444, 1: 
422, 2: 420 */];
+rgb2yuv_fsb_fn rgb2yuv_fsb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 
444, 1: 422, 2: 420 */];
 yuv2yuv_fn yuv2yuv[3 /* in_depth */][3 /* out_depth */][3 /* 0: 444, 1: 
422, 2: 420 */];
 
 void (*multiply3x3)(int16_t *data[3], ptrdiff_t stride,
diff --git a/libavfilter/colorspacedsp_template.c 
b/libavfilter/colorspacedsp_template.c
index f225391..db4a8d2 100644
--- a/libavfilter/colorspacedsp_template.c
+++ b/libavfilter/colorspacedsp_template.c
@@ -199,6 +199,134 @@ static void fn(rgb2yuv)(uint8_t *_yuv[3], ptrdiff_t 
yuv_stride[3],
 }
 }
 
+/* floyd-steinberg dithering - for any mid-top pixel A in a 3x2 block of 
pixels:
+ *1 A 2
+ *3 4 5
+ * the rounding error is distributed over the neighbouring pixels:
+ *2: 7/16th, 3: 3/16th, 4: 5/16th and 5: 1/16th
+ */
+static void fn(rgb2yuv_fsb)(uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+int16_t *rgb[3], ptrdiff_t s,
+int w, int h, const int16_t 
rgb2yuv_coeffs[3][3][8],
+const int16_t yuv_offset[8],
+int *rnd_scratch[3][2])
+{
+pixel **yuv = (pixel **) _yuv;
+pixel *yuv0 = yuv[0], *yuv1 = yuv[1], *yuv2 = yuv[2];
+const int16_t *rgb0 = rgb[0], *rgb1 = rgb[1], *rgb2 = rgb[2];
+int y, x;
+const int sh = 29 - BIT_DEPTH;
+const int rnd = 1 << (sh - 1);
+int cry = rgb2yuv_coeffs[0][0][0];
+int cgy = rgb2yuv_coeffs[0][1][0];
+int cby = rgb2yuv_coeffs[0][2][0];
+int cru = rgb2yuv_coeffs[1][0][0];
+int cgu = rgb2yuv_coeffs[1][1][0];
+int cburv = rgb2yuv_coeffs[1][2][0];
+

Re: [FFmpeg-devel] [PATCH] vf_colorspace: add floyd-steinberg dithering option to full conversion.

[Ronald S. Bultje]

Hi,

On Thu, May 5, 2016 at 8:16 AM, Michael Niedermayer 
wrote:

> On Tue, May 03, 2016 at 01:53:42PM -0400, Ronald S. Bultje wrote:
> > ---
> >  doc/filters.texi |  13 
> >  libavfilter/colorspacedsp.c  |  12 
> >  libavfilter/colorspacedsp.h  |   6 ++
> >  libavfilter/colorspacedsp_template.c | 128
> +++
> >  libavfilter/vf_colorspace.c  |  58 +++-
> >  5 files changed, 214 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index b17b115..98a002b 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -5104,6 +5104,19 @@ YUV 4:4:4 planar 12-bits
> >  Do a fast conversion, which skips gamma/primary correction. This will
> take
> >  significantly less CPU, but will be mathematically incorrect. To get
> output
> >  compatible with that produced by the colormatrix filter, use fast=1.
> > +
> > +@item dither
> > +Specify dithering mode.
> > +
> > +The accepted values are:
> > +@table @samp
> > +@item none
> > +No dithering
> > +
> > +@item fsb
> > +Floyd-Steinberg dithering
> > +@end table
> > +
> >  @end table
> >
> >  The filter converts the transfer characteristics, color space and color
> > diff --git a/libavfilter/colorspacedsp.c b/libavfilter/colorspacedsp.c
> > index d4c43c3..f95805b 100644
> > --- a/libavfilter/colorspacedsp.c
> > +++ b/libavfilter/colorspacedsp.c
> > @@ -20,6 +20,9 @@
> >
> >  #include "colorspacedsp.h"
> >
>
> > +/*
> > + * SS_W/H are synonyms for AVPixFmtDescriptor->log2_chroma_w/h.
>
> doesnt explain what SS stands for, that makes this harder to remember
>

Fixed.

> @@ -114,6 +117,15 @@ void ff_colorspacedsp_init(ColorSpaceDSPContext *dsp)
> >  init_rgb2yuv_fn(1, 10);
> >  init_rgb2yuv_fn(2, 12);
> >
> > +#define init_rgb2yuv_fsb_fn(idx, bit) \
> > +dsp->rgb2yuv_fsb[idx][0] = rgb2yuv_fsb_444p##bit##_c; \
> > +dsp->rgb2yuv_fsb[idx][1] = rgb2yuv_fsb_422p##bit##_c; \
> > +dsp->rgb2yuv_fsb[idx][2] = rgb2yuv_fsb_420p##bit##_c
> > +
> > +init_rgb2yuv_fsb_fn(0,  8);
> > +init_rgb2yuv_fsb_fn(1, 10);
> > +init_rgb2yuv_fsb_fn(2, 12);
>
> is there a plan for bit depth other than these and subsamplings the
> than these ?
>

For bit depth: I currently don't need more, but I see no reason why we
wouldn't eventually want to support up to 14 here (which is the hevc/h264
upper limit, right?).

for chroma subsamplings: not sure. My feeling is that this should address
most real-world needs, but this is obviously hard to say. I think if we
want more, we should simply fix the indexing into this array in
vf_colorspace.c from being hardcoded into working only for 444/422/420 into
becoming a real AV_PIX_FMT_* <-> internal-enum mapping.

0,1,2 is bad, these should be named constants/enums for the subsamplings
> or maybe a 2d array
>

Enum done, but in separate patch.

> diff --git a/libavfilter/colorspacedsp.h b/libavfilter/colorspacedsp.h
> > index 4e70c6c..2ca7b19 100644
> > --- a/libavfilter/colorspacedsp.h
> > +++ b/libavfilter/colorspacedsp.h
> > @@ -32,6 +32,11 @@ typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t
> yuv_stride[3],
> > int16_t *rgb[3], ptrdiff_t rgb_stride,
> > int w, int h, const int16_t
> rgb2yuv_coeffs[3][3][8],
> > const int16_t yuv_offset[8]);
>
> > +typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
> > +   int16_t *rgb[3], ptrdiff_t rgb_stride,
> > +   int w, int h, const int16_t
> rgb2yuv_coeffs[3][3][8],
> > +   const int16_t yuv_offset[8],
> > +   int *rnd[3][2]);
>
> lacks documentation
> the strides also can be const as well as rgb
>
>
> >  typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t
> yuv_out_stride[3],
> > uint8_t *yuv_in[3], ptrdiff_t
> yuv_in_stride[3],
>
> off topic but, same here


Both done, as a separate patch also.

> int w, int h, const int16_t
> yuv2yuv_coeffs[3][3][8],
> > @@ -40,6 +45,7 @@ typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3],
> ptrdiff_t yuv_out_stride[3],
> >  typedef struct ColorSpaceDSPContext {
> >  yuv2rgb_fn yuv2rgb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0:
> 444, 1: 422, 2: 420 */];
> >  rgb2yuv_fn rgb2yuv[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0:
> 444, 1: 422, 2: 420 */];
> > +rgb2yuv_fsb_fn rgb2yuv_fsb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3
> /* 0: 444, 1: 422, 2: 420 */];
> >  yuv2yuv_fn yuv2yuv[3 /* in_depth */][3 /* out_depth */][3 /* 0:
> 444, 1: 422, 2: 420 */];
> >
> >  void (*multiply3x3)(int16_t *data[3], ptrdiff_t stride,
> > diff --git a/libavfilter/colorspacedsp_template.c
> b/libavfilter/colorspacedsp_template.c
> > index f225391..db4a8d2 100644
> > --- a/libavfilter/colorspacedsp_template.c
> > +++ 

[FFmpeg-devel] [PATCH 2/3] vf_colorspace: add const to yuv_stride[] argument in DSP functions.

[Ronald S. Bultje]

---
 libavfilter/colorspacedsp.h  | 10 +-
 libavfilter/colorspacedsp_template.c |  6 +++---
 libavfilter/colorspacedsp_yuv2yuv_template.c |  4 ++--
 libavfilter/x86/colorspacedsp_init.c |  8 
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/libavfilter/colorspacedsp.h b/libavfilter/colorspacedsp.h
index 2ca7b19..7a64f9d 100644
--- a/libavfilter/colorspacedsp.h
+++ b/libavfilter/colorspacedsp.h
@@ -25,20 +25,20 @@
 #include 
 
 typedef void (*yuv2rgb_fn)(int16_t *rgb[3], ptrdiff_t rgb_stride,
-   uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+   uint8_t *yuv[3], const ptrdiff_t yuv_stride[3],
int w, int h, const int16_t yuv2rgb_coeffs[3][3][8],
const int16_t yuv_offset[8]);
-typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], const ptrdiff_t yuv_stride[3],
int16_t *rgb[3], ptrdiff_t rgb_stride,
int w, int h, const int16_t rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8]);
-typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], const ptrdiff_t yuv_stride[3],
int16_t *rgb[3], ptrdiff_t rgb_stride,
int w, int h, const int16_t 
rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8],
int *rnd[3][2]);
-typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3],
-   uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3],
+typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], const ptrdiff_t 
yuv_out_stride[3],
+   uint8_t *yuv_in[3], const ptrdiff_t 
yuv_in_stride[3],
int w, int h, const int16_t yuv2yuv_coeffs[3][3][8],
const int16_t yuv_offset[2][8]);
 
diff --git a/libavfilter/colorspacedsp_template.c 
b/libavfilter/colorspacedsp_template.c
index db4a8d2..53ac0d7 100644
--- a/libavfilter/colorspacedsp_template.c
+++ b/libavfilter/colorspacedsp_template.c
@@ -52,7 +52,7 @@
 #endif
 
 static void fn(yuv2rgb)(int16_t *rgb[3], ptrdiff_t rgb_stride,
-uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+uint8_t *_yuv[3], const ptrdiff_t yuv_stride[3],
 int w, int h, const int16_t yuv2rgb_coeffs[3][3][8],
 const int16_t yuv_offset[8])
 {
@@ -127,7 +127,7 @@ static void fn(yuv2rgb)(int16_t *rgb[3], ptrdiff_t 
rgb_stride,
 }
 }
 
-static void fn(rgb2yuv)(uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+static void fn(rgb2yuv)(uint8_t *_yuv[3], const ptrdiff_t yuv_stride[3],
 int16_t *rgb[3], ptrdiff_t s,
 int w, int h, const int16_t rgb2yuv_coeffs[3][3][8],
 const int16_t yuv_offset[8])
@@ -205,7 +205,7 @@ static void fn(rgb2yuv)(uint8_t *_yuv[3], ptrdiff_t 
yuv_stride[3],
  * the rounding error is distributed over the neighbouring pixels:
  *2: 7/16th, 3: 3/16th, 4: 5/16th and 5: 1/16th
  */
-static void fn(rgb2yuv_fsb)(uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+static void fn(rgb2yuv_fsb)(uint8_t *_yuv[3], const ptrdiff_t yuv_stride[3],
 int16_t *rgb[3], ptrdiff_t s,
 int w, int h, const int16_t 
rgb2yuv_coeffs[3][3][8],
 const int16_t yuv_offset[8],
diff --git a/libavfilter/colorspacedsp_yuv2yuv_template.c 
b/libavfilter/colorspacedsp_yuv2yuv_template.c
index 8b0d33a..3fae38c 100644
--- a/libavfilter/colorspacedsp_yuv2yuv_template.c
+++ b/libavfilter/colorspacedsp_yuv2yuv_template.c
@@ -37,8 +37,8 @@
 #define fn2(a,b,c,d) fn3(a,b,c,d)
 #define fn(a) fn2(a, IN_BIT_DEPTH, OUT_BIT_DEPTH, ss)
 
-static void fn(yuv2yuv)(uint8_t *_dst[3], ptrdiff_t dst_stride[3],
-uint8_t *_src[3], ptrdiff_t src_stride[3],
+static void fn(yuv2yuv)(uint8_t *_dst[3], const ptrdiff_t dst_stride[3],
+uint8_t *_src[3], const ptrdiff_t src_stride[3],
 int w, int h, const int16_t c[3][3][8],
 const int16_t yuv_offset[2][8])
 {
diff --git a/libavfilter/x86/colorspacedsp_init.c 
b/libavfilter/x86/colorspacedsp_init.c
index 78d34bc..5515ab8 100644
--- a/libavfilter/x86/colorspacedsp_init.c
+++ b/libavfilter/x86/colorspacedsp_init.c
@@ -23,8 +23,8 @@
 #include "libavfilter/colorspacedsp.h"
 
 #define decl_yuv2yuv_fn(t) \
-void ff_yuv2yuv_##t##_sse2(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3], \
-   uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3], \
+void ff_yuv2yuv_##t##_sse2(uint8_t *yuv_out[3], const ptrdiff_t 
yuv_out_stride[3], \
+   uint8_t *yuv_in[3], 

Re: [FFmpeg-devel] [PATCH 57/57] support for matrox m703 mpeg-2

[Michael Niedermayer]

On Fri, May 06, 2016 at 11:26:04AM +0200, Piotr Bandurski wrote:
> > file attached but i think there is something wrong with the encoder
> > used, the files do not seem to contain enough non zero bits to
> > be able to contain full yuv422 10bit
> > so i am not sure this will resolve this
> 
> ok, encoded it to m101 10bit:
> 
> https://www.datafilehost.com/d/119d82c3

thanks, this helped alot should be fixed
the encoder though or something between decoder or encoder isnt
just encoding this data but smearing and messing it up

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] Bonk decoder and demuxer

[Piotr Bandurski]

> > > On 5/5/16, Piotr Bandurski  wrote:
> > >> > > > > > > > > Improved version attached.
> > >> > > >
> > >> > > > I found another bug, this time in lossy mode - the file encoded as
> > >> > > > "joint stereo" decodes after a few seconds into noise:
> > >> > > >
> > >> > > > https://www.datafilehost.com/d/c2e8b332
> > >> > >
> > >> > > here are a few more samples:
> > >> > >
> > >> > > https://www.datafilehost.com/d/e4825eb4
> > >> > >
> > >> > > quantization: 1.15
> > >> > > downsampling ratio: 1:1/2:1/3:1/10:1
> > >> > > predictor size: 282
> > >> > > enable join stereo
> > >> > >
> > >> > >
> > >> > > in file "down_2_1.bonk" noise stars around 2:30
> > >> >
> > >> > hmm it has actually not much to do with "join stereo" option, because
> > >> > the same problem happens with mono files:
> > >> >
> > >> > https://www.datafilehost.com/d/09128a25
> > >>
> > >> these mono files hangs with ffmpeg's bonk decoder:
> > >>
> > >> https://www.datafilehost.com/d/b94fd994
> > >
> > > there is actually no hang, I used wrong binary for the test (with applied 
> > > v1
> > > version of your patch, so it's fixed)
> > 
> > I fixed hangs/crashes but cant locate noise bug anywhere.
> 
> It must be a bug in fre:ac implementation - I located another bug with 
> lossless 6khz file with predictor set to 512
> fre:ac file decodes into noise with bonk and ffmpeg.
> 
> I created similar sample with bonk (-l -s 512) and it decodes correctly with 
> ffmpeg.
> 
> There is also some unrelated thing - bonk encoder doesn't like wav files 
> generated by ffmpeg, but I don't know if this
> is a bug in ffmpeg or bonk.
> 
> so summarizing - LGTM from me for your decoder.

I was able to isolate this and it looks like it's really a bug in encoder (see 
"bonkdec_bug_qualization_1_15_down_10_1_pred_282.wav")
just original decoder is able to better handle this

https://www.datafilehost.com/d/8ca9e3c1

qualization 1.15
downsampling 10:1
predictor ...

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

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

[Christophe Gisquet]

Hi,

2016-05-06 2:19 GMT+02:00 Rostislav Pehlivanov :
> I plan to merge the fate tests as well tomorrow or on Saturday when I'll
> have time to quickly fix bugs which appear on platforms I haven't tested
> the encoder on. Hopefully none, but you never know.

Sure, makes sense.

In case you don't find time nor devices for those tests, Michael seems
to have tested on a fair number of archs:
"tested on mips/arm/x86 linux and mingw32/64"

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

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

[Hendrik Leppkes]

On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu  wrote:
> On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:
>>
>> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
>> > On 1/30/2016 7:15 PM, Timothy Gu wrote:
>> > > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.
>> >
>> > Perhaps this should be restricted to x86?
>>
>> Fair enough.
>
>
> Pushed.
>

Just to document it, this has caused build breakage in various
scenarios, even in GCC 5.3 (6.1 not tested).

The latest reported on IRC just today here:
libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
libavcodec/sbrdsp.c:47:13: internal compiler error: in
vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
 static void sbr_neg_odd_64_c(float *x)

There are various other cases which usually involve inline asm when
building with SIMD (ie. --cpu=host) and the optimizer running out of
registers, for example:
libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints

IMHO this feature is not quite ready to be enabled unconditionally in
our code base, and we should re-evaluate this change.

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

Re: [FFmpeg-devel] [PATCH] set exact ref frame in AVMotionVector

[Derek Buitenhuis]

On 5/6/2016 10:54 AM, Davinder Singh wrote:
> change the confusing "source" var to "ref" of AVMotionVector.

This would be a backwards incompatible API break, no?

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

[FFmpeg-devel] [PATCH] set exact ref frame in AVMotionVector

[Davinder Singh]

hi,
change the confusing "source" var to "ref" of AVMotionVector.
define two constants AV_MV_REF_FRAME_PREVIOUS and AV_MV_REF_FRAME_NEXT
all changes:
https://github.com/dsmudhar/FFmpeg/commit/33b5ad805cccd7b48a6b0d643c39e8dd26f0e98b

please confirm this:
snowdec.c
Line 96: BlockNode *bn...
...
Line 112: avmv->source = -1 - bn->ref;
i searched the code, bn->ref set was >= 0
so, i set it always prev:
avmv->ref = AV_MV_REF_FRAME_PREVIOUS;
since, in current code, "source" is checked if > 0 to be future ref, and
line 112 set it always negative.

Regards,
DSM_


0001-set-exact-ref-frame-in-AVMotionVector.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 57/57] support for matrox m703 mpeg-2

[Piotr Bandurski]

> file attached but i think there is something wrong with the encoder
> used, the files do not seem to contain enough non zero bits to
> be able to contain full yuv422 10bit
> so i am not sure this will resolve this

ok, encoded it to m101 10bit:

https://www.datafilehost.com/d/119d82c3

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

[FFmpeg-devel] [PATCH 2/2] dshow: Make dshow device buildable on Cygwin

[Moriyoshi Koizumi]

From: Moriyoshi koizumi 

wchar_t is not always the same thing as WCHAR.

Signed-off-by: Moriyoshi koizumi 
---
 libavdevice/dshow.c |  6 +++---
 libavdevice/dshow_capture.h | 10 +-
 libavdevice/dshow_filter.c  | 16 
 libavdevice/dshow_pin.c | 10 +-
 4 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 678861d..432b643 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -129,7 +129,7 @@ dshow_read_close(AVFormatContext *s)
 return 0;
 }
 
-static char *dup_wchar_to_utf8(wchar_t *w)
+static char *dup_wchar_to_utf8(WCHAR *w)
 {
 char *s = NULL;
 int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
@@ -599,7 +599,7 @@ dshow_cycle_pins(AVFormatContext *avctx, enum 
dshowDeviceType devtype,
 GUID category;
 DWORD r2;
 char *name_buf = NULL;
-wchar_t *pin_id = NULL;
+WCHAR *pin_id = NULL;
 char *pin_buf = NULL;
 char *desired_pin_name = devtype == VideoDevice ? ctx->video_pin_name 
: ctx->audio_pin_name;
 
@@ -734,7 +734,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum 
*devenum,
 IStream *ofile_stream = NULL;
 IPersistStream *pers_stream = NULL;
 
-const wchar_t *filter_name[2] = { L"Audio capture filter", L"Video capture 
filter" };
+const WCHAR *filter_name[2] = { L"Audio capture filter", L"Video capture 
filter" };
 
 
 if ( ((ctx->audio_filter_load_file) && 
(strlen(ctx->audio_filter_load_file)>0) && (sourcetype == AudioSourceDevice)) ||
diff --git a/libavdevice/dshow_capture.h b/libavdevice/dshow_capture.h
index f26eaf9..860b782 100644
--- a/libavdevice/dshow_capture.h
+++ b/libavdevice/dshow_capture.h
@@ -176,7 +176,7 @@ long  WINAPI libAVPin_ConnectedTo 
(libAVPin *, IPin **);
 long  WINAPI libAVPin_ConnectionMediaType (libAVPin *, 
AM_MEDIA_TYPE *);
 long  WINAPI libAVPin_QueryPinInfo(libAVPin *, PIN_INFO *);
 long  WINAPI libAVPin_QueryDirection  (libAVPin *, 
PIN_DIRECTION *);
-long  WINAPI libAVPin_QueryId (libAVPin *, wchar_t **);
+long  WINAPI libAVPin_QueryId (libAVPin *, WCHAR **);
 long  WINAPI libAVPin_QueryAccept (libAVPin *, const 
AM_MEDIA_TYPE *);
 long  WINAPI libAVPin_EnumMediaTypes  (libAVPin *, 
IEnumMediaTypes **);
 long  WINAPI libAVPin_QueryInternalConnections(libAVPin *, IPin **, 
unsigned long *);
@@ -249,7 +249,7 @@ libAVEnumMediaTypes *libAVEnumMediaTypes_Create(const 
AM_MEDIA_TYPE *type);
 struct libAVFilter {
 IBaseFilterVtbl *vtbl;
 long ref;
-const wchar_t *name;
+const WCHAR *name;
 libAVPin *pin;
 FILTER_INFO info;
 FILTER_STATE state;
@@ -272,10 +272,10 @@ long  WINAPI libAVFilter_GetState   
(libAVFilter *, DWORD, FILTER_ST
 long  WINAPI libAVFilter_SetSyncSource  (libAVFilter *, 
IReferenceClock *);
 long  WINAPI libAVFilter_GetSyncSource  (libAVFilter *, 
IReferenceClock **);
 long  WINAPI libAVFilter_EnumPins   (libAVFilter *, IEnumPins **);
-long  WINAPI libAVFilter_FindPin(libAVFilter *, const wchar_t 
*, IPin **);
+long  WINAPI libAVFilter_FindPin(libAVFilter *, const WCHAR *, 
IPin **);
 long  WINAPI libAVFilter_QueryFilterInfo(libAVFilter *, FILTER_INFO *);
-long  WINAPI libAVFilter_JoinFilterGraph(libAVFilter *, IFilterGraph 
*, const wchar_t *);
-long  WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, wchar_t **);
+long  WINAPI libAVFilter_JoinFilterGraph(libAVFilter *, IFilterGraph 
*, const WCHAR *);
+long  WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, WCHAR **);
 
 void libAVFilter_Destroy(libAVFilter *);
 libAVFilter *libAVFilter_Create (void *, void *, enum dshowDeviceType);
diff --git a/libavdevice/dshow_filter.c b/libavdevice/dshow_filter.c
index 7360adc..3ba3871 100644
--- a/libavdevice/dshow_filter.c
+++ b/libavdevice/dshow_filter.c
@@ -20,6 +20,8 @@
  */
 
 #include "dshow_capture.h"
+#include 
+#include 
 
 DECLARE_QUERYINTERFACE(libAVFilter,
 { {_IUnknown,0}, {_IBaseFilter,0} })
@@ -108,14 +110,14 @@ libAVFilter_EnumPins(libAVFilter *this, IEnumPins 
**enumpin)
 return S_OK;
 }
 long WINAPI
-libAVFilter_FindPin(libAVFilter *this, const wchar_t *id, IPin **pin)
+libAVFilter_FindPin(libAVFilter *this, const WCHAR *id, IPin **pin)
 {
 libAVPin *found = NULL;
 dshowdebug("libAVFilter_FindPin(%p)\n", this);
 
 if (!id || !pin)
 return E_POINTER;
-if (!wcscmp(id, L"In")) {
+if (!StrCmpW(id, L"In")) {
 found = this->pin;
 libAVPin_AddRef(found);
 }
@@ -140,26 +142,24 @@ libAVFilter_QueryFilterInfo(libAVFilter *this, 
FILTER_INFO *info)
 }
 long WINAPI
 libAVFilter_JoinFilterGraph(libAVFilter *this, IFilterGraph *graph,
-  

[FFmpeg-devel] [PATCH 2/2] dshow: Make dshow device buildable on Cygwin

[Moriyoshi Koizumi]

From: Moriyoshi koizumi 

wchar_t is not always the same thing as WCHAR.

Signed-off-by: Moriyoshi koizumi 
---
 libavdevice/dshow.c |  6 +++---
 libavdevice/dshow_capture.h | 10 +-
 libavdevice/dshow_filter.c  | 16 
 libavdevice/dshow_pin.c | 10 +-
 4 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 678861d..432b643 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -129,7 +129,7 @@ dshow_read_close(AVFormatContext *s)
 return 0;
 }
 
-static char *dup_wchar_to_utf8(wchar_t *w)
+static char *dup_wchar_to_utf8(WCHAR *w)
 {
 char *s = NULL;
 int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
@@ -599,7 +599,7 @@ dshow_cycle_pins(AVFormatContext *avctx, enum 
dshowDeviceType devtype,
 GUID category;
 DWORD r2;
 char *name_buf = NULL;
-wchar_t *pin_id = NULL;
+WCHAR *pin_id = NULL;
 char *pin_buf = NULL;
 char *desired_pin_name = devtype == VideoDevice ? ctx->video_pin_name 
: ctx->audio_pin_name;
 
@@ -734,7 +734,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum 
*devenum,
 IStream *ofile_stream = NULL;
 IPersistStream *pers_stream = NULL;
 
-const wchar_t *filter_name[2] = { L"Audio capture filter", L"Video capture 
filter" };
+const WCHAR *filter_name[2] = { L"Audio capture filter", L"Video capture 
filter" };
 
 
 if ( ((ctx->audio_filter_load_file) && 
(strlen(ctx->audio_filter_load_file)>0) && (sourcetype == AudioSourceDevice)) ||
diff --git a/libavdevice/dshow_capture.h b/libavdevice/dshow_capture.h
index f26eaf9..860b782 100644
--- a/libavdevice/dshow_capture.h
+++ b/libavdevice/dshow_capture.h
@@ -176,7 +176,7 @@ long  WINAPI libAVPin_ConnectedTo 
(libAVPin *, IPin **);
 long  WINAPI libAVPin_ConnectionMediaType (libAVPin *, 
AM_MEDIA_TYPE *);
 long  WINAPI libAVPin_QueryPinInfo(libAVPin *, PIN_INFO *);
 long  WINAPI libAVPin_QueryDirection  (libAVPin *, 
PIN_DIRECTION *);
-long  WINAPI libAVPin_QueryId (libAVPin *, wchar_t **);
+long  WINAPI libAVPin_QueryId (libAVPin *, WCHAR **);
 long  WINAPI libAVPin_QueryAccept (libAVPin *, const 
AM_MEDIA_TYPE *);
 long  WINAPI libAVPin_EnumMediaTypes  (libAVPin *, 
IEnumMediaTypes **);
 long  WINAPI libAVPin_QueryInternalConnections(libAVPin *, IPin **, 
unsigned long *);
@@ -249,7 +249,7 @@ libAVEnumMediaTypes *libAVEnumMediaTypes_Create(const 
AM_MEDIA_TYPE *type);
 struct libAVFilter {
 IBaseFilterVtbl *vtbl;
 long ref;
-const wchar_t *name;
+const WCHAR *name;
 libAVPin *pin;
 FILTER_INFO info;
 FILTER_STATE state;
@@ -272,10 +272,10 @@ long  WINAPI libAVFilter_GetState   
(libAVFilter *, DWORD, FILTER_ST
 long  WINAPI libAVFilter_SetSyncSource  (libAVFilter *, 
IReferenceClock *);
 long  WINAPI libAVFilter_GetSyncSource  (libAVFilter *, 
IReferenceClock **);
 long  WINAPI libAVFilter_EnumPins   (libAVFilter *, IEnumPins **);
-long  WINAPI libAVFilter_FindPin(libAVFilter *, const wchar_t 
*, IPin **);
+long  WINAPI libAVFilter_FindPin(libAVFilter *, const WCHAR *, 
IPin **);
 long  WINAPI libAVFilter_QueryFilterInfo(libAVFilter *, FILTER_INFO *);
-long  WINAPI libAVFilter_JoinFilterGraph(libAVFilter *, IFilterGraph 
*, const wchar_t *);
-long  WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, wchar_t **);
+long  WINAPI libAVFilter_JoinFilterGraph(libAVFilter *, IFilterGraph 
*, const WCHAR *);
+long  WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, WCHAR **);
 
 void libAVFilter_Destroy(libAVFilter *);
 libAVFilter *libAVFilter_Create (void *, void *, enum dshowDeviceType);
diff --git a/libavdevice/dshow_filter.c b/libavdevice/dshow_filter.c
index 7360adc..3ba3871 100644
--- a/libavdevice/dshow_filter.c
+++ b/libavdevice/dshow_filter.c
@@ -20,6 +20,8 @@
  */
 
 #include "dshow_capture.h"
+#include 
+#include 
 
 DECLARE_QUERYINTERFACE(libAVFilter,
 { {_IUnknown,0}, {_IBaseFilter,0} })
@@ -108,14 +110,14 @@ libAVFilter_EnumPins(libAVFilter *this, IEnumPins 
**enumpin)
 return S_OK;
 }
 long WINAPI
-libAVFilter_FindPin(libAVFilter *this, const wchar_t *id, IPin **pin)
+libAVFilter_FindPin(libAVFilter *this, const WCHAR *id, IPin **pin)
 {
 libAVPin *found = NULL;
 dshowdebug("libAVFilter_FindPin(%p)\n", this);
 
 if (!id || !pin)
 return E_POINTER;
-if (!wcscmp(id, L"In")) {
+if (!StrCmpW(id, L"In")) {
 found = this->pin;
 libAVPin_AddRef(found);
 }
@@ -140,26 +142,24 @@ libAVFilter_QueryFilterInfo(libAVFilter *this, 
FILTER_INFO *info)
 }
 long WINAPI
 libAVFilter_JoinFilterGraph(libAVFilter *this, IFilterGraph *graph,
-  

[FFmpeg-devel] [PATCH 1/2] dshow: Add missing library dependency (dxguid)

[Moriyoshi Koizumi]

From: Moriyoshi koizumi 

Signed-off-by: Moriyoshi koizumi 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 1f684d2..fb8d7d3 100755
--- a/configure
+++ b/configure
@@ -2832,7 +2832,7 @@ decklink_indev_extralibs="-lstdc++"
 decklink_outdev_deps="decklink pthreads"
 decklink_outdev_extralibs="-lstdc++"
 dshow_indev_deps="IBaseFilter"
-dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi"
+dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi 
-ldxguid"
 dv1394_indev_deps="dv1394"
 dv1394_indev_select="dv_demuxer"
 fbdev_indev_deps="linux_fb_h"
-- 
2.8.0

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