[FFmpeg-devel] [PATCH v4] Fix mistake with repeating values in first and second channels

[Ludmila Glinskih]

Signed-off-by: Ludmila Glinskih 
---
 libavcodec/api-flac-test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/api-flac-test.c b/libavcodec/api-flac-test.c
index b036385..38b2613 100644
--- a/libavcodec/api-flac-test.c
+++ b/libavcodec/api-flac-test.c
@@ -44,7 +44,7 @@ static int generate_raw_frame(uint16_t *frame_data, int i, 
int sample_rate,
 {
 frame_data[channels * j] = 1 * ((j / 10 * i) % 2);
 for (k = 1; k < channels; k++)
-frame_data[channels * j + k] = frame_data[channels * j] * k;
+frame_data[channels * j + k] = frame_data[channels * j] * (k + 1);
 }
 return 0;
 }
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v4] Fix mistake with repeating values in first and second channels

[Ludmila Glinskih]

Signed-off-by: Ludmila Glinskih 
---
 libavcodec/api-flac-test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/api-flac-test.c b/libavcodec/api-flac-test.c
index b036385..38b2613 100644
--- a/libavcodec/api-flac-test.c
+++ b/libavcodec/api-flac-test.c
@@ -44,7 +44,7 @@ static int generate_raw_frame(uint16_t *frame_data, int i, 
int sample_rate,
 {
 frame_data[channels * j] = 1 * ((j / 10 * i) % 2);
 for (k = 1; k < channels; k++)
-frame_data[channels * j + k] = frame_data[channels * j] * k;
+frame_data[channels * j + k] = frame_data[channels * j] * (k + 1);
 }
 return 0;
 }
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v4] Fix mistake with repeating values in first and second channels

[Ludmila Glinskih]

Signed-off-by: Ludmila Glinskih 
---
 libavcodec/api-flac-test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/api-flac-test.c b/libavcodec/api-flac-test.c
index b036385..38b2613 100644
--- a/libavcodec/api-flac-test.c
+++ b/libavcodec/api-flac-test.c
@@ -44,7 +44,7 @@ static int generate_raw_frame(uint16_t *frame_data, int i, 
int sample_rate,
 {
 frame_data[channels * j] = 1 * ((j / 10 * i) % 2);
 for (k = 1; k < channels; k++)
-frame_data[channels * j + k] = frame_data[channels * j] * k;
+frame_data[channels * j + k] = frame_data[channels * j] * (k + 1);
 }
 return 0;
 }
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH v4] Fix mistake with repeating values in first and second channels

[Ludmila Glinskih]

Oooops, this was meant to be in the last thread
=)

On Mon, Apr 20, 2015 at 10:34 AM, Ludmila Glinskih  wrote:
> Signed-off-by: Ludmila Glinskih 
> ---
>  libavcodec/api-flac-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/api-flac-test.c b/libavcodec/api-flac-test.c
> index b036385..38b2613 100644
> --- a/libavcodec/api-flac-test.c
> +++ b/libavcodec/api-flac-test.c
> @@ -44,7 +44,7 @@ static int generate_raw_frame(uint16_t *frame_data, int i, 
> int sample_rate,
>  {
>  frame_data[channels * j] = 1 * ((j / 10 * i) % 2);
>  for (k = 1; k < channels; k++)
> -frame_data[channels * j + k] = frame_data[channels * j] * k;
> +frame_data[channels * j + k] = frame_data[channels * j] * (k + 
> 1);
>  }
>  return 0;
>  }
> --
> 1.9.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4] Fix mistake with repeating values in first and second channels

[Ludmila Glinskih]

Ooops, wrong threat. I need one more try)

On Mon, Apr 20, 2015 at 10:36 AM, Ludmila Glinskih  wrote:
> Signed-off-by: Ludmila Glinskih 
> ---
>  libavcodec/api-flac-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/api-flac-test.c b/libavcodec/api-flac-test.c
> index b036385..38b2613 100644
> --- a/libavcodec/api-flac-test.c
> +++ b/libavcodec/api-flac-test.c
> @@ -44,7 +44,7 @@ static int generate_raw_frame(uint16_t *frame_data, int i, 
> int sample_rate,
>  {
>  frame_data[channels * j] = 1 * ((j / 10 * i) % 2);
>  for (k = 1; k < channels; k++)
> -frame_data[channels * j + k] = frame_data[channels * j] * k;
> +frame_data[channels * j + k] = frame_data[channels * j] * (k + 
> 1);
>  }
>  return 0;
>  }
> --
> 1.9.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/mips/generic_macros_msa: volatile doesnt need __

[Nedeljko Babic]

LGTM

Thanks,
Nedeljko

Od: ffmpeg-devel-boun...@ffmpeg.org [ffmpeg-devel-boun...@ffmpeg.org] u ime 
korisnika Michael Niedermayer [michae...@gmx.at]
Poslato: 18. april 2015 12:22
Za: FFmpeg development discussions and patches
Tema: [FFmpeg-devel] [PATCH] avutil/mips/generic_macros_msa: volatile   doesnt 
need __

Signed-off-by: Michael Niedermayer 
---
 libavutil/mips/generic_macros_msa.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/mips/generic_macros_msa.h 
b/libavutil/mips/generic_macros_msa.h
index d2fd87c..374382f 100644
--- a/libavutil/mips/generic_macros_msa.h
+++ b/libavutil/mips/generic_macros_msa.h
@@ -56,7 +56,7 @@
 uint8_t *dst_ptr_m = (uint8_t *) (pdst);  \
 uint64_t val_m = (val);   \
   \
-__asm__ __volatile__ (\
+__asm__ volatile (\
 "sd  %[val_m],  %[dst_ptr_m]  \n\t"   \
   \
 : [dst_ptr_m] "=m" (*dst_ptr_m)   \
@@ -73,7 +73,7 @@
 val0_m = (uint32_t) ((val) & 0x);  \
 val1_m = (uint32_t) (((val) >> 32) & 0x);  \
\
-__asm__ __volatile__ ( \
+__asm__ volatile ( \
 "usw  %[val0_m],  %[dst1_m]  \n\t" \
 "usw  %[val1_m],  %[dst2_m]  \n\t" \
\
--
1.7.9.5

___
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 v4] libavcodec: Add FLAC API test

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 03:03:08AM +0300, Ludmila Glinskih wrote:
> Signed-off-by: Ludmila Glinskih 
> ---
>  libavcodec/Makefile|   1 +
>  libavcodec/api-flac-test.c | 290 
> +
>  tests/fate/libavcodec.mak  |   6 +
>  3 files changed, 297 insertions(+)
>  create mode 100644 libavcodec/api-flac-test.c
[...]
> +static int close_encoder(AVCodecContext *enc_ctx)
> +{
> +avcodec_close(enc_ctx);
> +av_freep(&enc_ctx);
> +return 0;
> +}
> +
> +static int close_decoder(AVCodecContext *dec_ctx)
> +{
> +avcodec_close(dec_ctx);
> +av_freep(&dec_ctx);
> +return 0;
> +}

the idea of av_freep() is to clear the freed pointer so no stale
pointer is left that could be dereferenced by mistake
fixed that
applied

thanks

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- 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 v4] Fix mistake with repeating values in first and second channels

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 10:40:57AM +0300, Ludmila Glinskih wrote:
> Signed-off-by: Ludmila Glinskih 
> ---
>  libavcodec/api-flac-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

stashed into the patch and applied

thanks

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

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please


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

Re: [FFmpeg-devel] [PATCH] avutil/mips/generic_macros_msa: volatile doesnt need __

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 11:14:06AM +, Nedeljko Babic wrote:
> LGTM

applied

thanks

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH v4] libavcodec: Add FLAC API test

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 02:38:47PM +0200, Michael Niedermayer wrote:
> On Mon, Apr 20, 2015 at 03:03:08AM +0300, Ludmila Glinskih wrote:
> > Signed-off-by: Ludmila Glinskih 
> > ---
> >  libavcodec/Makefile|   1 +
> >  libavcodec/api-flac-test.c | 290 
> > +
> >  tests/fate/libavcodec.mak  |   6 +
> >  3 files changed, 297 insertions(+)
> >  create mode 100644 libavcodec/api-flac-test.c
> [...]
> > +static int close_encoder(AVCodecContext *enc_ctx)
> > +{
> > +avcodec_close(enc_ctx);
> > +av_freep(&enc_ctx);
> > +return 0;
> > +}
> > +
> > +static int close_decoder(AVCodecContext *dec_ctx)
> > +{
> > +avcodec_close(dec_ctx);
> > +av_freep(&dec_ctx);
> > +return 0;
> > +}
> 
> the idea of av_freep() is to clear the freed pointer so no stale
> pointer is left that could be dereferenced by mistake
> fixed that
> applied

also please send a patch to fix the { } placement as nicolas suggested

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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] libavutil: Make changes in softfloat needed for fixed point aac decoder.

[Nedeljko Babic]

>> -static av_const SoftFloat av_div_sf(SoftFloat a, SoftFloat b){
>> -a.exp -= b.exp+1;
>> -a.mant = ((int64_t)a.mant<<(ONE_BITS+1)) / b.mant;
>> -return av_normalize1_sf(a);
>> +return av_normalize1_sf((SoftFloat){a.mant, --a.exp});
>^^
>a.exp - 1

Ok.
I will change this.

>
>>  }
>>  
>>  static inline av_const int av_cmp_sf(SoftFloat a, SoftFloat b){
>> @@ -102,11 +101,18 @@ static inline av_const int av_cmp_sf(SoftFloat a, 
>> SoftFloat b){
>>  elsereturn  a.mant  - (b.mant >> t);
>>  }
>>  
>> +static inline av_const int av_gt_sf(SoftFloat a, SoftFloat b)
>> +{
>> +int t= a.exp - b.exp;
>> +if(t<0) return (a.mant >> (-t)) >  b.mant  ;
>> +elsereturn  a.mant  > (b.mant >> t);
>> +}
>> +
>>  static inline av_const SoftFloat av_add_sf(SoftFloat a, SoftFloat b){
>>  int t= a.exp - b.exp;
>> -if  (t <-31) return b;
>> -else if (t <  0) return av_normalize1_sf((SoftFloat){b.mant + (a.mant 
>> >> (-t)), b.exp});
>> -else if (t < 32) return av_normalize1_sf((SoftFloat){a.mant + (b.mant 
>> >>   t ), a.exp});
>> +if  (t <=-31) return b;
>> +else if (t <  0) return av_normalize_sf(av_normalize1_sf((SoftFloat){ 
>> b.mant + (a.mant >> (-t)), b.exp}));
>> +else if (t < 32) return av_normalize_sf(av_normalize1_sf((SoftFloat){ 
>> a.mant + (b.mant >>   t ), a.exp}));
>>  else return a;
>>  }
>>  
>> @@ -114,19 +120,146 @@ static inline av_const SoftFloat av_sub_sf(SoftFloat 
>> a, SoftFloat b){
>>  return av_add_sf(a, (SoftFloat){ -b.mant, b.exp});
>>  }
>>  
>> -//FIXME sqrt, log, exp, pow, sin, cos
>> +static inline av_const SoftFloat av_recip_sf(SoftFloat a)
>> +{
>> +int s = a.mant >> 31;
>> +
>> +a.exp = 1 - a.exp;
>> +a.mant = (a.mant ^ s) - s;
>> +a.mant = av_divtbl_sf[(a.mant - 0x2000) >> 22];
>> +a.mant = (a.mant ^ s) - s;
>> +
>> +return a;
>> +}
>> +
>
>> +static av_always_inline SoftFloat av_div_sf(SoftFloat a, SoftFloat b){
>
>missing documentation

I'll add it.

>is this exact ?
>if not what are the gurantees to the user
>

On our tests
For 80.3% of input values the output is exact
For 19.2% of input values the error is one LSB bit of mantissa
For 0.5% of input values the error is two LSB bits of mantissa

>
>> +#if 0
>> +a.exp -= b.exp + 1;
>> +a.mant = ((int64_t)a.mant<<(ONE_BITS+1)) / b.mant;
>> +return av_normalize1_sf(a);
>> +#else
>
>enabing this breaks the tests
>

This is av_div_sf as it was before our changes.
I left it here in case someone wants to develop this function based on what it
was before changes.
Of course, it would be better if I just left code history to git...
Maybe it would be best if I just remove this.

>
>also is it really an advantage to have this av_always_inline ?
>it looks a bit big for always inlining it
>

I guess it depends on compiler and the system on which this will be used.
In any case I suppose that there will not be great performance loss if I remove
av_always_inline.

>
>> +SoftFloat res;
>> +SoftFloat iB, tmp;
>> +
>> +if (b.mant != 0)
>> +{
>> +iB = av_recip_sf(b);
>> +/* Newton iteration to double precision */
>> +tmp = av_sub_sf(FLOAT_1, av_mul_sf(b, iB));
>> +iB = av_add_sf(iB, av_mul_sf(iB, tmp));
>> +tmp = av_sub_sf(FLOAT_1, av_mul_sf(b, iB));
>> +iB = av_add_sf(iB, av_mul_sf(iB, tmp));
>> +tmp = av_sub_sf(FLOAT_1, av_mul_sf(b, iB));
>> +iB = av_add_sf(iB, av_mul_sf(iB, tmp));
>> +res = av_mul_sf(a, iB);
>> +}
>> +else
>> +{
>> +/* handle division-by-zero */
>> +res.mant = 1;
>> +res.exp = 0x7FFF;
>> +}
>> +
>> +return res;
>> +#endif
>> +}
>> +
>> +//FIXME log, exp, pow
>>  
>
>>  static inline av_const SoftFloat av_int2sf(int v, int frac_bits){
>> -return av_normalize_sf((SoftFloat){v, ONE_BITS-frac_bits});
>> +return av_normalize_sf((SoftFloat){v, frac_bits});
>>  }
>
>missing documentation

I'll add it.

>also please make sure that the parameters make some logic sense
>and do not depend on the precission choosen by the implementation
>
>so a "1.0" shwould be generated from the same arguments no matter
>what the precision used in the implementation is

I am not sure I understand you on this.

Basic implementation of this function is the same as in original except
"ONE_BITS-frac_bits" is changed with "frac_bits".
This was done since algorithm is adjusted to be usable in implementation
of fixed point aac decoder.

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

Re: [FFmpeg-devel] [PATCH 13/14] tests: Add aac_fixed decoder test

[Nedeljko Babic]

>> From: Nedeljko Babic 
>> 
>> Signed-off-by: Nedeljko Babic 
>> ---
>>  tests/fate/aac.mak | 63 
>> ++
>>  1 file changed, 63 insertions(+)
>> 
>> diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
>> index 34823be..d90b143 100644
>> --- a/tests/fate/aac.mak
>> +++ b/tests/fate/aac.mak
>> @@ -70,6 +70,69 @@ FATE_AAC += fate-aac-er_eld2100np_48_ep0
>>  fate-aac-er_eld2100np_48_ep0: CMD = pcm -i 
>> $(TARGET_SAMPLES)/aac/er_eld2100np_48_ep0.mp4
>>  fate-aac-er_eld2100np_48_ep0: REF = $(SAMPLES)/aac/er_eld2100np_48.s16
>>  
>> +FATE_AAC += fate-aac-fixed-al04_44
>> +fate-aac-fixed-al04_44: CMD = pcm -c aac_fixed -i 
>> $(TARGET_SAMPLES)/aac/al04_44.mp4
>> +fate-aac-fixed-al04_44: REF = $(SAMPLES)/aac/al04_44.s16
>
>You need to specify that these tests depend on aac_fixed being available.
>
>Look at the end of the file, see how FATE_AAC and FATE_AAC_CT_RAW are handled 
>(what values
>are passed to DEMDEC), and add a new one for these tests using the aac_fixed 
>decoder.

Ok. I'll add this and resubmit the patch.

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

Re: [FFmpeg-devel] [PATCH 2/2] libavutil: Make changes in softfloat needed for fixed point aac decoder.

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 01:33:16PM +, Nedeljko Babic wrote:
> 
> >> -static av_const SoftFloat av_div_sf(SoftFloat a, SoftFloat b){
> >> -a.exp -= b.exp+1;
> >> -a.mant = ((int64_t)a.mant<<(ONE_BITS+1)) / b.mant;
> >> -return av_normalize1_sf(a);
> >> +return av_normalize1_sf((SoftFloat){a.mant, --a.exp});
> >^^
> >a.exp - 1
> 
> Ok.
> I will change this.
> 
> >
> >>  }
> >>  
> >>  static inline av_const int av_cmp_sf(SoftFloat a, SoftFloat b){
> >> @@ -102,11 +101,18 @@ static inline av_const int av_cmp_sf(SoftFloat a, 
> >> SoftFloat b){
> >>  elsereturn  a.mant  - (b.mant >> t);
> >>  }
> >>  
> >> +static inline av_const int av_gt_sf(SoftFloat a, SoftFloat b)
> >> +{
> >> +int t= a.exp - b.exp;
> >> +if(t<0) return (a.mant >> (-t)) >  b.mant  ;
> >> +elsereturn  a.mant  > (b.mant >> t);
> >> +}
> >> +
> >>  static inline av_const SoftFloat av_add_sf(SoftFloat a, SoftFloat b){
> >>  int t= a.exp - b.exp;
> >> -if  (t <-31) return b;
> >> -else if (t <  0) return av_normalize1_sf((SoftFloat){b.mant + (a.mant 
> >> >> (-t)), b.exp});
> >> -else if (t < 32) return av_normalize1_sf((SoftFloat){a.mant + (b.mant 
> >> >>   t ), a.exp});
> >> +if  (t <=-31) return b;
> >> +else if (t <  0) return av_normalize_sf(av_normalize1_sf((SoftFloat){ 
> >> b.mant + (a.mant >> (-t)), b.exp}));
> >> +else if (t < 32) return av_normalize_sf(av_normalize1_sf((SoftFloat){ 
> >> a.mant + (b.mant >>   t ), a.exp}));
> >>  else return a;
> >>  }
> >>  
> >> @@ -114,19 +120,146 @@ static inline av_const SoftFloat 
> >> av_sub_sf(SoftFloat a, SoftFloat b){
> >>  return av_add_sf(a, (SoftFloat){ -b.mant, b.exp});
> >>  }
> >>  
> >> -//FIXME sqrt, log, exp, pow, sin, cos
> >> +static inline av_const SoftFloat av_recip_sf(SoftFloat a)
> >> +{
> >> +int s = a.mant >> 31;
> >> +
> >> +a.exp = 1 - a.exp;
> >> +a.mant = (a.mant ^ s) - s;
> >> +a.mant = av_divtbl_sf[(a.mant - 0x2000) >> 22];
> >> +a.mant = (a.mant ^ s) - s;
> >> +
> >> +return a;
> >> +}
> >> +
> >
> >> +static av_always_inline SoftFloat av_div_sf(SoftFloat a, SoftFloat b){
> >
> >missing documentation
> 
> I'll add it.
> 
> >is this exact ?
> >if not what are the gurantees to the user
> >
> 
> On our tests
> For 80.3% of input values the output is exact
> For 19.2% of input values the error is one LSB bit of mantissa
> For 0.5% of input values the error is two LSB bits of mantissa

I think av_div_sf() should be exact, approximate
functions should have a clear and distinct name, be that
av_div_sf_approx() or whatever


[...]
> >
> >> +SoftFloat res;
> >> +SoftFloat iB, tmp;
> >> +
> >> +if (b.mant != 0)
> >> +{
> >> +iB = av_recip_sf(b);
> >> +/* Newton iteration to double precision */
> >> +tmp = av_sub_sf(FLOAT_1, av_mul_sf(b, iB));
> >> +iB = av_add_sf(iB, av_mul_sf(iB, tmp));
> >> +tmp = av_sub_sf(FLOAT_1, av_mul_sf(b, iB));
> >> +iB = av_add_sf(iB, av_mul_sf(iB, tmp));
> >> +tmp = av_sub_sf(FLOAT_1, av_mul_sf(b, iB));
> >> +iB = av_add_sf(iB, av_mul_sf(iB, tmp));
> >> +res = av_mul_sf(a, iB);
> >> +}
> >> +else
> >> +{
> >> +/* handle division-by-zero */
> >> +res.mant = 1;
> >> +res.exp = 0x7FFF;
> >> +}
> >> +
> >> +return res;
> >> +#endif
> >> +}
> >> +
> >> +//FIXME log, exp, pow
> >>  
> >
> >>  static inline av_const SoftFloat av_int2sf(int v, int frac_bits){
> >> -return av_normalize_sf((SoftFloat){v, ONE_BITS-frac_bits});
> >> +return av_normalize_sf((SoftFloat){v, frac_bits});
> >>  }
> >
> >missing documentation
> 
> I'll add it.
> 
> >also please make sure that the parameters make some logic sense
> >and do not depend on the precission choosen by the implementation
> >
> >so a "1.0" shwould be generated from the same arguments no matter
> >what the precision used in the implementation is
> 
> I am not sure I understand you on this.
> 
> Basic implementation of this function is the same as in original except
> "ONE_BITS-frac_bits" is changed with "frac_bits".
> This was done since algorithm is adjusted to be usable in implementation
> of fixed point aac decoder.

the numbers are of the form x * 2^y
thus the interface to create 4.0 should be av_int2sf(1,2) not
int2sf(1,123)
The interface should be simple, logic and intuitive

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

[FFmpeg-devel] [PATCH 2/2] avformat/format: Add generic trace av_log in av_probe_input_format3()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/format.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/format.c b/libavformat/format.c
index fa94b7d..7df06b7 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -195,6 +195,8 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, int 
is_opened,
 score = 0;
 if (fmt1->read_probe) {
 score = fmt1->read_probe(&lpd);
+if (score)
+av_log(NULL, AV_LOG_TRACE, "Probing %s score:%d size:%d\n", 
fmt1->name, score, lpd.buf_size);
 if (fmt1->extensions && av_match_ext(lpd.filename, 
fmt1->extensions)) {
 if  (nodat == 0) score = FFMAX(score, 1);
 else if (nodat == 1) score = FFMAX(score, 
AVPROBE_SCORE_EXTENSION / 2 - 1);
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/2] avformat/nsvdec: remove trace log from probe(), this is better done generically not per format

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/nsvdec.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/nsvdec.c b/libavformat/nsvdec.c
index 5002bd7..de55396 100644
--- a/libavformat/nsvdec.c
+++ b/libavformat/nsvdec.c
@@ -723,7 +723,6 @@ static int nsv_probe(AVProbeData *p)
 {
 int i, score = 0;
 
-av_log(NULL, AV_LOG_TRACE, "nsv_probe(), buf_size %d\n", p->buf_size);
 /* check file header */
 /* streamed files might not have any header */
 if (p->buf[0] == 'N' && p->buf[1] == 'S' &&
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/2] ffmpeg: add option not to offset seek position by start time

[wm4]

---
 doc/ffmpeg.texi | 7 +++
 ffmpeg.h| 2 ++
 ffmpeg_opt.c| 5 -
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index d995995..c66cb16 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1158,6 +1158,13 @@ This option enables or disables accurate seeking in 
input files with the
 transcoding. Use @option{-noaccurate_seek} to disable it, which may be useful
 e.g. when copying some streams and transcoding the others.
 
+@item -seek_timestamp (@emph{input})
+This option enables or disables seeking by timestamp in input files with the
+@option{-ss} option. It is disabled by default. If enabled, the argument
+to the @option{-ss} option is considered an actual timestamp, and is not
+offset by the start time of the file. This matters only for files which do
+not start from timestamp 0, such as transport streams.
+
 @item -thread_queue_size @var{size} (@emph{input})
 This option sets the maximum number of queued packets when reading from the
 file or device. With low latency / high rate live streams, packets may be
diff --git a/ffmpeg.h b/ffmpeg.h
index 9050202..71061da 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -92,6 +92,7 @@ typedef struct OptionsContext {
 
 /* input/output options */
 int64_t start_time;
+int seek_timestamp;
 const char *format;
 
 SpecifierOpt *codec_names;
@@ -339,6 +340,7 @@ typedef struct InputFile {
 int64_t ts_offset;
 int64_t last_ts;
 int64_t start_time;   /* user-specified start time in AV_TIME_BASE or 
AV_NOPTS_VALUE */
+int seek_timestamp;
 int64_t recording_time;
 int nb_streams;   /* number of stream that ffmpeg is aware of; may be 
different
  from ctx.nb_streams if new streams appear during 
av_read_frame() */
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 8f1f35d..75c80e7 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -919,7 +919,7 @@ static int open_input_file(OptionsContext *o, const char 
*filename)
 
 timestamp = (o->start_time == AV_NOPTS_VALUE) ? 0 : o->start_time;
 /* add the stream start time */
-if (ic->start_time != AV_NOPTS_VALUE)
+if (!o->seek_timestamp && ic->start_time != AV_NOPTS_VALUE)
 timestamp += ic->start_time;
 
 /* if seeking requested, we execute it */
@@ -2865,6 +2865,9 @@ const OptionDef options[] = {
 { "ss", HAS_ARG | OPT_TIME | OPT_OFFSET |
 OPT_INPUT | OPT_OUTPUT,  { .off = 
OFFSET(start_time) },
 "set the start time offset", "time_off" },
+{ "seek_timestamp", HAS_ARG | OPT_INT | OPT_OFFSET |
+OPT_INPUT,   { .off = 
OFFSET(seek_timestamp) },
+"enable/disable seeking by timestamp with -ss" },
 { "accurate_seek",  OPT_BOOL | OPT_OFFSET | OPT_EXPERT |
 OPT_INPUT,   { .off = 
OFFSET(accurate_seek) },
 "enable/disable accurate seeking with -ss" },
-- 
2.1.4

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

[FFmpeg-devel] [PATCH 2/2] fate: gapless: fix mp3 tests

[wm4]

Seeking to a negative time did not have the desired effect of seeking to
the next valid position (the file start). On the other hand, just
"-ss 0" will normally seek to a position higher than 0, because it adds
the start time of the file. (The start time is not 0 because the gapless
code skips a few samples from the start.)

Fix this by using the "-seek_timestamp 1" option, which makes "-ss 0" do
what you'd expect it would do.

Also put the -ss option at the right place, before -i. This actually
makes it seek, instead of something completely else. The ".out-3" test
is no different in the -usetoc 0/1 cases, because the seeking is
inaccurate (in both cases).
---
In other news, gapless still breaks with seeking, and the last part of
the tests (...out-3 lines) test something broken. I conclude it can't
be made work without some form of full indexing.
---
 tests/fate-run.sh| 13 +
 tests/ref/fate/gapless-mp3   |  4 ++--
 tests/ref/fate/gapless-mp3-notoc |  4 ++--
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 0165812..1a8ff94 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -229,20 +229,17 @@ gapless(){
 decfile3="${outdir}/${test}.out-3"
 cleanfiles="$cleanfiles $decfile1 $decfile2 $decfile3"
 
-# large enough to make ffmpeg.c seek to the start of the file
-start_offset=-1
-
 # test packet data
-ffmpeg -i "$sample" $extra_args -flags +bitexact -c:a copy -f framecrc -y 
$decfile1
+ffmpeg $extra_args -i "$sample" -flags +bitexact -c:a copy -f framecrc -y 
$decfile1
 do_md5sum $decfile1
 # test decoded (and cut) data
-ffmpeg -i "$sample" $extra_args -flags +bitexact -f wav md5:
+ffmpeg $extra_args -i "$sample" -flags +bitexact -f wav md5:
 # the same as above again, with seeking to the start
-ffmpeg -ss $start_offset -i "$sample" $extra_args -flags +bitexact -c:a 
copy -f framecrc -y $decfile2
+ffmpeg $extra_args -ss 0 -seek_timestamp 1 -i "$sample" -flags +bitexact 
-c:a copy -f framecrc -y $decfile2
 do_md5sum $decfile2
-ffmpeg -ss $start_offset -i "$sample" $extra_args -flags +bitexact -f wav 
md5:
+ffmpeg $extra_args -ss 0 -seek_timestamp 1 -i "$sample" -flags +bitexact 
-f wav md5:
 # test packet data, with seeking to a specific position
-ffmpeg -ss 5 -i "$sample" $extra_args -flags +bitexact -c:a copy -f 
framecrc -y $decfile3
+ffmpeg $extra_args -ss 5 -seek_timestamp 1 -i "$sample" -flags +bitexact 
-c:a copy -f framecrc -y $decfile3
 do_md5sum $decfile3
 }
 
diff --git a/tests/ref/fate/gapless-mp3 b/tests/ref/fate/gapless-mp3
index 3cff9a8..984ae84 100644
--- a/tests/ref/fate/gapless-mp3
+++ b/tests/ref/fate/gapless-mp3
@@ -1,5 +1,5 @@
 d5c88cf38416329a052a9b0cb140fb4c *tests/data/fate/gapless-mp3.out-1
 c96c3ae7bd3300fd2f4debac222de5b7
-68f040b12d79c71e3b2e8ba90a9cbd96 *tests/data/fate/gapless-mp3.out-2
+3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3.out-2
 c96c3ae7bd3300fd2f4debac222de5b7
-e750fc8ae00ba29a03983edafbb63975 *tests/data/fate/gapless-mp3.out-3
+70e7cd7f2b6365e7f48ed206113f06fc *tests/data/fate/gapless-mp3.out-3
diff --git a/tests/ref/fate/gapless-mp3-notoc b/tests/ref/fate/gapless-mp3-notoc
index 3528e71..f52efff 100644
--- a/tests/ref/fate/gapless-mp3-notoc
+++ b/tests/ref/fate/gapless-mp3-notoc
@@ -1,5 +1,5 @@
 d5c88cf38416329a052a9b0cb140fb4c *tests/data/fate/gapless-mp3-notoc.out-1
 c96c3ae7bd3300fd2f4debac222de5b7
-68f040b12d79c71e3b2e8ba90a9cbd96 *tests/data/fate/gapless-mp3-notoc.out-2
+3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3-notoc.out-2
 c96c3ae7bd3300fd2f4debac222de5b7
-e750fc8ae00ba29a03983edafbb63975 *tests/data/fate/gapless-mp3-notoc.out-3
+e82eaed507ce3f7f6199918159e1ddd7 *tests/data/fate/gapless-mp3-notoc.out-3
-- 
2.1.4

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

[FFmpeg-devel] [PATCH] webmdashenc: Fix potential memory leak

[Vignesh Venkatasubramanian]

Fix potential memory leak in WebM DASH Muxer. This fixes coverity
scan CID 1295088.

Signed-off-by: Vignesh Venkatasubramanian 
---
 libavformat/webmdashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
index a8eb8ac..6b94e54 100644
--- a/libavformat/webmdashenc.c
+++ b/libavformat/webmdashenc.c
@@ -398,8 +398,8 @@ static int write_adaptation_set(AVFormatContext *s, int 
as_index)
 ret = write_representation(s, s->streams[as->streams[i]],
representation_id, !width_in_as,
!height_in_as, !sample_rate_in_as);
-if (ret) return ret;
 av_free(representation_id);
+if (ret) return ret;
 }
 avio_printf(s->pb, "\n");
 return 0;
-- 
2.2.0.rc0.207.ga3a616c

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for H264 lpf and weight/biweight functions

[Timothy Gu]

On Mon, Apr 20, 2015 at 2:54 AM  wrote:

> From: Shivraj Patil 
>
> Signed-off-by: Shivraj Patil 
> ---
>  libavcodec/h264dsp.c|1 +
>  libavcodec/h264dsp.h|2 +
>  libavcodec/mips/Makefile|2 +
>  libavcodec/mips/h264dsp_init_mips.c |   74 +
>  libavcodec/mips/h264dsp_mips.h  |   71 +
>  libavcodec/mips/h264dsp_msa.c   | 3037
> +++
>  libavutil/mips/generic_macros_msa.h |  518 ++
>  7 files changed, 3705 insertions(+)
>  create mode 100644 libavcodec/mips/h264dsp_init_mips.c
>  create mode 100644 libavcodec/mips/h264dsp_mips.h
>  create mode 100644 libavcodec/mips/h264dsp_msa.c
>
[...]

> diff --git a/libavcodec/mips/h264dsp_init_mips.c
> b/libavcodec/mips/h264dsp_init_mips.c
> new file mode 100644
> index 000..8d3d760
> --- /dev/null
> +++ b/libavcodec/mips/h264dsp_init_mips.c
> @@ -0,0 +1,74 @@
> +/*
> + * Copyright (c) 2015 Parag Salasakar (parag.salasa...@imgtec.com)
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "h264dsp_mips.h"
> +
> +#if HAVE_MSA
> +static av_cold void h264dsp_init_msa(H264DSPContext *c,
> + const int bit_depth,
> + const int chroma_format_idc)
> +{
> +if (8 == bit_depth) {
> +c->h264_v_loop_filter_luma = ff_h264_v_lpf_luma_inter_msa;
> +c->h264_h_loop_filter_luma = ff_h264_h_lpf_luma_inter_msa;
> +c->h264_h_loop_filter_luma_mbaff =
> +ff_h264_h_loop_filter_luma_mbaff_msa;
> +c->h264_v_loop_filter_luma_intra = ff_h264_v_lpf_luma_intra_msa;
> +c->h264_h_loop_filter_luma_intra = ff_h264_h_lpf_luma_intra_msa;
> +c->h264_h_loop_filter_luma_mbaff_intra =
> +ff_h264_h_loop_filter_luma_mbaff_intra_msa;
> +c->h264_v_loop_filter_chroma = ff_h264_v_lpf_chroma_inter_msa;
> +
> +if (chroma_format_idc <= 1)
> +c->h264_h_loop_filter_chroma = ff_h264_h_lpf_chroma_inter_msa;
> +else
> +c->h264_h_loop_filter_chroma =
> +ff_h264_h_loop_filter_chroma422_msa;
> +
> +if (chroma_format_idc > 1)
> +c->h264_h_loop_filter_chroma_mbaff =
> +ff_h264_h_loop_filter_chroma422_mbaff_msa;
> +
> +c->h264_v_loop_filter_chroma_intra =
> +ff_h264_v_lpf_chroma_intra_msa;
> +
> +if (chroma_format_idc <= 1)
> +c->h264_h_loop_filter_chroma_intra =
> +ff_h264_h_lpf_chroma_intra_msa;
> +
> +/* Weighted MC */
> +c->weight_h264_pixels_tab[0] = ff_weight_h264_pixels16_8_msa;
> +c->weight_h264_pixels_tab[1] = ff_weight_h264_pixels8_8_msa;
> +c->weight_h264_pixels_tab[2] = ff_weight_h264_pixels4_8_msa;
> +
> +c->biweight_h264_pixels_tab[0] = ff_biweight_h264_pixels16_8_msa;
> +c->biweight_h264_pixels_tab[1] = ff_biweight_h264_pixels8_8_msa;
> +c->biweight_h264_pixels_tab[2] = ff_biweight_h264_pixels4_8_msa;
> +}  // if (8 == bit_depth)
> +}
> +#endif  // #if HAVE_MSA
> +
> +av_cold void ff_h264dsp_init_mips(H264DSPContext *c, const int bit_depth,
> +  const int chroma_format_idc)
> +{
> +#if HAVE_MSA
> +h264dsp_init_msa(c, bit_depth, chroma_format_idc);
> +#endif  // #if HAVE_MSA
> +}
>

You should fold the _init_msa() function into this function. You also need
to add the flags into libavutil/mips/cpu.h as the user might not want to
use MSA at runtime.

See libavutil/cpu.h and libavutil/*/cpu.h.

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for H264 lpf and weight/biweight functions

[James Almer]

On 20/04/15 3:58 PM, Timothy Gu wrote:
> You should fold the _init_msa() function into this function. You also need
> to add the flags into libavutil/mips/cpu.h as the user might not want to
> use MSA at runtime.
> 
> See libavutil/cpu.h and libavutil/*/cpu.h.
> 
> Timothy

User selectable cpuflags are mainly for debugging. Pretty much only devs ever 
use them.
For that matter, do mips processors even have some sort of cpuid instruction at 
all? Since 
these optimizations all rely on configure time options to choose what feature 
sets are 
compiled and used, I'm going to guess no. Otherwise it would have been done in 
a similar 
fashion as x86 and arm from the get go.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mp3dec: Adjust returned timestamp in the CBR seeking case

[Michael Niedermayer]

With this the returned timestamp should match the packet instead of
the requested timestamp, which may lay between  packets

Signed-off-by: Michael Niedermayer 
---
 libavformat/mp3dec.c |6 ++
 tests/ref/fate/gapless-mp3-notoc |2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 06bc1d0..89990ec 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -489,6 +489,12 @@ static int mp3_seek(AVFormatContext *s, int stream_index, 
int64_t timestamp,
 ret = avio_seek(s->pb, best_pos, SEEK_SET);
 if (ret < 0)
 return ret;
+
+if (mp3->is_cbr && ie == &ie1) {
+int frame_duration = av_rescale(st->duration, 1, mp3->frames);
+ie1.timestamp = frame_duration * (av_rescale(best_pos - 
s->internal->data_offset, mp3->frames, mp3->header_filesize));
+}
+
 ff_update_cur_dts(s, st, ie->timestamp);
 st->skip_samples = ie->timestamp <= 0 ? mp3->start_pad + 528 + 1 : 0;
 return 0;
diff --git a/tests/ref/fate/gapless-mp3-notoc b/tests/ref/fate/gapless-mp3-notoc
index f52efff..936d0ba 100644
--- a/tests/ref/fate/gapless-mp3-notoc
+++ b/tests/ref/fate/gapless-mp3-notoc
@@ -2,4 +2,4 @@ d5c88cf38416329a052a9b0cb140fb4c 
*tests/data/fate/gapless-mp3-notoc.out-1
 c96c3ae7bd3300fd2f4debac222de5b7
 3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3-notoc.out-2
 c96c3ae7bd3300fd2f4debac222de5b7
-e82eaed507ce3f7f6199918159e1ddd7 *tests/data/fate/gapless-mp3-notoc.out-3
+92e37f050ad4fc817730c8af17ee6d1b *tests/data/fate/gapless-mp3-notoc.out-3
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/nsvdec: remove trace log from probe(), this is better done generically not per format

[Paul B Mahol]

Dana 20. 4. 2015. 17:39 osoba "Michael Niedermayer" 
napisala je:
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/nsvdec.c |1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/nsvdec.c b/libavformat/nsvdec.c
> index 5002bd7..de55396 100644
> --- a/libavformat/nsvdec.c
> +++ b/libavformat/nsvdec.c
> @@ -723,7 +723,6 @@ static int nsv_probe(AVProbeData *p)
>  {
>  int i, score = 0;
>
> -av_log(NULL, AV_LOG_TRACE, "nsv_probe(), buf_size %d\n",
p->buf_size);
>  /* check file header */
>  /* streamed files might not have any header */
>  if (p->buf[0] == 'N' && p->buf[1] == 'S' &&
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] fate: gapless: fix mp3 tests

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 07:36:52PM +0200, wm4 wrote:
> Seeking to a negative time did not have the desired effect of seeking to
> the next valid position (the file start). On the other hand, just
> "-ss 0" will normally seek to a position higher than 0, because it adds
> the start time of the file. (The start time is not 0 because the gapless
> code skips a few samples from the start.)
> 
> Fix this by using the "-seek_timestamp 1" option, which makes "-ss 0" do
> what you'd expect it would do.
> 
> Also put the -ss option at the right place, before -i. This actually
> makes it seek, instead of something completely else. The ".out-3" test
> is no different in the -usetoc 0/1 cases, because the seeking is
> inaccurate (in both cases).
> ---
> In other news, gapless still breaks with seeking, and the last part of
> the tests (...out-3 lines) test something broken. I conclude it can't
> be made work without some form of full indexing.
> ---
>  tests/fate-run.sh| 13 +
>  tests/ref/fate/gapless-mp3   |  4 ++--
>  tests/ref/fate/gapless-mp3-notoc |  4 ++--
>  3 files changed, 9 insertions(+), 12 deletions(-)

applied

thanks

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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] ffmpeg: add option not to offset seek position by start time

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 07:36:51PM +0200, wm4 wrote:
> ---
>  doc/ffmpeg.texi | 7 +++
>  ffmpeg.h| 2 ++
>  ffmpeg_opt.c| 5 -
>  3 files changed, 13 insertions(+), 1 deletion(-)

applied

thanks

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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/mp3dec: Adjust returned timestamp in the CBR seeking case

[wm4]

On Mon, 20 Apr 2015 21:25:44 +0200
Michael Niedermayer  wrote:

> With this the returned timestamp should match the packet instead of
> the requested timestamp, which may lay between  packets
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mp3dec.c |6 ++
>  tests/ref/fate/gapless-mp3-notoc |2 +-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 06bc1d0..89990ec 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -489,6 +489,12 @@ static int mp3_seek(AVFormatContext *s, int 
> stream_index, int64_t timestamp,
>  ret = avio_seek(s->pb, best_pos, SEEK_SET);
>  if (ret < 0)
>  return ret;
> +
> +if (mp3->is_cbr && ie == &ie1) {
> +int frame_duration = av_rescale(st->duration, 1, mp3->frames);

Why use av_rescale here? Shouldn't a normal division work fine?

> +ie1.timestamp = frame_duration * (av_rescale(best_pos - 
> s->internal->data_offset, mp3->frames, mp3->header_filesize));

Redundant (  ) ?

> +}
> +
>  ff_update_cur_dts(s, st, ie->timestamp);
>  st->skip_samples = ie->timestamp <= 0 ? mp3->start_pad + 528 + 1 : 0;
>  return 0;
> diff --git a/tests/ref/fate/gapless-mp3-notoc 
> b/tests/ref/fate/gapless-mp3-notoc
> index f52efff..936d0ba 100644
> --- a/tests/ref/fate/gapless-mp3-notoc
> +++ b/tests/ref/fate/gapless-mp3-notoc
> @@ -2,4 +2,4 @@ d5c88cf38416329a052a9b0cb140fb4c 
> *tests/data/fate/gapless-mp3-notoc.out-1
>  c96c3ae7bd3300fd2f4debac222de5b7
>  3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3-notoc.out-2
>  c96c3ae7bd3300fd2f4debac222de5b7
> -e82eaed507ce3f7f6199918159e1ddd7 *tests/data/fate/gapless-mp3-notoc.out-3
> +92e37f050ad4fc817730c8af17ee6d1b *tests/data/fate/gapless-mp3-notoc.out-3

Maybe there's no better way for now. Did you look at (or listen to) the
output? Does it improve?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: Adjust returned timestamp in the CBR seeking case

[wm4]

On Mon, 20 Apr 2015 21:25:44 +0200
Michael Niedermayer  wrote:

> With this the returned timestamp should match the packet instead of
> the requested timestamp, which may lay between  packets
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mp3dec.c |6 ++
>  tests/ref/fate/gapless-mp3-notoc |2 +-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 06bc1d0..89990ec 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -489,6 +489,12 @@ static int mp3_seek(AVFormatContext *s, int 
> stream_index, int64_t timestamp,
>  ret = avio_seek(s->pb, best_pos, SEEK_SET);
>  if (ret < 0)
>  return ret;
> +
> +if (mp3->is_cbr && ie == &ie1) {
> +int frame_duration = av_rescale(st->duration, 1, mp3->frames);
> +ie1.timestamp = frame_duration * (av_rescale(best_pos - 
> s->internal->data_offset, mp3->frames, mp3->header_filesize));
> +}
> +
>  ff_update_cur_dts(s, st, ie->timestamp);
>  st->skip_samples = ie->timestamp <= 0 ? mp3->start_pad + 528 + 1 : 0;
>  return 0;
> diff --git a/tests/ref/fate/gapless-mp3-notoc 
> b/tests/ref/fate/gapless-mp3-notoc
> index f52efff..936d0ba 100644
> --- a/tests/ref/fate/gapless-mp3-notoc
> +++ b/tests/ref/fate/gapless-mp3-notoc
> @@ -2,4 +2,4 @@ d5c88cf38416329a052a9b0cb140fb4c 
> *tests/data/fate/gapless-mp3-notoc.out-1
>  c96c3ae7bd3300fd2f4debac222de5b7
>  3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3-notoc.out-2
>  c96c3ae7bd3300fd2f4debac222de5b7
> -e82eaed507ce3f7f6199918159e1ddd7 *tests/data/fate/gapless-mp3-notoc.out-3
> +92e37f050ad4fc817730c8af17ee6d1b *tests/data/fate/gapless-mp3-notoc.out-3

I checked myself, and the output looks and sounds potentially good.
(But I'm rather bad at spotting the "gap".) So I'd suggest applying
this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Claudio Freire]

On Sat, Apr 18, 2015 at 10:34 AM, Michael Niedermayer  wrote:
> On Sat, Apr 18, 2015 at 01:59:53PM +0200, Andreas Cadhalpun wrote:
>> On 18.04.2015 04:40, Michael Niedermayer wrote:
>> > On Sat, Apr 18, 2015 at 12:55:08AM +0200, Andreas Cadhalpun wrote:
>> >> The problem is that minath is not the minimum, only close:
>> >> minath = ath(3410, ATH_ADD) = -5.24237967
>> >>  ath(3407, ATH_ADD) = -5.24241638
>> >
>> > the exact location of the minimum depends on teh "add" value
>> > its around 3410 for add=0 and around 3407 for add=4
>>
>> True.
>>
>> > for fun, 3407.080774800152 is even closer than 3407 for add=4
>>
>> Yes, but the ath function calculates with floats and thus is
>> inaccurate enough that it doesn't matter if the input is 3407
>> or 3407.1.
>>
>> > but the "add" parameter should probably be user selectable
>>
>> Currently ATH_ADD is a #define, but if that was made user selectable,
>> one could approximate the position of the minimum:
>> minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)
>>
>> > also if you want to prevent coeffs[].ath from becoming negative then
>>
>> That isn't strictly required, because 0 is a valid value and is just
>> as bad as a negative one.
>
>> But I assume the model works better, if it uses something closer to the
>> minimum of the ath function.
>
> thats more a question for claudio than me id say

TL;DR, band->thr should not be negative ever, band->thr == 0.0f would
cause lots of issues on its own if band->energy != 0.0f in such a case
(though I don't see how band->thr can be 0.0f if band->energy is not),
and ath <= 0.0f can happen and should be no trouble if it does.

The long version:

ath should approximate the shape of the absolute hearing threshold, so
yes, it's best if it really uses the minimum, since that will prevent
clipping of the ath curve and result in a more accurate threshold
computation.

Still, when

band->thr_quiet = band->thr = FFMAX(band->thr, coeffs[g].ath);

Is computed, correct me if I'm wrong, but band->thr is the band's
energy (sum of squares), so I see how that can be zero, but not how it
can be negative.

Thus, if ath became negative, its effective shape would be clipped by band->thr.

The whole point of ath is to avoid spending lots of bits for signals
normally too faint to be heard. The case of band->energy==0 is already
handled by zero flags, but faint noise in higher frequencies needs an
absolute hearing threshold curve to properly decide when not to waste
bits in those bands. But since people can adjust the volume and you
never know the final SPL at which the signal will be played, a precise
calculation of said threshold is pointless, what I try to do in the
patch series in issue #2686, is to attempt to shift it to the
equivalent power of a 16-bit signal's quantization noise, which one
would assume should be below the absolute hearing threshold in any
sane reproduction environment - so it's a conservative estimate.

That said, ath should be > 0, not >= 0. But it's hard to enforce that
without clipping it, and it's not worth the trouble attempting it. I
don't believe accurate computation of ath to that point would improve
encoding that much. Any reasonable approximation will do.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for H264 lpf and weight/biweight functions

[Timothy Gu]

On Mon, Apr 20, 2015 at 12:04 PM James Almer  wrote:
>
> For that matter, do mips processors even have some sort of cpuid
> instruction at all?


AFAIK it does. See:

-
https://github.com/torvalds/linux/blob/master/arch/mips/kernel/cpu-probe.c#L519-L520
-
https://github.com/torvalds/linux/blob/master/arch/mips/include/asm/mipsregs.h#L1176
-
https://github.com/torvalds/linux/blob/master/arch/mips/include/asm/mipsregs.h#L903-L916


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

Re: [FFmpeg-devel] [libav-devel] [PATCH] alsdec: validate time diff index

[Andreas Cadhalpun]

On 19.04.2015 22:20, Luca Barbato wrote:
> On 18/04/15 18:58, Andreas Cadhalpun wrote:
>> If begin is smaller than t, the subtraction 'begin -= t' wraps around,
>> because begin is unsigned. The same applies for end < t.
>>
>> This causes segmentation faults.
> 
> Actually, the access to raw_buffer seems a bit optimistic all over this
> code.
> 
> I'd check that `master` is always between `raw_buffer` and the end of it.

You mean something like the attached patch?

> (I'm not sure if `div_blocks` is validated before, same for `offset`)

That should catch problems in those as well.

Best regards,
Andreas
>From 5b0a985130f94c887c40028f5549a29576a26991 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Mon, 20 Apr 2015 23:14:28 +0200
Subject: [PATCH] alsdec: check sample pointer range in
 revert_channel_correlation

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/alsdec.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index c81db18..a14761c 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -1246,6 +1246,7 @@ static int revert_channel_correlation(ALSDecContext *ctx, ALSBlockData *bd,
 ALSChannelData *ch = cd[c];
 unsigned int   dep = 0;
 unsigned int channels = ctx->avctx->channels;
+unsigned int channel_size = ctx->sconf.frame_length + ctx->sconf.max_order;
 
 if (reverted[c])
 return 0;
@@ -1303,6 +1304,15 @@ static int revert_channel_correlation(ALSDecContext *ctx, ALSBlockData *bd,
 end   -= t;
 }
 
+if (master + FFMIN(begin - 1, begin - 1 + t) < ctx->raw_buffer ||
+master + FFMAX(end + 1,   end + 1 + t)   > ctx->raw_buffer + channels * channel_size) {
+av_log(ctx->avctx, AV_LOG_ERROR,
+   "sample pointer range [%p, %p] not contained in raw_buffer [%p, %p].\n",
+   master + FFMIN(begin - 1, begin - 1 + t), master + FFMAX(end + 1,   end + 1 + t),
+   ctx->raw_buffer, ctx->raw_buffer + channels * channel_size);
+return AVERROR_INVALIDDATA;
+}
+
 for (smp = begin; smp < end; smp++) {
 y  = (1 << 6) +
  MUL64(ch[dep].weighting[0], master[smp - 1]) +
-- 
2.1.4

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Andreas Cadhalpun]

On 20.04.2015 12:53, Luca Barbato wrote:
> On 18/04/15 22:37, Andreas Cadhalpun wrote:
>> I think the crash should be fixed before a larger reshaping.
>>
> 
> I do not see how you can fix it w/out having a separate code path for
> 0-energy/0-threshold band. And getting that would require that kind of
> work. =\

I'm sorry I don't understand. The patch I sent avoids the problem.

Alternatively coeffs[g].ath could be forced to always be positive,
which would avoid the problem as well.

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

[FFmpeg-devel] [PATCH] oggparsedirac: check return value of init_get_bits

[Christopher Watkins]

From a93fa19467ac2568cfe32332b789b315e37dbdf1 Mon Sep 17 00:00:00 2001
From: Chris Watkins 
Date: Mon, 20 Apr 2015 14:23:57 -0700
Subject: [PATCH] oggparsedirac: check return value of init_get_bits

If init_get_bits fails the GetBitContext is invalid and must not be
used. Check the return value in dirac_header and propogate the error.

Signed-off-by: Chris Watkins 
---
 libavformat/oggparsedirac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/oggparsedirac.c b/libavformat/oggparsedirac.c
index 10fb07e..35be655 100644
--- a/libavformat/oggparsedirac.c
+++ b/libavformat/oggparsedirac.c
@@ -36,7 +36,9 @@ static int dirac_header(AVFormatContext *s, int idx)
 if (st->codec->codec_id == AV_CODEC_ID_DIRAC)
 return 0;
 
-init_get_bits(&gb, os->buf + os->pstart + 13, (os->psize - 13) * 8);
+if (init_get_bits(&gb, os->buf + os->pstart + 13, (os->psize - 13) * 8) < 0)
+return -1;
+
 if (avpriv_dirac_parse_sequence_header(st->codec, &gb, &source) < 0)
 return -1;
 
-- 
2.2.0.rc0.207.ga3a616c

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Andreas Cadhalpun]

On 20.04.2015 22:15, Claudio Freire wrote:
> TL;DR, band->thr should not be negative ever, band->thr == 0.0f would
> cause lots of issues on its own if band->energy != 0.0f in such a case
> (though I don't see how band->thr can be 0.0f if band->energy is not),

This could happen in pathological cases:
band->energy = 1e-37f
band->thr= band->energy * 0.001258925f = 0.0f

> and ath <= 0.0f can happen and should be no trouble if it does.

The trouble begins if band->thr is also 0.0f.

> The long version:
> 
> ath should approximate the shape of the absolute hearing threshold, so
> yes, it's best if it really uses the minimum, since that will prevent
> clipping of the ath curve and result in a more accurate threshold
> computation.

So you agree with my patch fixing minath?
Or would you prefer a version with:
minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)

> Still, when
> 
> band->thr_quiet = band->thr = FFMAX(band->thr, coeffs[g].ath);
> 
> Is computed, correct me if I'm wrong, but band->thr is the band's
> energy (sum of squares), so I see how that can be zero, but not how it
> can be negative.

Yes, band->thr is always >= 0.0f.

> Thus, if ath became negative, its effective shape would be clipped by 
> band->thr.

Indeed. That's why I wrote that ath = 0.0f is just as bad as a negative one.

> The whole point of ath is to avoid spending lots of bits for signals
> normally too faint to be heard. The case of band->energy==0 is already
> handled by zero flags, but faint noise in higher frequencies needs an
> absolute hearing threshold curve to properly decide when not to waste
> bits in those bands. But since people can adjust the volume and you
> never know the final SPL at which the signal will be played, a precise
> calculation of said threshold is pointless, what I try to do in the
> patch series in issue #2686, is to attempt to shift it to the
> equivalent power of a 16-bit signal's quantization noise, which one
> would assume should be below the absolute hearing threshold in any
> sane reproduction environment - so it's a conservative estimate.

Thanks for the explanation.

> That said, ath should be > 0, not >= 0.

Good to know.

> But it's hard to enforce that
> without clipping it, and it's not worth the trouble attempting it.

Why would clipping be a problem?
What about the attached patch?

> I don't believe accurate computation of ath to that point would improve
> encoding that much. Any reasonable approximation will do.

It's more about avoiding nasty problems with division by 0.

Best regards,
Andreas

>From 21bf9c94e4fb3aaacfc122eacb581c7504d2183a Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Tue, 21 Apr 2015 00:13:16 +0200
Subject: [PATCH] aacpsy: clip coeffs[g].ath at 1e-30f

This ensures that band->thr is always positive.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/aacpsy.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/aacpsy.c b/libavcodec/aacpsy.c
index 7205ee3..bd3068f 100644
--- a/libavcodec/aacpsy.c
+++ b/libavcodec/aacpsy.c
@@ -350,6 +350,9 @@ static av_cold int psy_3gpp_init(FFPsyContext *ctx) {
 for (i = 1; i < band_sizes[g]; i++)
 minscale = FFMIN(minscale, ath((start + i) * line_to_frequency, ATH_ADD));
 coeffs[g].ath = minscale - minath;
+if (coeffs[g].ath < 1e-30f) {
+coeffs[g].ath = 1e-30f;
+}
 start += band_sizes[g];
 }
 }
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH v4] libavcodec: Add FLAC API test

[Kieran Kunhya]

On 20 April 2015 at 01:03, Ludmila Glinskih  wrote:
> Signed-off-by: Ludmila Glinskih 
> ---
>  libavcodec/Makefile|   1 +
>  libavcodec/api-flac-test.c | 290 
> +

I would put this in its own directory.
I think the next thing you should work on is a simple, shared version
of framecrc so these tests can be integrated into FATE.
Or you can use the framecrc in libavformat - I have no preference.

You may need some help though from people who understand the build
system better then me about fate integration.

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

Re: [FFmpeg-devel] Patch for High color and High bit-depth support

[James Zern]

On Sat, Apr 18, 2015 at 1:06 PM, James Zern  wrote:
> On Thu, Apr 16, 2015 at 6:19 PM, Debargha Mukherjee  
> wrote:
>> Resolutions inline...
>>
>> From d84e140ed83bdc3889720e4a6af330198176b839 Mon Sep 17 00:00:00 2001
>> From: Deb Mukherjee 
>> Date: Wed, 25 Mar 2015 17:10:16 -0700
>> Subject: [PATCH] Support for VP9 high-color/high-bit-depth encoding
>>
>> Patch to support VP9 encoding with new profiles 1-3.
>> Profile 1 (8-bit 422/444) should work with default libvpx
>> configuration.
>> However you will need to configure libvpx with
>> --enable-vp9-highbitdepth before building and linking
>> with ffmpeg for profile 2 (10-/12-bit 420) and profile 3
>> (10-/12-bit 422/444) encoding.
>>
>> You may use the appropriate profile option on the
>> command line:
>> -profile:v 1 for 422/444 8-bit encoding
>> -profile:v 2 for 420 10-/12- bit encoding
>> -profile:v 3 for 422/444 10-/12-bit encoding
>> If you do not use the -profile:v option, it will be deduced
>> from the source format.
>> ---
>>  libavcodec/libvpx.c| 47 +++-
>>  libavcodec/libvpxenc.c | 85 
>> --
>>  2 files changed, 129 insertions(+), 3 deletions(-)
>>
>
> lgtm.
>

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Claudio Freire]

On Mon, Apr 20, 2015 at 7:18 PM, Andreas Cadhalpun
 wrote:
> On 20.04.2015 22:15, Claudio Freire wrote:
>> TL;DR, band->thr should not be negative ever, band->thr == 0.0f would
>> cause lots of issues on its own if band->energy != 0.0f in such a case
>> (though I don't see how band->thr can be 0.0f if band->energy is not),
>
> This could happen in pathological cases:
> band->energy = 1e-37f
> band->thr= band->energy * 0.001258925f = 0.0f

That's an unhappy situation, but I don't see a fix for it (in theory,
band->thr = FFMAX(FLT_EPSILON, band->energy * ...), but that's quite
fragile).


>
>> The long version:
>>
>> ath should approximate the shape of the absolute hearing threshold, so
>> yes, it's best if it really uses the minimum, since that will prevent
>> clipping of the ath curve and result in a more accurate threshold
>> computation.
>
> So you agree with my patch fixing minath?
> Or would you prefer a version with:
> minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)

Well, that's not really closer to the minimum (a few tests with gnuplot say).

But yeah, something that makes it closer, sure.

I'd try to symbollicaly deriving the minimum if you really mean to
improve that (should be doable, it's all differentiable stuff).
Otherwise, handling the division by zero closer to where it happens is
probably easier to do properly.

>> But it's hard to enforce that
>> without clipping it, and it's not worth the trouble attempting it.
>
> Why would clipping be a problem?

It would flatten the masking floor around the part where it matters
most (the surroundings of the minimum).

Still, we're talking about extremely faint signals, so it's still a
very edgy case.

> What about the attached patch?

It's no guarantee. Math can still push that into zero. It's better to
handle the underflow where it matters (ie: where the division by ath
or thr happen, as in the previous patches).

>
>> I don't believe accurate computation of ath to that point would improve
>> encoding that much. Any reasonable approximation will do.
>
> It's more about avoiding nasty problems with division by 0.

Agreed.

Thus, I favor handling it where the division is attempted.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] webmdashenc: Fix potential memory leak

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 11:20:41AM -0700, Vignesh Venkatasubramanian wrote:
> Fix potential memory leak in WebM DASH Muxer. This fixes coverity
> scan CID 1295088.
> 
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  libavformat/webmdashenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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/mp3dec: Adjust returned timestamp in the CBR seeking case

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 09:47:33PM +0200, wm4 wrote:
> On Mon, 20 Apr 2015 21:25:44 +0200
> Michael Niedermayer  wrote:
> 
> > With this the returned timestamp should match the packet instead of
> > the requested timestamp, which may lay between  packets
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mp3dec.c |6 ++
> >  tests/ref/fate/gapless-mp3-notoc |2 +-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 06bc1d0..89990ec 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -489,6 +489,12 @@ static int mp3_seek(AVFormatContext *s, int 
> > stream_index, int64_t timestamp,
> >  ret = avio_seek(s->pb, best_pos, SEEK_SET);
> >  if (ret < 0)
> >  return ret;
> > +
> > +if (mp3->is_cbr && ie == &ie1) {
> > +int frame_duration = av_rescale(st->duration, 1, mp3->frames);
> 
> Why use av_rescale here? Shouldn't a normal division work fine?

i was thinking that if duration is slightly wrong then av_rescale
would be more robust as its rounding to nearest


> 
> > +ie1.timestamp = frame_duration * (av_rescale(best_pos - 
> > s->internal->data_offset, mp3->frames, mp3->header_filesize));
> 
> Redundant (  ) ?

yes, ill remove it

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Andreas Cadhalpun]

On 21.04.2015 01:13, Claudio Freire wrote:
> On Mon, Apr 20, 2015 at 7:18 PM, Andreas Cadhalpun
>  wrote:
>> On 20.04.2015 22:15, Claudio Freire wrote:
>>> TL;DR, band->thr should not be negative ever, band->thr == 0.0f would
>>> cause lots of issues on its own if band->energy != 0.0f in such a case
>>> (though I don't see how band->thr can be 0.0f if band->energy is not),
>>
>> This could happen in pathological cases:
>> band->energy = 1e-37f
>> band->thr= band->energy * 0.001258925f = 0.0f
> 
> That's an unhappy situation, but I don't see a fix for it (in theory,
> band->thr = FFMAX(FLT_EPSILON, band->energy * ...), but that's quite
> fragile).

Yeah, that's rather ugly and FLT_EPSILON isn't really a good minimum anyway.

>>> The long version:
>>>
>>> ath should approximate the shape of the absolute hearing threshold, so
>>> yes, it's best if it really uses the minimum, since that will prevent
>>> clipping of the ath curve and result in a more accurate threshold
>>> computation.
>>
>> So you agree with my patch fixing minath?
>> Or would you prefer a version with:
>> minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)
> 
> Well, that's not really closer to the minimum (a few tests with gnuplot say).

Are you sure your plots were done correctly?
Because I'm quite sure this is the correct first order approximation
of the minimum.

For ATH_ADD = 4 this gives 3407.068, which is quite close to Michael's value
(3407.080774800152).

> But yeah, something that makes it closer, sure.
> 
> I'd try to symbollicaly deriving the minimum if you really mean to
> improve that (should be doable, it's all differentiable stuff).

I actually derived the dependency of the minimum on ATH_ADD in first
order around ATH_ADD = 0 (using sagemath).

> Otherwise, handling the division by zero closer to where it happens is
> probably easier to do properly.

OK.

>>> But it's hard to enforce that
>>> without clipping it, and it's not worth the trouble attempting it.
>>
>> Why would clipping be a problem?
> 
> It would flatten the masking floor around the part where it matters
> most (the surroundings of the minimum).
> 
> Still, we're talking about extremely faint signals, so it's still a
> very edgy case.

I see.

>> What about the attached patch?
> 
> It's no guarantee. Math can still push that into zero. It's better to
> handle the underflow where it matters (ie: where the division by ath
> or thr happen, as in the previous patches).
> 
>>
>>> I don't believe accurate computation of ath to that point would improve
>>> encoding that much. Any reasonable approximation will do.
>>
>> It's more about avoiding nasty problems with division by 0.
> 
> Agreed.
> 
> Thus, I favor handling it where the division is attempted.

OK, than let's keep doing that.

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Claudio Freire]

On Mon, Apr 20, 2015 at 8:32 PM, Andreas Cadhalpun
 wrote:
 The long version:

 ath should approximate the shape of the absolute hearing threshold, so
 yes, it's best if it really uses the minimum, since that will prevent
 clipping of the ath curve and result in a more accurate threshold
 computation.
>>>
>>> So you agree with my patch fixing minath?
>>> Or would you prefer a version with:
>>> minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)
>>
>> Well, that's not really closer to the minimum (a few tests with gnuplot say).
>
> Are you sure your plots were done correctly?
> Because I'm quite sure this is the correct first order approximation
> of the minimum.
>
> For ATH_ADD = 4 this gives 3407.068, which is quite close to Michael's value
> (3407.080774800152).

I checked the formula several times, but still, I could have made a mistake.

>
>> But yeah, something that makes it closer, sure.
>>
>> I'd try to symbollicaly deriving the minimum if you really mean to
>> improve that (should be doable, it's all differentiable stuff).
>
> I actually derived the dependency of the minimum on ATH_ADD in first
> order around ATH_ADD = 0 (using sagemath).

ATH_ADD is defined as 4, that may make a significant difference
(changes a high-order term).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: Adjust returned timestamp in the CBR seeking case

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 09:54:22PM +0200, wm4 wrote:
> On Mon, 20 Apr 2015 21:25:44 +0200
> Michael Niedermayer  wrote:
> 
> > With this the returned timestamp should match the packet instead of
> > the requested timestamp, which may lay between  packets
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mp3dec.c |6 ++
> >  tests/ref/fate/gapless-mp3-notoc |2 +-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 06bc1d0..89990ec 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -489,6 +489,12 @@ static int mp3_seek(AVFormatContext *s, int 
> > stream_index, int64_t timestamp,
> >  ret = avio_seek(s->pb, best_pos, SEEK_SET);
> >  if (ret < 0)
> >  return ret;
> > +
> > +if (mp3->is_cbr && ie == &ie1) {
> > +int frame_duration = av_rescale(st->duration, 1, mp3->frames);
> > +ie1.timestamp = frame_duration * (av_rescale(best_pos - 
> > s->internal->data_offset, mp3->frames, mp3->header_filesize));
> > +}
> > +
> >  ff_update_cur_dts(s, st, ie->timestamp);
> >  st->skip_samples = ie->timestamp <= 0 ? mp3->start_pad + 528 + 1 : 0;
> >  return 0;
> > diff --git a/tests/ref/fate/gapless-mp3-notoc 
> > b/tests/ref/fate/gapless-mp3-notoc
> > index f52efff..936d0ba 100644
> > --- a/tests/ref/fate/gapless-mp3-notoc
> > +++ b/tests/ref/fate/gapless-mp3-notoc
> > @@ -2,4 +2,4 @@ d5c88cf38416329a052a9b0cb140fb4c 
> > *tests/data/fate/gapless-mp3-notoc.out-1
> >  c96c3ae7bd3300fd2f4debac222de5b7
> >  3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3-notoc.out-2
> >  c96c3ae7bd3300fd2f4debac222de5b7
> > -e82eaed507ce3f7f6199918159e1ddd7 *tests/data/fate/gapless-mp3-notoc.out-3
> > +92e37f050ad4fc817730c8af17ee6d1b *tests/data/fate/gapless-mp3-notoc.out-3
> 
> I checked myself, and the output looks and sounds potentially good.
> (But I'm rather bad at spotting the "gap".) So I'd suggest applying
> this.

ok, applied

thanks

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Claudio Freire]

On Mon, Apr 20, 2015 at 8:59 PM, Claudio Freire  wrote:
> On Mon, Apr 20, 2015 at 8:32 PM, Andreas Cadhalpun
>  wrote:
> The long version:
>
> ath should approximate the shape of the absolute hearing threshold, so
> yes, it's best if it really uses the minimum, since that will prevent
> clipping of the ath curve and result in a more accurate threshold
> computation.

 So you agree with my patch fixing minath?
 Or would you prefer a version with:
 minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)
>>>
>>> Well, that's not really closer to the minimum (a few tests with gnuplot 
>>> say).
>>
>> Are you sure your plots were done correctly?
>> Because I'm quite sure this is the correct first order approximation
>> of the minimum.
>>
>> For ATH_ADD = 4 this gives 3407.068, which is quite close to Michael's value
>> (3407.080774800152).
>
> I checked the formula several times, but still, I could have made a mistake.


This is what I did if you want to check it out (maybe you spot the mistake)

gnuplot> ath(f,a) = _ath(f/1000.0, a)
gnuplot> _ath(f,a) = 3.64 * f**(-0.8) - 6.8 * exp(-0.6 * (f-3.4) *
(f-3.4)) + 6.0 * exp(-0.15 * (f-8.7) * (f-8.7)) + (0.6 + 0.04 * a) *
0.001 * f * f * f
gnuplot> plot [f=3400:3500] ath(f,4), ath(3410-0.733*4, 4)

Funny thing, is it's much closer with:

gnuplot> plot [f=3400:3500] ath(f,4), ath(3410+0.733*4, 4)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 09:07:14PM -0300, Claudio Freire wrote:
> On Mon, Apr 20, 2015 at 8:59 PM, Claudio Freire  
> wrote:
> > On Mon, Apr 20, 2015 at 8:32 PM, Andreas Cadhalpun
> >  wrote:
> > The long version:
> >
> > ath should approximate the shape of the absolute hearing threshold, so
> > yes, it's best if it really uses the minimum, since that will prevent
> > clipping of the ath curve and result in a more accurate threshold
> > computation.
> 
>  So you agree with my patch fixing minath?
>  Or would you prefer a version with:
>  minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)
> >>>
> >>> Well, that's not really closer to the minimum (a few tests with gnuplot 
> >>> say).
> >>
> >> Are you sure your plots were done correctly?
> >> Because I'm quite sure this is the correct first order approximation
> >> of the minimum.
> >>
> >> For ATH_ADD = 4 this gives 3407.068, which is quite close to Michael's 
> >> value
> >> (3407.080774800152).
> >
> > I checked the formula several times, but still, I could have made a mistake.
> 
> 
> This is what I did if you want to check it out (maybe you spot the mistake)
> 
> gnuplot> ath(f,a) = _ath(f/1000.0, a)
> gnuplot> _ath(f,a) = 3.64 * f**(-0.8) - 6.8 * exp(-0.6 * (f-3.4) *
> (f-3.4)) + 6.0 * exp(-0.15 * (f-8.7) * (f-8.7)) + (0.6 + 0.04 * a) *
> 0.001 * f * f * f
  ^^
missing * f

also IIRC gnuplot is just double precission
depending on how many decimal places one wants to calculate this can
become a limitation

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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 1/2] avformat/nsvdec: remove trace log from probe(), this is better done generically not per format

[Michael Niedermayer]

On Mon, Apr 20, 2015 at 09:32:15PM +0200, Paul B Mahol wrote:
> Dana 20. 4. 2015. 17:39 osoba "Michael Niedermayer" 
> napisala je:
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/nsvdec.c |1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/libavformat/nsvdec.c b/libavformat/nsvdec.c
> > index 5002bd7..de55396 100644
> > --- a/libavformat/nsvdec.c
> > +++ b/libavformat/nsvdec.c
> > @@ -723,7 +723,6 @@ static int nsv_probe(AVProbeData *p)
> >  {
> >  int i, score = 0;
> >
> > -av_log(NULL, AV_LOG_TRACE, "nsv_probe(), buf_size %d\n",
> p->buf_size);
> >  /* check file header */
> >  /* streamed files might not have any header */
> >  if (p->buf[0] == 'N' && p->buf[1] == 'S' &&
> > --
> > 1.7.9.5
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> LGTM

applied

thanks

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Claudio Freire]

On Mon, Apr 20, 2015 at 9:13 PM, Michael Niedermayer  wrote:
> On Mon, Apr 20, 2015 at 09:07:14PM -0300, Claudio Freire wrote:
>> On Mon, Apr 20, 2015 at 8:59 PM, Claudio Freire  
>> wrote:
>> > On Mon, Apr 20, 2015 at 8:32 PM, Andreas Cadhalpun
>> >  wrote:
>> > The long version:
>> >
>> > ath should approximate the shape of the absolute hearing threshold, so
>> > yes, it's best if it really uses the minimum, since that will prevent
>> > clipping of the ath curve and result in a more accurate threshold
>> > computation.
>> 
>>  So you agree with my patch fixing minath?
>>  Or would you prefer a version with:
>>  minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)
>> >>>
>> >>> Well, that's not really closer to the minimum (a few tests with gnuplot 
>> >>> say).
>> >>
>> >> Are you sure your plots were done correctly?
>> >> Because I'm quite sure this is the correct first order approximation
>> >> of the minimum.
>> >>
>> >> For ATH_ADD = 4 this gives 3407.068, which is quite close to Michael's 
>> >> value
>> >> (3407.080774800152).
>> >
>> > I checked the formula several times, but still, I could have made a 
>> > mistake.
>>
>>
>> This is what I did if you want to check it out (maybe you spot the mistake)
>>
>> gnuplot> ath(f,a) = _ath(f/1000.0, a)
>> gnuplot> _ath(f,a) = 3.64 * f**(-0.8) - 6.8 * exp(-0.6 * (f-3.4) *
>> (f-3.4)) + 6.0 * exp(-0.15 * (f-8.7) * (f-8.7)) + (0.6 + 0.04 * a) *
>> 0.001 * f * f * f
>   ^^
> missing * f

Much better now :)

So yes. I'd say it's a good change.

>
> also IIRC gnuplot is just double precission
> depending on how many decimal places one wants to calculate this can
> become a limitation

aacpsy.c is single precision or double or long double depending on the
architecture.

Certainly if numeric precision is an issue it'd be better to
precompute the table and just put it as a constant in aactab.c.

I don't think it's necessary though. It'd be hard to maintain.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] oggparsedirac: check return value of init_get_bits

[Clément Bœsch]

On Mon, Apr 20, 2015 at 02:29:54PM -0700, Christopher Watkins wrote:
> 

> From a93fa19467ac2568cfe32332b789b315e37dbdf1 Mon Sep 17 00:00:00 2001
> From: Chris Watkins 
> Date: Mon, 20 Apr 2015 14:23:57 -0700
> Subject: [PATCH] oggparsedirac: check return value of init_get_bits
> 
> If init_get_bits fails the GetBitContext is invalid and must not be
> used. Check the return value in dirac_header and propogate the error.
> 
> Signed-off-by: Chris Watkins 
> ---
>  libavformat/oggparsedirac.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/oggparsedirac.c b/libavformat/oggparsedirac.c
> index 10fb07e..35be655 100644
> --- a/libavformat/oggparsedirac.c
> +++ b/libavformat/oggparsedirac.c
> @@ -36,7 +36,9 @@ static int dirac_header(AVFormatContext *s, int idx)
>  if (st->codec->codec_id == AV_CODEC_ID_DIRAC)
>  return 0;
>  
> -init_get_bits(&gb, os->buf + os->pstart + 13, (os->psize - 13) * 8);
> +if (init_get_bits(&gb, os->buf + os->pstart + 13, (os->psize - 13) * 8) 
> < 0)
> +return -1;

int ret;
// ...
ret = init_get_bits(...);
if (ret < 0)
  return ret;

You can also use init_get_bits8() while at it


-- 
Clément B.


pgpdUcQxdsvmj.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_colorkey: Add colorkey video filter

[Clément Bœsch]

On Sun, Apr 19, 2015 at 06:15:48PM +0200, Timo Rothenpieler wrote:
> ---
>  Changelog |   1 +
>  MAINTAINERS   |   1 +
>  doc/filters.texi  |  39 
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_colorkey.c | 226 
> ++
>  6 files changed, 269 insertions(+)
>  create mode 100644 libavfilter/vf_colorkey.c
> 
> diff --git a/Changelog b/Changelog
> index 2e30b24..e99d1e9 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -17,6 +17,7 @@ version :
>  - WebM Live Chunk Muxer
>  - nvenc level and tier options
>  - chorus filter
> +- colorkey video filter
>  
>  
>  version 2.6:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 598c0b3..18f6ba3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -352,6 +352,7 @@ Filters:
>avf_showcqt.c Muhammad Faiz
>vf_blend.cPaul B Mahol
>vf_colorbalance.c Paul B Mahol
> +  vf_colorkey.c Timo Rothenpieler
>vf_dejudder.c Nicholas Robbins
>vf_delogo.c   Jean Delvare (CC 
> )
>vf_drawbox.c/drawgrid Andrey Utkin
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 0f2e720..79c0753 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -3026,6 +3026,45 @@ colorbalance=rs=.3
>  @end example
>  @end itemize
>  
> +@section colorkey
> +RGB colorspace color keying.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item color
> +The color which will be replaced with transparency.
> +
> +@item similarity
> +Similarity percentage with the key color.
> +
> +0.01 matches only the exact key color, while 1.0 matches everything.
> +

This should probably be a "threshold" option.

> +@item blend
> +Blend percentage.
> +
> +0.0 makes pixels either fully transparent, or not transparent at all.
> +
> +Higher values result in semi-transparent pixels, with a higher transparency
> +the more similar the pixels color is to the key color.
> +@end table
> +

Shouldn't this blending be different near cutting zones (to smooth a bit
the overlay)?

We will also probably want some kind of greedy mode to enlarge the
selection, and options such as ignore very small zones (to avoid random
glitches). But anyway, this can obviously come later.

> +@subsection Examples
> +
> +@itemize
> +@item
> +Make every green pixel in the input image transparent:
> +@example
> +ffmpeg -i input.png -vf colorkey=green out.png
> +@end example
> +
> +@item
> +Make every red pixel in the input image transparent, with a high similarity 
> tolerance:
> +@example
> +ffmpeg -i input.png -vf colorkey=0xFF:0.3 out.png
> +@end example
> +@end itemize
> +

I suppose the main usage is to overlay the patchwork onto some other
video, so maybe a complete example with an overlay filter might make
sense.

>  @section colorlevels
>  
>  Adjust video input frames using levels.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 48cee50..60e6b52 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -102,6 +102,7 @@ OBJS-$(CONFIG_BOXBLUR_FILTER)+= 
> vf_boxblur.o
>  OBJS-$(CONFIG_CODECVIEW_FILTER)  += vf_codecview.o
>  OBJS-$(CONFIG_COLORBALANCE_FILTER)   += vf_colorbalance.o
>  OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER)  += vf_colorchannelmixer.o
> +OBJS-$(CONFIG_COLORKEY_FILTER)   += vf_colorkey.o
>  OBJS-$(CONFIG_COLORLEVELS_FILTER)+= vf_colorlevels.o
>  OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
>  OBJS-$(CONFIG_COPY_FILTER)   += vf_copy.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 7961dca..2eeec7f 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -118,6 +118,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(CODECVIEW,  codecview,  vf);
>  REGISTER_FILTER(COLORBALANCE,   colorbalance,   vf);
>  REGISTER_FILTER(COLORCHANNELMIXER, colorchannelmixer, vf);
> +REGISTER_FILTER(COLORKEY,   colorkey,   vf);
>  REGISTER_FILTER(COLORLEVELS,colorlevels,vf);
>  REGISTER_FILTER(COLORMATRIX,colormatrix,vf);
>  REGISTER_FILTER(COPY,   copy,   vf);
> diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
> new file mode 100644
> index 000..b5180cf
> --- /dev/null
> +++ b/libavfilter/vf_colorkey.c
> @@ -0,0 +1,226 @@
> +/*
> + * Copyright (c) 2015 Timo Rothenpieler 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be u

Re: [FFmpeg-devel] youtube patches

[Clément Bœsch]

On Wed, Apr 08, 2015 at 07:15:51PM +0200, Gilles Chanteperdrix wrote:
> Enough talking, here are some patches, and I will let the
> maintainers decide. 
> 
> On the libquvi side, the first patch cleans up the error handling in
> the libquvi_read_header function to avoid calling libquvi cleanup
> functions on uninitialized variables. The second patch adds a call
> to avformat_find_stream_info for the inner format context so as to
> be able to fill the start_time, duration and bit_rate of the outer
> format context.
> 
> On the youtube-dl side, a patch adds support for a youtube-dl based
> demuxer, which is functionally equivalent to libquvi, except that it
> supports all the sites supported by youtube-dl. I avoided using
> popen on purpose, so as to try and be as much cross-platform as
> possible, though the av_tempfile function returns a file descriptor,
> so, probably requires UNIX or POSIX anyway.
> 
> In my opinion, it does not make sense to maintain both solutions.
> 
> Regards.
> 

Alright, so first, I'd like to say I'm sorry to be somehow the cause of
the drama, being the original author of the libquvi demuxer...

At some point, I even stopped using it: it was originally written for the
0.4 (stable) serie, but then my distro upgraded it to 0.9 (unstable),
dropping the 0.4 version. I don't remember if the API changed much, but
one major change was about the license: it changed from LGPL to AGPL. I
wasn't exactly so sure about what legal implication that had for our build
so I just ignored the issue for a long time. And when I decided to long
back at it, libquvi wasn't maintained anymore.

So anyway, it would probably make sense to just drop libquvi support IMO.
I don't consider myself a maintainer of this demuxer anymore, so feel free
to send it back to hell.

Now indeed there might be no alternative to this currently, as far as I
understood from the youtube-dl discussions. If someone is working on an
(real) API on youtube-dl side, something similar to libquvi might be nice.
Oh an while I'm at it, a fast and good probe function on that API would be
very welcome (just a matching of the URL, no request made or such).

And finally, I'm still very much opposed to maintain our C version of
these websites on FFmpeg side, as well as exec, system & friends calls to
youtube-dl. If someone wants to do some heresy like that, he's free to do
it outside the project (even if it's hidden in the official youtube-dl
API).

Anyway, sorry about digging up this dead flame, but I'm now back in the
game :)

-- 
Clément B.


pgpR0zvTNDpDb.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] libavcodec: Add FLAC API test

[Clément Bœsch]

On Mon, Apr 20, 2015 at 02:37:27PM +0200, Ludmila Glinskih wrote:
> ffmpeg | branch: master | Ludmila Glinskih  | Mon Apr 20 
> 03:03:08 2015 +0300| [be70c79af2bbbf8818707075ebc376d0be137582] | committer: 
> Michael Niedermayer
> 
> libavcodec: Add FLAC API test
> 
> Signed-off-by: Ludmila Glinskih 
> Signed-off-by: Michael Niedermayer 
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=be70c79af2bbbf8818707075ebc376d0be137582
> ---
> 
>  libavcodec/Makefile|1 +
>  libavcodec/api-flac-test.c |  290 
> 
>  tests/fate/libavcodec.mak  |6 +
>  3 files changed, 297 insertions(+)
> 
[...]

> +TESTPROGS += api-flac

Mmh... no TESTPROGRES-$(CONFIG_FLAC_DECODER) or similar?

[...]
> +if (!ctx)
> +{

Sorry to comment on such superficial issue, but this style (repeated all
over the file) is an obvious violation of the coding style of the project.
If the author or the person pushing the patch could fix this, that would
be appreciated.

Thanks

[...]

-- 
Clément B.


pgpjeSe2cjV5E.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] refactored srtdec

[Clément Bœsch]

On Fri, Apr 10, 2015 at 04:14:59AM -0300, James Almer wrote:
[...]
> IMO all this belongs in ass.c/h instead of two new files.

Not really, it's about parsing "html"-like markup. The fact that it's
generating ASS is accessory. It could be something else (if the internal
representation of decoded text sub wasn't ASS typically, which could
happen in the future). The complex logic really is about parsing that
markup, I believe it belongs in this separate file.

-- 
Clément B.


pgpm20y2uxjmv.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4] libavcodec: Add FLAC API test

[James Almer]

On 19/04/15 9:03 PM, Ludmila Glinskih wrote:

> +static int run_test(AVCodec *enc, AVCodec *dec, AVCodecContext *enc_ctx,
> +AVCodecContext *dec_ctx)
> +{
> +AVPacket enc_pkt;
> +AVFrame *in_frame, *out_frame;
> +uint8_t *raw_in = NULL, *raw_out = NULL;
> +int in_offset = 0, out_offset = 0;
> +int frame_data_size = 0;

This

[...]

> +if (memcmp(raw_in, raw_out, frame_data_size * NUMBER_OF_FRAMES) != 0)

And this are the only lines where frame_data_size is used. This means it's 
always 0.
Is that intended? Because unless i'm missing something, that doesn't seem right 
for 
a memcmp.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] alsdec: validate time diff index

[Thilo Borgmann]

Am 20.04.15 um 23:20 schrieb Andreas Cadhalpun:
> On 19.04.2015 22:20, Luca Barbato wrote:
>> On 18/04/15 18:58, Andreas Cadhalpun wrote:
>>> If begin is smaller than t, the subtraction 'begin -= t' wraps around,
>>> because begin is unsigned. The same applies for end < t.
>>>
>>> This causes segmentation faults.
>>
>> Actually, the access to raw_buffer seems a bit optimistic all over this
>> code.
>>
>> I'd check that `master` is always between `raw_buffer` and the end of it.
> 
> You mean something like the attached patch?
> 
>> (I'm not sure if `div_blocks` is validated before, same for `offset`)
> 
> That should catch problems in those as well.

Have you tested with fate after applying this patch locally?

-Thilo

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