Re: [FFmpeg-devel] [PATCH][RFC][WIP] lavf/ramdec: RAM demuxer

[wm4]

On Sun, 3 Jan 2016 21:59:21 +0100
Hendrik Leppkes  wrote:

> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
>  wrote:
> > This is a WIP patch for the RAM playlist format:
> > http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
> > http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm.
> >
> > The implementation is currently essentially a kitchen sink dump of
> > concatdec; hence the copyright notice is preserved.
> >
> > Metadata stuff is currently lacking. Feedback appreciated; this is my
> > first demuxer.
> >
> > Done some very simple, basic testing.
> >  
> 
> Playlists "intentionally" don't have demuxers, as they should probably
> be handled in a more generic top-level way. As you said, this is
> basically concatdec with parsing, which every playlist demuxer would
> likely end up being.
> Unfortunately, noone has yet finished any such API to handle this
> properly, hence no playlist support in FFmpeg yet.

Cancatenating all playlist entries? That seems very strange.

I remember a branch in Libav which attempted to export playlists via
API, but work on it has stopped.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Michael Niedermayer]

On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> This gets rid of some branches to speed up table generation slightly
> (impact higher on mulaw than alaw). Tables are identical to before,
> tested with FATE.
> 
> Sample benchmark (Haswell, GNU/Linux+gcc):
> old:
>  313494 decicycles in build_alaw_table,4094 runs,  2 skips
>  315959 decicycles in build_alaw_table,8190 runs,  2 skips
> 
>  323599 decicycles in build_ulaw_table,4095 runs,  1 skips
>  318849 decicycles in build_ulaw_table,8188 runs,  4 skips
> 
> new:
>  261902 decicycles in build_alaw_table,4096 runs,  0 skips
>  266519 decicycles in build_alaw_table,8192 runs,  0 skips
> 
>  209657 decicycles in build_ulaw_table,4096 runs,  0 skips
>  232656 decicycles in build_ulaw_table,8192 runs,  0 skips
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/pcm_tablegen.h | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/pcm_tablegen.h b/libavcodec/pcm_tablegen.h
> index 1387210..7269977 100644
> --- a/libavcodec/pcm_tablegen.h
> +++ b/libavcodec/pcm_tablegen.h
> @@ -87,21 +87,21 @@ static av_cold void build_xlaw_table(uint8_t 
> *linear_to_xlaw,
>  {
>  int i, j, v, v1, v2;
>  
> -j = 0;
> -for(i=0;i<128;i++) {
> -if (i != 127) {
> -v1 = xlaw2linear(i ^ mask);
> -v2 = xlaw2linear((i + 1) ^ mask);
> -v = (v1 + v2 + 4) >> 3;
> -} else {
> -v = 8192;
> -}
> -for(;j +j = 1;
> +linear_to_xlaw[8192] = mask;
> +for(i=0;i<127;i++) {
> +v1 = xlaw2linear(i ^ mask);
> +v2 = xlaw2linear((i + 1) ^ mask);
> +v = (v1 + v2 + 4) >> 3;
> +for(;j +linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>  linear_to_xlaw[8192 + j] = (i ^ mask);
> -if (j > 0)
> -linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>  }
>  }
> +for(;j<8192;j++) {
> +linear_to_xlaw[8192 - j] = (127 ^ (mask ^ 0x80));
> +linear_to_xlaw[8192 + j] = (127 ^ mask);
> +}
>  linear_to_xlaw[0] = linear_to_xlaw[1];

i think you can make the tables 8 times smaller
the points in the table where values transition seemed to be always
a multiple of 8 appart so just adjusting the offset in
pcm_encode_frame() would allow decreasing the >> 2 to >> 5

if that works out it would make the table generation 8 times faster
reduce memory needed and speed up the code runtime due to lower
pressure on L1/L2 caches


[...]
-- 
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][RFC][WIP] lavf/ramdec: RAM demuxer

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 1:05 PM, wm4  wrote:
> On Sun, 3 Jan 2016 21:59:21 +0100
> Hendrik Leppkes  wrote:
>
>> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
>>  wrote:
>> > This is a WIP patch for the RAM playlist format:
>> > http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
>> > http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm.
>> >
>> > The implementation is currently essentially a kitchen sink dump of
>> > concatdec; hence the copyright notice is preserved.
>> >
>> > Metadata stuff is currently lacking. Feedback appreciated; this is my
>> > first demuxer.
>> >
>> > Done some very simple, basic testing.
>> >
>>
>> Playlists "intentionally" don't have demuxers, as they should probably
>> be handled in a more generic top-level way. As you said, this is
>> basically concatdec with parsing, which every playlist demuxer would
>> likely end up being.
>> Unfortunately, noone has yet finished any such API to handle this
>> properly, hence no playlist support in FFmpeg yet.
>
> Cancatenating all playlist entries? That seems very strange.

Am curious: isn't that what playlists are generally speaking?

>
> I remember a branch in Libav which attempted to export playlists via
> API, but work on it has stopped.
> ___
> 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][RFC][WIP] lavf/ramdec: RAM demuxer

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 12:59 PM, Hendrik Leppkes  wrote:
> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
>  wrote:
>> This is a WIP patch for the RAM playlist format:
>> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
>> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm.
>>
>> The implementation is currently essentially a kitchen sink dump of
>> concatdec; hence the copyright notice is preserved.
>>
>> Metadata stuff is currently lacking. Feedback appreciated; this is my
>> first demuxer.
>>
>> Done some very simple, basic testing.
>>
>
> Playlists "intentionally" don't have demuxers, as they should probably
> be handled in a more generic top-level way. As you said, this is
> basically concatdec with parsing, which every playlist demuxer would
> likely end up being.
> Unfortunately, noone has yet finished any such API to handle this
> properly, hence no playlist support in FFmpeg yet.

I get a sense that it is tedious, annoying, and with little benefit:
for a power user, they have zero benefit as one can simply use concat
and/or script a converter to the concat format. For a normal user,
downstream clients anyway handle playlists.

Patch dropped; thanks.

>
>
> - 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] avcodec: Remove libstagefright

[Martin Storsjö]

On Sun, 3 Jan 2016, Derek Buitenhuis wrote:


It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. Both stagefright itself, and MediaCodec, have
avcodec backends already, and this is the correct way to use it.


No, that's unrelated. Yes, people have written avcodec backends for 
stagefright/MediaCodec, but that's unrelated and only of interest for 
stock Android mediaplayers to extend their codec support.



MediaCodec as a proper JNI API.


wat? (Yes, using MediaCodec, either via the recent C API, or via JNI, is 
the correct way to do it.)



Furthermore, stagefright support in avcodec needs a series of
magic incantations and version-specific stuff, such that
using it actually provides downsides compared just using the actual
Android frameworks properly, in that it is a lot more work and confusion
to get it even running. It also leads to a lot of misinformation, like
these sorts of comments (in [1]) that are absolutely incorrect.


Spot on, +1.


[1] http://stackoverflow.com/a/29362353/3115956

Signed-off-by: Derek Buitenhuis 
---
I am certain there are many more reasons to remvoe this as well. I know
its own author despises it, and I know j-b will same things to say.


Not direct author, but co-author/mentor.

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

Re: [FFmpeg-devel] [PATCH 1/3] common: add ff_parity()

[Clément Bœsch]

On Sun, Jan 03, 2016 at 05:56:41PM -0300, James Almer wrote:
[...]
> >> +static av_always_inline av_const int ff_parity(uint32_t v)
> >> +{
> >> +#if HAVE_PARITY
> >> +return __builtin_parity(v);
> >> +#else
> >> +return av_popcount(v) & 1;
> >> +#endif
> > 
> > Do compilers really generate better code for the former?
> 
> GCC does on x86 when the target cpu doesn't support the popcnt instruction,
> otherwise the end result would be the same (popcnt + and).
> av_popcount_c() is not optimal for this.
> 

For the record, this is what it looks like here (GCC 5.3.0, clang 3.7.0,
i5-5250U):

[/tmp]☭ cat a.c
#include 

int parity0(uint32_t x) { return __builtin_popcount(x) & 1; }
int parity1(uint32_t x) { return __builtin_parity(x); }
[/tmp]☭ gcc -O2 -c a.c && objdump -r -d -Mintel a.o

a.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   48 83 ec 08 subrsp,0x8
   4:   89 ff   movedi,edi
   6:   e8 00 00 00 00  call   b 
7: R_X86_64_PC32__popcountdi2-0x4
   b:   48 83 c4 08 addrsp,0x8
   f:   83 e0 01andeax,0x1
  12:   c3  ret
  13:   0f 1f 00nopDWORD PTR [rax]
  16:   66 2e 0f 1f 84 00 00nopWORD PTR cs:[rax+rax*1+0x0]
  1d:   00 00 00 

0020 :
  20:   89 f8   moveax,edi
  22:   c1 ef 10shredi,0x10
  25:   31 f8   xoreax,edi
  27:   30 e0   xoral,ah
  29:   0f 9b c0setnp  al
  2c:   0f b6 c0movzx  eax,al
  2f:   c3  ret
[/tmp]☭ clang -O2 -c a.c && objdump -r -d -Mintel a.o

a.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   89 f8   moveax,edi
   2:   d1 e8   shreax,1
   4:   25 55 55 55 55  andeax,0x
   9:   29 c7   subedi,eax
   b:   89 f8   moveax,edi
   d:   25 33 33 33 33  andeax,0x
  12:   c1 ef 02shredi,0x2
  15:   81 e7 33 33 33 33   andedi,0x
  1b:   01 c7   addedi,eax
  1d:   89 f8   moveax,edi
  1f:   c1 e8 04shreax,0x4
  22:   01 f8   addeax,edi
  24:   25 0f 0f 0f 01  andeax,0x10f0f0f
  29:   69 c0 01 01 01 01   imul   eax,eax,0x1010101
  2f:   c1 e8 18shreax,0x18
  32:   83 e0 01andeax,0x1
  35:   c3  ret
  36:   66 2e 0f 1f 84 00 00nopWORD PTR cs:[rax+rax*1+0x0]
  3d:   00 00 00 

0040 :
  40:   89 f8   moveax,edi
  42:   d1 e8   shreax,1
  44:   25 55 55 55 55  andeax,0x
  49:   29 c7   subedi,eax
  4b:   89 f8   moveax,edi
  4d:   25 33 33 33 33  andeax,0x
  52:   c1 ef 02shredi,0x2
  55:   81 e7 33 33 33 33   andedi,0x
  5b:   01 c7   addedi,eax
  5d:   89 f8   moveax,edi
  5f:   c1 e8 04shreax,0x4
  62:   01 f8   addeax,edi
  64:   25 0f 0f 0f 01  andeax,0x10f0f0f
  69:   69 c0 01 01 01 01   imul   eax,eax,0x1010101
  6f:   c1 e8 18shreax,0x18
  72:   83 e0 01andeax,0x1
  75:   c3  ret
[/tmp]☭ 

Conclusion: with GCC it matters, not so much with Clang.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> Ganesh Ajjanagadde  mit.edu> writes:
> 
> > No one has told me what is interesting
> 
> Did you look at tickets #4441 or #4085?

Or ticket #4829 or a j2k issue?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] rtmpdh: Initialize gcrypt before using it

[Ricardo Constantino]

On 3 January 2016 at 23:13, Jan Ekstrom  wrote:

> Hi,
>
> In general looks good, although it might look a bit weird for someone
> as usually libraries have initialization functions called like that.
> That said, this is what
>
> https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html
> recommends.
>
> My only comment would be that we might want to set the parameter to
> GCRYPT_VERSION instead of NULL, as we most probably care if the
> library loaded matches our version (unless these versions change even
> if API doesn't change).
>

This is where it shows my ignorance but I don't know which of these is the
best way of dealing with that.
I tested all three and they all work with the linked sample.


0001-rtmpdh-Initialize-gcrypt-before-using-it-v1.patch
Description: Binary data


0001-rtmpdh-Initialize-gcrypt-before-using-it-v2.patch
Description: Binary data


0001-rtmpdh-Initialize-gcrypt-before-using-it-v3.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] common: add ff_parity()

[wm4]

On Sun,  3 Jan 2016 20:21:00 +0100
Clément Bœsch  wrote:

> ---
>  configure   | 2 ++
>  libavutil/x86/intmath.h | 9 +
>  2 files changed, 11 insertions(+)
> 
> diff --git a/configure b/configure
> index 6710f85..610be92 100755
> --- a/configure
> +++ b/configure
> @@ -1738,6 +1738,7 @@ BUILTIN_LIST="
>  machine_rw_barrier
>  MemoryBarrier
>  mm_empty
> +parity
>  rdtsc
>  sarestart
>  sync_val_compare_and_swap
> @@ -5242,6 +5243,7 @@ check_builtin sarestart signal.h "SA_RESTART"
>  check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; 
> __sync_val_compare_and_swap(ptr, oldval, newval)"
>  check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, 
> tm)"
>  check_builtin localtime_r time.h "time_t *time; struct tm *tm; 
> localtime_r(time, tm)"
> +check_builtin parity "" "__builtin_parity(123)"
>  
>  case "$custom_allocator" in
>  jemalloc)
> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
> index 611ef88..9c36bf2 100644
> --- a/libavutil/x86/intmath.h
> +++ b/libavutil/x86/intmath.h
> @@ -75,6 +75,15 @@ static av_always_inline av_const int ff_ctzll_x86(long 
> long v)
>  
>  #endif /* __POPCNT__ */
>  
> +static av_always_inline av_const int ff_parity(uint32_t v)
> +{
> +#if HAVE_PARITY
> +return __builtin_parity(v);
> +#else
> +return av_popcount(v) & 1;
> +#endif

Do compilers really generate better code for the former?

> +}
> +
>  #if defined(__BMI2__)
>  
>  #if AV_GCC_VERSION_AT_LEAST(5,1)

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

Re: [FFmpeg-devel] [RFC] Disable compile-time tablegen for cbrt if total cycle count < 200000

[Michael Niedermayer]

On Fri, Jan 01, 2016 at 08:07:39AM -0800, Ganesh Ajjanagadde wrote:
> Hi all,
> 
> Motivated by a remark by Ronald:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186200.html,
> this is a request for comment on disabling compile time tablegen for
> cbrt if the total cycle count < 20. Note that cbrt tables are only
> used in aacdec.

Its very hard to state a hard number as the threshold, this is quite
subjective
and different viewpoints would lead to different results

but lets try anyway
for the hardcoded table case more data needs to be read from disk
ATM this is about 2mb for all tables

for dynamic tables the used tables need to be generated
theres a difference in binary size (table size vs code to generate it),
that translates into a cost value (bytes * cycles_per_byte)

and the dynamic init needs some time to build the table, thats
conveniently already in cycles

(above ignores alot, like HDDs, SDDs disk cache have different speed
 hardcoded tables can be shared between processes but then rarely would
 a process use all tables while the OS might end up loading all anyway
 also we assume a load from cache while a OS might actually map tables
 from the disk cache directly)

now if the dynamic init is faster than loading the table from
the disk cache then dynamic init is likely the better choice

using cat into /dev/null i get about 2bytes per cycle

also about START/STOP_TIMER, the decicyles are tens of cycles so
one tenths of the displayed value is the amount of cpu cycles

iam sure if one looks at this from a different angle a quite different
threshold mathod and value could result


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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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] common: add ff_parity()

[James Almer]

On 1/3/2016 5:33 PM, wm4 wrote:
> On Sun,  3 Jan 2016 20:21:00 +0100
> Clément Bœsch  wrote:
> 
>> ---
>>  configure   | 2 ++
>>  libavutil/x86/intmath.h | 9 +
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/configure b/configure
>> index 6710f85..610be92 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1738,6 +1738,7 @@ BUILTIN_LIST="
>>  machine_rw_barrier
>>  MemoryBarrier
>>  mm_empty
>> +parity
>>  rdtsc
>>  sarestart
>>  sync_val_compare_and_swap
>> @@ -5242,6 +5243,7 @@ check_builtin sarestart signal.h "SA_RESTART"
>>  check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; 
>> __sync_val_compare_and_swap(ptr, oldval, newval)"
>>  check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, 
>> tm)"
>>  check_builtin localtime_r time.h "time_t *time; struct tm *tm; 
>> localtime_r(time, tm)"
>> +check_builtin parity "" "__builtin_parity(123)"
>>  
>>  case "$custom_allocator" in
>>  jemalloc)
>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
>> index 611ef88..9c36bf2 100644
>> --- a/libavutil/x86/intmath.h
>> +++ b/libavutil/x86/intmath.h
>> @@ -75,6 +75,15 @@ static av_always_inline av_const int ff_ctzll_x86(long 
>> long v)
>>  
>>  #endif /* __POPCNT__ */
>>  
>> +static av_always_inline av_const int ff_parity(uint32_t v)
>> +{
>> +#if HAVE_PARITY
>> +return __builtin_parity(v);
>> +#else
>> +return av_popcount(v) & 1;
>> +#endif
> 
> Do compilers really generate better code for the former?

GCC does on x86 when the target cpu doesn't support the popcnt instruction,
otherwise the end result would be the same (popcnt + and).
av_popcount_c() is not optimal for this.

> 
>> +}
>> +
>>  #if defined(__BMI2__)
>>  
>>  #if AV_GCC_VERSION_AT_LEAST(5,1)
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Carl Eugen Hoyos]

Ganesh Ajjanagadde  mit.edu> writes:

> No one has told me what is interesting

Did you look at tickets #4441 or #4085?
(Careful about the license for the second one.)
But you can only decide for yourself what you 
find interesting...

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/3] common: add ff_parity()

[Clément Bœsch]

On Sun, Jan 03, 2016 at 05:54:34PM -0300, James Almer wrote:
> On 1/3/2016 4:22 PM, Clément Bœsch wrote:
> > On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
> > [...]
> >> +static av_always_inline av_const int ff_parity(uint32_t v)
> >> +{
> >> +#if HAVE_PARITY
> >> +return __builtin_parity(v);
> >> +#else
> >> +return av_popcount(v) & 1;
> > 
> > doing a popcount being overkill, this could be replaced with
> > (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1
> 
> Are you sure that's correct for an uint32_t?
> 

Erm. Yeah no, my bad.

> > 
> > Whatever people prefers
> 
> No need for the configure check. Make the above the c generic version (Add it 
> to
> common.h or intmath.h), then on x86/intmath.h make it use __builtin_parity if
> __GNU__ is true.

Why should we use __builtin_parity only on x86?

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avcodec/h264: Fix regression caused by removial of default_ref_list

[Michael Niedermayer]

On Mon, Jan 04, 2016 at 12:14:44AM +0100, Hendrik Leppkes wrote:
> On Sun, Jan 3, 2016 at 7:03 PM, Michael Niedermayer  wrote:
> > From: Michael Niedermayer 
> >
> > This fixes a regression of the sample from Ticket 2371
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/h264.h  |1 +
> >  libavcodec/h264_refs.c |   11 +--
> >  2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/h264.h b/libavcodec/h264.h
> > index 5d9aecd..a5fc3a0 100644
> > --- a/libavcodec/h264.h
> > +++ b/libavcodec/h264.h
> > @@ -669,6 +669,7 @@ typedef struct H264Context {
> >   */
> >  int max_pic_num;
> >
> > +H264Ref default_ref[2];
> >  H264Picture *short_ref[32];
> >  H264Picture *long_ref[32];
> >  H264Picture *delayed_pic[MAX_DELAYED_PIC_COUNT + 2]; // FIXME size?
> > diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> > index 52fedc1..f42d6a2 100644
> > --- a/libavcodec/h264_refs.c
> > +++ b/libavcodec/h264_refs.c
> > @@ -208,6 +208,8 @@ static void h264_initialise_ref_list(H264Context *h, 
> > H264SliceContext *sl)
> >  }
> >  }
> >  }
> > +for (i = 0; i < sl->list_count; i++)
> > +h->default_ref[i] = sl->ref_list[i][0];
> >  }
> >
> >  static void print_short_term(H264Context *h);
> > @@ -351,10 +353,14 @@ int 
> > ff_h264_decode_ref_pic_list_reordering(H264Context *h, H264SliceContext *sl)
> >  if (   !sl->ref_list[list][index].parent
> >  || (!FIELD_PICTURE(h) && 
> > (sl->ref_list[list][index].reference&3) != 3)) {
> >  int i;
> > -av_log(h->avctx, AV_LOG_ERROR, "Missing reference 
> > picture\n");
> > +av_log(h->avctx, AV_LOG_ERROR, "Missing reference picture, 
> > default is %d\n", h->default_ref[list].poc);
> >  for (i = 0; i < FF_ARRAY_ELEMS(h->last_pocs); i++)
> >  h->last_pocs[i] = INT_MIN;
> > -return -1;
> > +if (h->default_ref[list].parent
> > +&& !(!FIELD_PICTURE(h) && 
> > (h->default_ref[list].reference&3) != 3))
> > +sl->ref_list[list][index] = h->default_ref[list];
> > +else
> > +return -1;
> >  }
> >  
> > av_assert0(av_buffer_get_ref_count(sl->ref_list[list][index].parent->f->buf[0])
> >  > 0);
> >  }
> > @@ -524,6 +530,7 @@ void ff_h264_remove_all_refs(H264Context *h)
> >  }
> >  h->short_ref_count = 0;
> >
> > +memset(h->default_ref, 0, sizeof(h->default_ref));
> >  for (i = 0; i < h->nb_slice_ctx; i++) {
> >  H264SliceContext *sl = >slice_ctx[i];
> >  sl->list_count = sl->ref_count[0] = sl->ref_count[1] = 0;
> > --
> 
> Patch works for me. But I don't have a big opinion on which to use.
> This one makes future merges easier, buty  ou are the most likely to
> work on the H264 decoder in the future, so if noone else has any
> opinions, i would just let you push whichever of the two you prefer.

ok, 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] avformat/concatdec: get bit_rate from internal format

[Zhang Rui]

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

Re: [FFmpeg-devel] [PATCH 2/3] lavc/ccaption_dec: use ff_parity()

[Michael Niedermayer]

On Sun, Jan 03, 2016 at 08:21:01PM +0100, Clément Bœsch wrote:
> ---
>  libavcodec/ccaption_dec.c | 38 ++
>  1 file changed, 2 insertions(+), 36 deletions(-)

should be ok

thx

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH][RFC][WIP] lavf/ramdec: RAM demuxer

[Paul B Mahol]

On 1/3/16, Ganesh Ajjanagadde  wrote:
> On Sun, Jan 3, 2016 at 12:59 PM, Hendrik Leppkes 
> wrote:
>> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
>>  wrote:
>>> This is a WIP patch for the RAM playlist format:
>>> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
>>> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm.
>>>
>>> The implementation is currently essentially a kitchen sink dump of
>>> concatdec; hence the copyright notice is preserved.
>>>
>>> Metadata stuff is currently lacking. Feedback appreciated; this is my
>>> first demuxer.
>>>
>>> Done some very simple, basic testing.
>>>
>>
>> Playlists "intentionally" don't have demuxers, as they should probably
>> be handled in a more generic top-level way. As you said, this is
>> basically concatdec with parsing, which every playlist demuxer would
>> likely end up being.
>> Unfortunately, noone has yet finished any such API to handle this
>> properly, hence no playlist support in FFmpeg yet.
>
> I get a sense that it is tedious, annoying, and with little benefit:
> for a power user, they have zero benefit as one can simply use concat
> and/or script a converter to the concat format. For a normal user,
> downstream clients anyway handle playlists.
>
> Patch dropped; thanks.

If you really want something hard, write tivo demuxer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] vorbisdec: replace get_bits with get_bitsz where n can be 0

[Michael Niedermayer]

On Sun, Jan 03, 2016 at 11:44:02PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 22:50, Michael Niedermayer wrote:
> > On Sun, Jan 03, 2016 at 07:50:39PM +0100, Andreas Cadhalpun wrote:
> >>  vorbisdec.c |5 +
> >>  1 file changed, 5 insertions(+)
> >> ba151dadb72b6c74e1139decf4b32c8676ddc58e  
> >> 0001-vorbisdec-reject-rangebits-0.patch
> >> From d740a59b6e099c90504d55c65923def1ad6de234 Mon Sep 17 00:00:00 2001
> >> From: Andreas Cadhalpun 
> >> Date: Sun, 3 Jan 2016 19:11:24 +0100
> >> Subject: [PATCH 1/2] vorbisdec: reject rangebits 0
> >>
> >> This causes non-unique elements in floor_setup->data.t1.list, which
> >> makes the stream undecodable according to the specification.
> >>
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavcodec/vorbisdec.c | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
> >> index f773afa..2792af1 100644
> >> --- a/libavcodec/vorbisdec.c
> >> +++ b/libavcodec/vorbisdec.c
> >> @@ -573,6 +573,11 @@ static int 
> >> vorbis_parse_setup_hdr_floors(vorbis_context *vc)
> >>  return AVERROR(ENOMEM);
> >>  
> >>  rangebits = get_bits(gb, 4);
> >> +if (!rangebits) {
> >> +av_log(vc->avctx, AV_LOG_ERROR,
> >> +   "A rangebits value of 0 is not compliant with the 
> >> Vorbis I specification.\n");
> >> +return AVERROR_INVALIDDATA;
> >> +}
> > 
> > this assumes partitions > 0
> > iam not sure if this is required or not, the spec does not seem to
> > explicitly state it
> 
> OK, so let's only error out if partitions is > 0.
> Updated patch attached.
> 
> Best regards,
> Andreas
> 

>  vorbisdec.c |5 +
>  1 file changed, 5 insertions(+)
> cb124c1de2cdbe783b2217af90f082cbc6e0a29f  
> 0001-vorbisdec-reject-rangebits-0-with-non-0-partitions.patch
> From 37170226888eb08fe1d98e31bed4a0a8199bd7e3 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Sun, 3 Jan 2016 19:11:24 +0100
> Subject: [PATCH] vorbisdec: reject rangebits 0 with non-0 partitions
> 
> This causes non-unique elements in floor_setup->data.t1.list, which
> makes the stream undecodable according to the specification.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/vorbisdec.c | 5 +
>  1 file changed, 5 insertions(+)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

[FFmpeg-devel] [PATCH][RFC][WIP] lavf/ramdec: RAM demuxer

[Ganesh Ajjanagadde]

This is a WIP patch for the RAM playlist format:
http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm.

The implementation is currently essentially a kitchen sink dump of
concatdec; hence the copyright notice is preserved.

Metadata stuff is currently lacking. Feedback appreciated; this is my
first demuxer.

Done some very simple, basic testing.

Signed-off-by: Ganesh Ajjanagadde 
---
 MAINTAINERS  |   1 +
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/ramdec.c | 467 +++
 4 files changed, 470 insertions(+)
 create mode 100644 libavformat/ramdec.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9add13d..ba1034e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -486,6 +486,7 @@ Muxers/Demuxers:
   rdt.c Ronald S. Bultje
   rl2.c Sascha Sommer
   rmdec.c, rmenc.c  Ronald S. Bultje, Kostya Shishkov
+  ramdec.c  Ganesh Ajjanagadde
   rtmp* Kostya Shishkov
   rtp.c, rtpenc.c   Martin Storsjo
   rtpdec_ac3.*  Gilles Chanteperdrix
diff --git a/libavformat/Makefile b/libavformat/Makefile
index e03c73e..708e622 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -377,6 +377,7 @@ OBJS-$(CONFIG_REALTEXT_DEMUXER)  += realtextdec.o 
subtitles.o
 OBJS-$(CONFIG_REDSPARK_DEMUXER)  += redspark.o
 OBJS-$(CONFIG_RL2_DEMUXER)   += rl2.o
 OBJS-$(CONFIG_RM_DEMUXER)+= rmdec.o rm.o rmsipr.o
+OBJS-$(CONFIG_RAM_DEMUXER)   += ramdec.o
 OBJS-$(CONFIG_RM_MUXER)  += rmenc.o rm.o
 OBJS-$(CONFIG_ROQ_DEMUXER)   += idroqdec.o
 OBJS-$(CONFIG_ROQ_MUXER) += idroqenc.o rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index dabfa34..f1dea3e 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -262,6 +262,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (REDSPARK, redspark);
 REGISTER_DEMUXER (RL2,  rl2);
 REGISTER_MUXDEMUX(RM,   rm);
+REGISTER_DEMUXER (RAM,  ram);
 REGISTER_MUXDEMUX(ROQ,  roq);
 REGISTER_DEMUXER (RPL,  rpl);
 REGISTER_DEMUXER (RSD,  rsd);
diff --git a/libavformat/ramdec.c b/libavformat/ramdec.c
new file mode 100644
index 000..e5e8ec1
--- /dev/null
+++ b/libavformat/ramdec.c
@@ -0,0 +1,467 @@
+/*
+ * RAM playlist demuxer
+ * Copyright (c) 2016 Nicolas George
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/timestamp.h"
+#include "avformat.h"
+#include "internal.h"
+#include "url.h"
+
+/* FIXME: multiple files, seeking, metadata */
+typedef enum RamMatchMode {
+MATCH_ONE_TO_ONE,
+MATCH_EXACT_ID,
+} RamMatchMode;
+
+typedef struct RamStream {
+AVBitStreamFilterContext *bsf;
+int out_stream_index;
+} RamStream;
+
+typedef struct {
+char *url;
+AVDictionary *metadata;
+RamStream *streams;
+int64_t start_time;
+int64_t file_start_time;
+int64_t file_inpoint;
+int64_t duration;
+int64_t inpoint;
+int64_t outpoint;
+int nb_streams;
+} RamFile;
+
+typedef struct {
+AVClass *class;
+RamFile *files;
+RamFile *cur_file;
+AVFormatContext *avf;
+unsigned nb_files;
+int eof;
+RamMatchMode stream_match_mode;
+unsigned auto_convert;
+int segment_time_metadata;
+} RamContext;
+
+static int ram_probe(AVProbeData *probe)
+{
+char *line_buf;
+char *next_line;
+char probe_str[4];
+AVIOContext *pb;
+int ret;
+line_buf = av_strtok(probe->buf, "\r\n", _line);
+
+/* skip over comments */
+while (line_buf && *line_buf == '#')
+line_buf = av_strtok(NULL, "\r\n", _line);
+
+if ((ret = avio_open(, line_buf, AVIO_FLAG_READ)) < 0)
+return ret;
+if ((ret = avio_read(pb, probe_str, sizeof(probe_str))) < 0)
+goto fail;
+ 

Re: [FFmpeg-devel] [PATCH 1/3] common: add ff_parity()

[James Almer]

On 1/3/2016 6:33 PM, Clément Bœsch wrote:
> On Sun, Jan 03, 2016 at 05:54:34PM -0300, James Almer wrote:
>> On 1/3/2016 4:22 PM, Clément Bœsch wrote:
>>> On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
>>> [...]
 +static av_always_inline av_const int ff_parity(uint32_t v)
 +{
 +#if HAVE_PARITY
 +return __builtin_parity(v);
 +#else
 +return av_popcount(v) & 1;
>>>
>>> doing a popcount being overkill, this could be replaced with
>>> (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1
>>
>> Are you sure that's correct for an uint32_t?
>>
> 
> Erm. Yeah no, my bad.
> 
>>>
>>> Whatever people prefers
>>
>> No need for the configure check. Make the above the c generic version (Add 
>> it to
>> common.h or intmath.h), then on x86/intmath.h make it use __builtin_parity if
>> __GNU__ is true.
> 
> Why should we use __builtin_parity only on x86?

Yeah, my bad. Was thinking as if this was about __builtin_popcount, which is 
awful
with GCC for anything except a few x86 targets.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Cineform HD Decoder:

[Kieran Kunhya]

Decodes YUV422P10 samples in AVI and MOV (Gopro Studio)
Older files with more subbands, skips, Bayer not supported
---
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/cfhd.c   | 567 
 libavcodec/cfhd.h   |  97 +
 libavcodec/cfhddata.c   | 466 +++
 libavcodec/codec_desc.c |   6 +
 libavformat/riff.c  |   1 +
 8 files changed, 1140 insertions(+)
 create mode 100644 libavcodec/cfhd.c
 create mode 100644 libavcodec/cfhd.h
 create mode 100644 libavcodec/cfhddata.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a18ca5b..9db88d7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -212,6 +212,7 @@ OBJS-$(CONFIG_CDGRAPHICS_DECODER)  += cdgraphics.o
 OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o
 OBJS-$(CONFIG_CINEPAK_DECODER) += cinepak.o
 OBJS-$(CONFIG_CINEPAK_ENCODER) += cinepakenc.o elbg.o
+OBJS-$(CONFIG_CFHD_DECODER)+= cfhd.o cfhddata.o
 OBJS-$(CONFIG_CLJR_DECODER)+= cljrdec.o
 OBJS-$(CONFIG_CLJR_ENCODER)+= cljrenc.o
 OBJS-$(CONFIG_CLLC_DECODER)+= cllc.o canopus.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4eeb6f3..ca6e4c2 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -147,6 +147,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(CAVS,  cavs);
 REGISTER_DECODER(CDGRAPHICS,cdgraphics);
 REGISTER_DECODER(CDXL,  cdxl);
+REGISTER_DECODER(CFHD,  cfhd);
 REGISTER_ENCDEC (CINEPAK,   cinepak);
 REGISTER_ENCDEC (CLJR,  cljr);
 REGISTER_DECODER(CLLC,  cllc);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index f365775..b958a6c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -315,6 +315,7 @@ enum AVCodecID {
 AV_CODEC_ID_SMVJPEG,
 AV_CODEC_ID_APNG,
 AV_CODEC_ID_DAALA,
+AV_CODEC_ID_CFHD,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
new file mode 100644
index 000..0f1bcd3
--- /dev/null
+++ b/libavcodec/cfhd.c
@@ -0,0 +1,567 @@
+/*
+ * Copyright (c) 2015 Kieran Kunhya
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * CFHD Video Decoder
+ */
+
+#include "avcodec.h"
+#include "bswapdsp.h"
+#include "internal.h"
+#include "cfhd.h"
+#include "libavutil/avassert.h"
+#include "libavutil/buffer.h"
+#include "libavutil/common.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+
+static av_cold int cfhd_init_decoder(AVCodecContext *avctx)
+{
+CFHDContext *s = avctx->priv_data;
+
+ff_cfhd_init_vlcs(s);
+
+avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
+avctx->bits_per_raw_sample = 16;
+s->avctx   = avctx;
+
+return 0;
+}
+
+static void init_plane_defaults(CFHDContext *s)
+{
+s->subband_num= 0;
+s->level  = 0;
+s->subband_num_actual = 0;
+}
+
+static void init_frame_defaults(CFHDContext *s)
+{
+s->bpc   = 10;
+s->channel_cnt   = 4;
+s->subband_cnt   = 10;
+s->channel_num   = 0;
+s->lowpass_precision = 16;
+s->quantisation  = 1;
+s->wavelet_depth = 3;
+s->pshift= 1;
+s->codebook  = 0;
+init_plane_defaults(s);
+}
+
+static inline int dequant_and_decompand(int level, int quantisation)
+{
+int abslevel = abs(level);
+return (abslevel + ((768 * abslevel * abslevel * abslevel) / (255 * 255 * 
255))) * FFSIGN(level) * quantisation;
+}
+
+static inline void filter(int16_t *output, int out_stride, int16_t *low, int 
low_stride,
+  int16_t *high, int high_stride, int len)
+{
+int32_t tmp, tmp2;
+int16_t tmp3, tmp4;
+
+/* these refer to the coefficients for the *next* iteration */
+int16_t l_0, l_1, l_2, l_m1, l_m2;
+int16_t h_0;
+
+int i;
+for (i = 0; i < len; i++) {
+if (i == 0) {
+l_2  = low[3 * low_stride];
+

Re: [FFmpeg-devel] [RFC] Disable compile-time tablegen for cbrt if total cycle count < 200000

[Michael Niedermayer]

On Mon, Jan 04, 2016 at 12:21:40AM +0100, Michael Niedermayer wrote:
> On Mon, Jan 04, 2016 at 12:07:15AM +0100, Michael Niedermayer wrote:
> > On Fri, Jan 01, 2016 at 08:07:39AM -0800, Ganesh Ajjanagadde wrote:
> > > Hi all,
> > > 
> > > Motivated by a remark by Ronald:
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186200.html,
> > > this is a request for comment on disabling compile time tablegen for
> > > cbrt if the total cycle count < 20. Note that cbrt tables are only
> > > used in aacdec.
> > 
> > Its very hard to state a hard number as the threshold, this is quite
> > subjective
> > and different viewpoints would lead to different results
> > 
> > but lets try anyway
> > for the hardcoded table case more data needs to be read from disk
> > ATM this is about 2mb for all tables
> > 
> > for dynamic tables the used tables need to be generated
> > theres a difference in binary size (table size vs code to generate it),
> > that translates into a cost value (bytes * cycles_per_byte)
> > 
> > and the dynamic init needs some time to build the table, thats
> > conveniently already in cycles
> > 
> > (above ignores alot, like HDDs, SDDs disk cache have different speed
> >  hardcoded tables can be shared between processes but then rarely would
> >  a process use all tables while the OS might end up loading all anyway
> >  also we assume a load from cache while a OS might actually map tables
> >  from the disk cache directly)
> > 
> > now if the dynamic init is faster than loading the table from
> > the disk cache then dynamic init is likely the better choice
> > 
> 
> > using cat into /dev/null i get about 2bytes per cycle
> 
> to make this more complex
> if the whole binary is read on init then all tables would need to be
> loaded while for a use case of repeated execution of ffmpeg only
> the tables needed for a single file would need to be build
> 
> (the repeated execution is where the init time matters most)

if one assumes that hardcoded tables are always loaded and only one
set of tables is generated then the question would be how often
does a table need to be generated
for example if table foobar needs to be generated for 100% of the
files then the cost of 2bytes per cycle vs cycles to build it from
above would apply
while OTOH if a table is only generated for 1% of the files
then it would be 2bytes per cycle vs. X cycles to generate it * 0.01

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCH][RFC][WIP] lavf/ramdec: RAM demuxer

[Hendrik Leppkes]

On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
 wrote:
> This is a WIP patch for the RAM playlist format:
> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm.
>
> The implementation is currently essentially a kitchen sink dump of
> concatdec; hence the copyright notice is preserved.
>
> Metadata stuff is currently lacking. Feedback appreciated; this is my
> first demuxer.
>
> Done some very simple, basic testing.
>

Playlists "intentionally" don't have demuxers, as they should probably
be handled in a more generic top-level way. As you said, this is
basically concatdec with parsing, which every playlist demuxer would
likely end up being.
Unfortunately, noone has yet finished any such API to handle this
properly, hence no playlist support in FFmpeg yet.


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

Re: [FFmpeg-devel] [PATCH]lavfi/drawtext: Fix microsecond display

[Carl Eugen Hoyos]

Derek Buitenhuis  gmail.com> writes:

> On 1/3/2016 1:00 PM, Carl Eugen Hoyos wrote:
> > Attached patch fixes ticket #4792 for me, please comment.
> 
> Looks OK.

Thank you, patch applied.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 3/3] lavc/g729dec: use ff_parity()

[Michael Niedermayer]

On Sun, Jan 03, 2016 at 08:21:02PM +0100, Clément Bœsch wrote:
> ---
>  libavcodec/g729dec.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)

LGTM
thx

[...]
-- 
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 2/3] vorbisdec: replace get_bits with get_bitsz where n can be 0

[Andreas Cadhalpun]

On 03.01.2016 22:50, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 07:50:39PM +0100, Andreas Cadhalpun wrote:
>>  vorbisdec.c |5 +
>>  1 file changed, 5 insertions(+)
>> d8862de6632822fd066a585953e5966fd941ad93  
>> 0002-vorbisdec-reject-channel-mapping-with-less-than-two-.patch
>> From 09bf8ca4d496518b876639b793cae12066b7ba3b Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Sun, 3 Jan 2016 19:20:54 +0100
>> Subject: [PATCH 2/2] vorbisdec: reject channel mapping with less than two
>>  channels
>>
>> It causes the angle channel number to equal the magnitude channel
>> number, which makes the stream undecodable according to the
>> specification.
> 
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] rtmpdh: Initialize gcrypt before using it

[Jan Ekstrom]

Hi,

In general looks good, although it might look a bit weird for someone
as usually libraries have initialization functions called like that.
That said, this is what
https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html
recommends.

My only comment would be that we might want to set the parameter to
GCRYPT_VERSION instead of NULL, as we most probably care if the
library loaded matches our version (unless these versions change even
if API doesn't change).

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264: Fix regression caused by removial of default_ref_list

[Hendrik Leppkes]

On Sun, Jan 3, 2016 at 7:03 PM, Michael Niedermayer  wrote:
> From: Michael Niedermayer 
>
> This fixes a regression of the sample from Ticket 2371
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264.h  |1 +
>  libavcodec/h264_refs.c |   11 +--
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/h264.h b/libavcodec/h264.h
> index 5d9aecd..a5fc3a0 100644
> --- a/libavcodec/h264.h
> +++ b/libavcodec/h264.h
> @@ -669,6 +669,7 @@ typedef struct H264Context {
>   */
>  int max_pic_num;
>
> +H264Ref default_ref[2];
>  H264Picture *short_ref[32];
>  H264Picture *long_ref[32];
>  H264Picture *delayed_pic[MAX_DELAYED_PIC_COUNT + 2]; // FIXME size?
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index 52fedc1..f42d6a2 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -208,6 +208,8 @@ static void h264_initialise_ref_list(H264Context *h, 
> H264SliceContext *sl)
>  }
>  }
>  }
> +for (i = 0; i < sl->list_count; i++)
> +h->default_ref[i] = sl->ref_list[i][0];
>  }
>
>  static void print_short_term(H264Context *h);
> @@ -351,10 +353,14 @@ int ff_h264_decode_ref_pic_list_reordering(H264Context 
> *h, H264SliceContext *sl)
>  if (   !sl->ref_list[list][index].parent
>  || (!FIELD_PICTURE(h) && 
> (sl->ref_list[list][index].reference&3) != 3)) {
>  int i;
> -av_log(h->avctx, AV_LOG_ERROR, "Missing reference 
> picture\n");
> +av_log(h->avctx, AV_LOG_ERROR, "Missing reference picture, 
> default is %d\n", h->default_ref[list].poc);
>  for (i = 0; i < FF_ARRAY_ELEMS(h->last_pocs); i++)
>  h->last_pocs[i] = INT_MIN;
> -return -1;
> +if (h->default_ref[list].parent
> +&& !(!FIELD_PICTURE(h) && 
> (h->default_ref[list].reference&3) != 3))
> +sl->ref_list[list][index] = h->default_ref[list];
> +else
> +return -1;
>  }
>  
> av_assert0(av_buffer_get_ref_count(sl->ref_list[list][index].parent->f->buf[0])
>  > 0);
>  }
> @@ -524,6 +530,7 @@ void ff_h264_remove_all_refs(H264Context *h)
>  }
>  h->short_ref_count = 0;
>
> +memset(h->default_ref, 0, sizeof(h->default_ref));
>  for (i = 0; i < h->nb_slice_ctx; i++) {
>  H264SliceContext *sl = >slice_ctx[i];
>  sl->list_count = sl->ref_count[0] = sl->ref_count[1] = 0;
> --

Patch works for me. But I don't have a big opinion on which to use.
This one makes future merges easier, buty  ou are the most likely to
work on the H264 decoder in the future, so if noone else has any
opinions, i would just let you push whichever of the two you prefer.

Thanks

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

Re: [FFmpeg-devel] [PATCH 1/3] common: add ff_parity()

[James Almer]

On 1/3/2016 4:22 PM, Clément Bœsch wrote:
> On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
> [...]
>> +static av_always_inline av_const int ff_parity(uint32_t v)
>> +{
>> +#if HAVE_PARITY
>> +return __builtin_parity(v);
>> +#else
>> +return av_popcount(v) & 1;
> 
> doing a popcount being overkill, this could be replaced with
> (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1

Are you sure that's correct for an uint32_t?

> 
> Whatever people prefers

No need for the configure check. Make the above the c generic version (Add it to
common.h or intmath.h), then on x86/intmath.h make it use __builtin_parity if
__GNU__ is true.

Even if the popcnt instruction is not supported by the target cpu, the code
generated for __builtin_parity by GCC is much better than the one generated by
av_popcount_c()
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 9:35 AM, Kieran Kunhya  wrote:
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcoded tables can be removed here.
>
> How are you going to guarantee this across all arches?

First of all, I have no idea what "guarantee" you are looking for
here. What I guarantee is this: on every architecture, this change
results in speedup (not to a mathematical level of guarantee, but to a
practical level of gurantee).

What I don't know is at what point one considers hardcoded tables,
associated ifdefry, etc useful or not. That is inherently subjective.
Same goes for code "readability" - also subjective. I also don't know
the relative gains across architectures.

What I do know is that there are clear inconsistencies in opinions
here regarding this (e.g not "speed critical" yet needs a configure
option), and I want to understand the heart of the matter.

The thread I created is a step towards a scientific understanding of
the actual impact of hardcoded tables, something that seems to not
have been done in the past, when it should have been done at the time
of introduction.

Furthermore, since when has FFmpeg "guaranteed" speedups across all
arches? Impacts of even a single line change can vary across arches.
Does that mean that all patches under review get benched on each and
every architecture that we support? Of course not.

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

Re: [FFmpeg-devel] [PATCH 2/3] vorbisdec: replace get_bits with get_bitsz where n can be 0

[Michael Niedermayer]

On Sun, Jan 03, 2016 at 07:50:39PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 02:41, Michael Niedermayer wrote:
> > On Sun, Jan 03, 2016 at 01:36:13AM +0100, Andreas Cadhalpun wrote:
> >> get_bits is documented to only support reading 1-25 bits.
> >> get_bitsz was added for this purpose.
> >>
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavcodec/vorbisdec.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
> >> index f773afa..9ba0bce 100644
> >> --- a/libavcodec/vorbisdec.c
> >> +++ b/libavcodec/vorbisdec.c
> >> @@ -169,7 +169,7 @@ static const char idx_err_str[] = "Index value %d out 
> >> of range (0 - %d) for %s a
> >>  }
> >>  #define GET_VALIDATED_INDEX(idx, bits, limit) \
> >>  {\
> >> -idx = get_bits(gb, bits);\
> >> +idx = get_bitsz(gb, bits);\
> >>  VALIDATE_INDEX(idx, limit)\
> >>  }
> > 
> > this looks wrong
> > bits is 8 or ilog() where ilog(0) is not allowed one way or another
> > i think
> > 
> > for example for the audio channels
> > "the numbers read in the above two steps are channel numbers representing
> >  the channel to treat as magnitude and the channel to treat as angle,
> >  respectively. If for any coupling step the angle channel number equals
> >  the magnitude channel number " ... "the stream is undecodable."
> > 
> > when reading 0 bits both would be 0
> > 
> > 
> >>  
> >> @@ -585,7 +585,7 @@ static int 
> >> vorbis_parse_setup_hdr_floors(vorbis_context *vc)
> >>  
> >>  for (j = 0; j < floor_setup->data.t1.partitions; ++j) {
> >>  for (k = 0; k < 
> >> floor_setup->data.t1.class_dimensions[floor_setup->data.t1.partition_class[j]];
> >>  ++k, ++floor1_values) {
> >> -floor_setup->data.t1.list[floor1_values].x = 
> >> get_bits(gb, rangebits);
> >> +floor_setup->data.t1.list[floor1_values].x = 
> >> get_bitsz(gb, rangebits);
> > 
> > IIUC
> > "Vector [floor1_x_list] is limited to a maximum length of 65 elements;
> >  a setup indicating more than 65 total elements (including elements 0
> >  and 1 set prior to the read loop) renders the stream undecodable. All
> >  vector [floor1_x_list] element values must be unique within the vector;
> >  a non-unique value renders the stream undecodable. "
> > 
> > suggests that values cannot be 0 as the first is hardcoded to 0
> 
> Thanks a lot for finding the relevant places in the specification.
> 
> Based on that it's probably better to just error out in these cases.
> Patches for that are attached.
> 
> Best regards,
> Andreas
> 

>  vorbisdec.c |5 +
>  1 file changed, 5 insertions(+)
> ba151dadb72b6c74e1139decf4b32c8676ddc58e  
> 0001-vorbisdec-reject-rangebits-0.patch
> From d740a59b6e099c90504d55c65923def1ad6de234 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Sun, 3 Jan 2016 19:11:24 +0100
> Subject: [PATCH 1/2] vorbisdec: reject rangebits 0
> 
> This causes non-unique elements in floor_setup->data.t1.list, which
> makes the stream undecodable according to the specification.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/vorbisdec.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
> index f773afa..2792af1 100644
> --- a/libavcodec/vorbisdec.c
> +++ b/libavcodec/vorbisdec.c
> @@ -573,6 +573,11 @@ static int vorbis_parse_setup_hdr_floors(vorbis_context 
> *vc)
>  return AVERROR(ENOMEM);
>  
>  rangebits = get_bits(gb, 4);
> +if (!rangebits) {
> +av_log(vc->avctx, AV_LOG_ERROR,
> +   "A rangebits value of 0 is not compliant with the 
> Vorbis I specification.\n");
> +return AVERROR_INVALIDDATA;
> +}

this assumes partitions > 0
iam not sure if this is required or not, the spec does not seem to
explicitly state it


>  rangemax = (1 << rangebits);
>  if (rangemax > vc->blocksize[1] / 2) {
>  av_log(vc->avctx, AV_LOG_ERROR,
> -- 
> 2.6.4
> 

>  vorbisdec.c |5 +
>  1 file changed, 5 insertions(+)
> d8862de6632822fd066a585953e5966fd941ad93  
> 0002-vorbisdec-reject-channel-mapping-with-less-than-two-.patch
> From 09bf8ca4d496518b876639b793cae12066b7ba3b Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Sun, 3 Jan 2016 19:20:54 +0100
> Subject: [PATCH 2/2] vorbisdec: reject channel mapping with less than two
>  channels
> 
> It causes the angle channel number to equal the magnitude channel
> number, which makes the stream undecodable according to the
> specification.


LGTM

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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

Re: [FFmpeg-devel] [PATCH 2/3] vorbisdec: replace get_bits with get_bitsz where n can be 0

[Andreas Cadhalpun]

On 03.01.2016 22:50, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 07:50:39PM +0100, Andreas Cadhalpun wrote:
>>  vorbisdec.c |5 +
>>  1 file changed, 5 insertions(+)
>> ba151dadb72b6c74e1139decf4b32c8676ddc58e  
>> 0001-vorbisdec-reject-rangebits-0.patch
>> From d740a59b6e099c90504d55c65923def1ad6de234 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Sun, 3 Jan 2016 19:11:24 +0100
>> Subject: [PATCH 1/2] vorbisdec: reject rangebits 0
>>
>> This causes non-unique elements in floor_setup->data.t1.list, which
>> makes the stream undecodable according to the specification.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/vorbisdec.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
>> index f773afa..2792af1 100644
>> --- a/libavcodec/vorbisdec.c
>> +++ b/libavcodec/vorbisdec.c
>> @@ -573,6 +573,11 @@ static int vorbis_parse_setup_hdr_floors(vorbis_context 
>> *vc)
>>  return AVERROR(ENOMEM);
>>  
>>  rangebits = get_bits(gb, 4);
>> +if (!rangebits) {
>> +av_log(vc->avctx, AV_LOG_ERROR,
>> +   "A rangebits value of 0 is not compliant with the 
>> Vorbis I specification.\n");
>> +return AVERROR_INVALIDDATA;
>> +}
> 
> this assumes partitions > 0
> iam not sure if this is required or not, the spec does not seem to
> explicitly state it

OK, so let's only error out if partitions is > 0.
Updated patch attached.

Best regards,
Andreas

>From 37170226888eb08fe1d98e31bed4a0a8199bd7e3 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Sun, 3 Jan 2016 19:11:24 +0100
Subject: [PATCH] vorbisdec: reject rangebits 0 with non-0 partitions

This causes non-unique elements in floor_setup->data.t1.list, which
makes the stream undecodable according to the specification.

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

diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
index f773afa..59691b9 100644
--- a/libavcodec/vorbisdec.c
+++ b/libavcodec/vorbisdec.c
@@ -573,6 +573,11 @@ static int vorbis_parse_setup_hdr_floors(vorbis_context *vc)
 return AVERROR(ENOMEM);
 
 rangebits = get_bits(gb, 4);
+if (!rangebits && floor_setup->data.t1.partitions) {
+av_log(vc->avctx, AV_LOG_ERROR,
+   "A rangebits value of 0 is not compliant with the Vorbis I specification.\n");
+return AVERROR_INVALIDDATA;
+}
 rangemax = (1 << rangebits);
 if (rangemax > vc->blocksize[1] / 2) {
 av_log(vc->avctx, AV_LOG_ERROR,
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Michael Niedermayer]

On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> > This gets rid of some branches to speed up table generation slightly
> > (impact higher on mulaw than alaw). Tables are identical to before,
> > tested with FATE.
> > 
> > Sample benchmark (Haswell, GNU/Linux+gcc):
> > old:
> >  313494 decicycles in build_alaw_table,4094 runs,  2 skips
> >  315959 decicycles in build_alaw_table,8190 runs,  2 skips
> > 
> >  323599 decicycles in build_ulaw_table,4095 runs,  1 skips
> >  318849 decicycles in build_ulaw_table,8188 runs,  4 skips
> > 
> > new:
> >  261902 decicycles in build_alaw_table,4096 runs,  0 skips
> >  266519 decicycles in build_alaw_table,8192 runs,  0 skips
> > 
> >  209657 decicycles in build_ulaw_table,4096 runs,  0 skips
> >  232656 decicycles in build_ulaw_table,8192 runs,  0 skips
> > 
> > Signed-off-by: Ganesh Ajjanagadde 
> > ---
> >  libavcodec/pcm_tablegen.h | 24 
> >  1 file changed, 12 insertions(+), 12 deletions(-)
> > 
> > diff --git a/libavcodec/pcm_tablegen.h b/libavcodec/pcm_tablegen.h
> > index 1387210..7269977 100644
> > --- a/libavcodec/pcm_tablegen.h
> > +++ b/libavcodec/pcm_tablegen.h
> > @@ -87,21 +87,21 @@ static av_cold void build_xlaw_table(uint8_t 
> > *linear_to_xlaw,
> >  {
> >  int i, j, v, v1, v2;
> >  
> > -j = 0;
> > -for(i=0;i<128;i++) {
> > -if (i != 127) {
> > -v1 = xlaw2linear(i ^ mask);
> > -v2 = xlaw2linear((i + 1) ^ mask);
> > -v = (v1 + v2 + 4) >> 3;
> > -} else {
> > -v = 8192;
> > -}
> > -for(;j > +j = 1;
> > +linear_to_xlaw[8192] = mask;
> > +for(i=0;i<127;i++) {
> > +v1 = xlaw2linear(i ^ mask);
> > +v2 = xlaw2linear((i + 1) ^ mask);
> > +v = (v1 + v2 + 4) >> 3;
> > +for(;j > +linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
> >  linear_to_xlaw[8192 + j] = (i ^ mask);
> > -if (j > 0)
> > -linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
> >  }
> >  }
> > +for(;j<8192;j++) {
> > +linear_to_xlaw[8192 - j] = (127 ^ (mask ^ 0x80));
> > +linear_to_xlaw[8192 + j] = (127 ^ mask);
> > +}
> >  linear_to_xlaw[0] = linear_to_xlaw[1];
> 
> i think you can make the tables 8 times smaller

forget this, i should have checked the whole table or looked when i
am awake ...

[...]

-- 
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] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 1:30 PM, Carl Eugen Hoyos  wrote:
> Carl Eugen Hoyos  ag.or.at> writes:
>
>> Ganesh Ajjanagadde  mit.edu> writes:
>>
>> > No one has told me what is interesting
>>
>> Did you look at tickets #4441 or #4085?
>
> Or ticket #4829 or a j2k issue?

Thanks a lot for taking the time to point these out. They have all
been noted. Unfortunately, I have too many things on my list now. 4829
may be what I tackle first; it may take a while though.

I hope the following is helpful.
Generally, my strengths are in algorithmic/mathematical/numerical
improvements. I have a strong interest in security (both its
"practical" and "theoretical" variants), but with nowhere near the
same level of knowledge.

Clarifications: by algorithmic improvements, I do not usually count
asm code, but make exceptions in some cases. In particular, I have
minimal knowledge of assembly and minimal motivation in learning it.
However, I may examine at some point cases where I am convinced that a
compiler can't do the needful.
By theoretical aspects of security, I refer to defensive programming,
some forms of undefined behavior (e.g rint64_clip, many ubsan
failures), and other such things such as those flagged by Coverity. By
practical aspects of security, I refer to things like fuzzing crashes,
other ubsan failures, and other things flagged by Coverity or found by
audit.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 7:32 PM, Michael Niedermayer
 wrote:
> On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
>> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
>> > This gets rid of some branches to speed up table generation slightly
>> > (impact higher on mulaw than alaw). Tables are identical to before,
>> > tested with FATE.
>> >
>> > Sample benchmark (Haswell, GNU/Linux+gcc):
>> > old:
>> >  313494 decicycles in build_alaw_table,4094 runs,  2 skips
>> >  315959 decicycles in build_alaw_table,8190 runs,  2 skips
>> >
>> >  323599 decicycles in build_ulaw_table,4095 runs,  1 skips
>> >  318849 decicycles in build_ulaw_table,8188 runs,  4 skips
>> >
>> > new:
>> >  261902 decicycles in build_alaw_table,4096 runs,  0 skips
>> >  266519 decicycles in build_alaw_table,8192 runs,  0 skips
>> >
>> >  209657 decicycles in build_ulaw_table,4096 runs,  0 skips
>> >  232656 decicycles in build_ulaw_table,8192 runs,  0 skips
>> >
>> > Signed-off-by: Ganesh Ajjanagadde 
>> > ---
>> >  libavcodec/pcm_tablegen.h | 24 
>> >  1 file changed, 12 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/libavcodec/pcm_tablegen.h b/libavcodec/pcm_tablegen.h
>> > index 1387210..7269977 100644
>> > --- a/libavcodec/pcm_tablegen.h
>> > +++ b/libavcodec/pcm_tablegen.h
>> > @@ -87,21 +87,21 @@ static av_cold void build_xlaw_table(uint8_t 
>> > *linear_to_xlaw,
>> >  {
>> >  int i, j, v, v1, v2;
>> >
>> > -j = 0;
>> > -for(i=0;i<128;i++) {
>> > -if (i != 127) {
>> > -v1 = xlaw2linear(i ^ mask);
>> > -v2 = xlaw2linear((i + 1) ^ mask);
>> > -v = (v1 + v2 + 4) >> 3;
>> > -} else {
>> > -v = 8192;
>> > -}
>> > -for(;j> > +j = 1;
>> > +linear_to_xlaw[8192] = mask;
>> > +for(i=0;i<127;i++) {
>> > +v1 = xlaw2linear(i ^ mask);
>> > +v2 = xlaw2linear((i + 1) ^ mask);
>> > +v = (v1 + v2 + 4) >> 3;
>> > +for(;j> > +linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>> >  linear_to_xlaw[8192 + j] = (i ^ mask);
>> > -if (j > 0)
>> > -linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>> >  }
>> >  }
>> > +for(;j<8192;j++) {
>> > +linear_to_xlaw[8192 - j] = (127 ^ (mask ^ 0x80));
>> > +linear_to_xlaw[8192 + j] = (127 ^ mask);
>> > +}
>> >  linear_to_xlaw[0] = linear_to_xlaw[1];
>>
>> i think you can make the tables 8 times smaller
>
> forget this, i should have checked the whole table or looked when i
> am awake ...

ha ha. By the way, both changes are needed to get this level of
speedup, with only the j change which you acked, the speedup is much
smaller. But then also note that the other parts of the patch also
increase the binary size more.

>
> [...]
>
> --
> 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
>
> ___
> 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] [RFC] Disable compile-time tablegen for cbrt if total cycle count < 200000

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 3:07 PM, Michael Niedermayer
 wrote:
> On Fri, Jan 01, 2016 at 08:07:39AM -0800, Ganesh Ajjanagadde wrote:
>> Hi all,
>>
>> Motivated by a remark by Ronald:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186200.html,
>> this is a request for comment on disabling compile time tablegen for
>> cbrt if the total cycle count < 20. Note that cbrt tables are only
>> used in aacdec.
>
> Its very hard to state a hard number as the threshold, this is quite
> subjective
> and different viewpoints would lead to different results
>
> but lets try anyway
> for the hardcoded table case more data needs to be read from disk
> ATM this is about 2mb for all tables
>
> for dynamic tables the used tables need to be generated
> theres a difference in binary size (table size vs code to generate it),
> that translates into a cost value (bytes * cycles_per_byte)
>
> and the dynamic init needs some time to build the table, thats
> conveniently already in cycles

Indeed; this was why it was easy to quantify the costs of dynamic init above.

>
> (above ignores alot, like HDDs, SDDs disk cache have different speed
>  hardcoded tables can be shared between processes but then rarely would
>  a process use all tables while the OS might end up loading all anyway
>  also we assume a load from cache while a OS might actually map tables
>  from the disk cache directly)
>
> now if the dynamic init is faster than loading the table from
> the disk cache then dynamic init is likely the better choice
>
> using cat into /dev/null i get about 2bytes per cycle
>
> also about START/STOP_TIMER, the decicyles are tens of cycles so
> one tenths of the displayed value is the amount of cpu cycles

Correct me if I am wrong, but I thought I did this above by dividing
the counter by 10.

>
> iam sure if one looks at this from a different angle a quite different
> threshold mathod and value could result

Yes, but here you ignore the table being used by what fraction of
files. --enable-hardcoded-tables as a whole is a ~15-20% size
increase. It is hard to impossible to separate the costs of what
happens here, i.e what files use what tables, when and what things are
loaded, etc. One may be unlucky to hit a page fault, or it may already
be present, who knows. It is thus highly variable.

Seems like you partially address this below. Unfortunately, the above
difficulties are coupled with the lack of ability to quantify the
"fraction of files that use a particular table". This obviously varies
by client use. For example, I have never used dsd myself, but I have
encountered aac frequently.

You have been very consistent and methodical about your responses and
stuck to technical matters, and I highly appreciate this. Thus, if you
wish to continue to keep the hard coded tables ifdefry here (and/or
elsewhere), please say so and I can stop this thread right now to
focus effort elsewhere. I will then continue to improve dynamic init,
but not bother about getting rid of the ifdefry and configure magic.
You may not be project leader, but in this matter, I would really like
a final judgement call from you: it will help give me some clarity.

>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Opposition brings concord. Out of discord comes the fairest harmony.
> -- Heraclitus
>
> ___
> 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] lavfi/vf_decimate: do not compare the first frame to itself.

[Carl Eugen Hoyos]

Nicolas George  nsup.org> writes:

> This is a waste of computing power and will result to 0,
> making it always dropped.
> Use maximum difference values instead.

Please commit.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/3] ffmdec: reset packet_end in case of failure

[Michael Niedermayer]

On Sat, Jan 02, 2016 at 07:43:03PM +0100, Andreas Cadhalpun wrote:
> On 02.01.2016 19:14, Michael Niedermayer wrote:
> > On Sat, Jan 02, 2016 at 04:51:17PM +0100, Andreas Cadhalpun wrote:
> >> This fixes segmentation faults caused by passing a packet_ptr of NULL to
> >> memcpy.
> >>
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavformat/ffmdec.c | 8 ++--
> >>  1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c
> >> index 9fe4155..7b2d0d7 100644
> >> --- a/libavformat/ffmdec.c
> >> +++ b/libavformat/ffmdec.c
> >> @@ -123,8 +123,10 @@ static int ffm_read_data(AVFormatContext *s,
> >>  frame_offset = avio_rb16(pb);
> >>  avio_read(pb, ffm->packet, ffm->packet_size - 
> >> FFM_HEADER_SIZE);
> >>  ffm->packet_end = ffm->packet + (ffm->packet_size - 
> >> FFM_HEADER_SIZE - fill_size);
> >> -if (ffm->packet_end < ffm->packet || frame_offset < 0)
> >> +if (ffm->packet_end < ffm->packet || frame_offset < 0) {
> >> +ffm->packet_end = ffm->packet_ptr;
> > 
> > doesnt this imply that packet_end was set to a invalid pointer?
> 
> Yes, if you use a strict definition of a valid pointer.
> (It could still point to a valid memory address, but from a different
> memory allocation than packet_ptr.)
> 
> By the way, the check for frame_offset < 0 is pointless, because
> avio_rb16 returns an unsigned int.
> 
> > (that is undefined behavior)
> 
> Yes, but ubsan didn't catch it. ;)
> 
> Anyway, attached is an updated patch avoiding this problem.
> 
> Best regards,
> Andreas

>  ffmdec.c |9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 1600298d54df3b7c7c74d4437521405b38342c60  
> 0001-ffmdec-reset-packet_end-in-case-of-failure.patch
> From a0faebf31ab37083e140c6d276b16dd024f97ffb Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Sat, 2 Jan 2016 16:27:02 +0100
> Subject: [PATCH 1/3] ffmdec: reset packet_end in case of failure
> 
> This fixes segmentation faults caused by passing a packet_ptr of NULL to
> memcpy.
> 
> Signed-off-by: Andreas Cadhalpun 

should be ok

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

[FFmpeg-devel] [PATCH]libavcodec/dca: Make decoding xll the default

[Carl Eugen Hoyos]

Hi!

Is there still something important missing?

Carl Eugen
diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
index 6b8d02d..4f8cf54 100644
--- a/libavcodec/dcadec.c
+++ b/libavcodec/dcadec.c
@@ -2038,7 +2038,7 @@ static av_cold int dca_decode_end(AVCodecContext *avctx)
 
 static const AVOption options[] = {
 { "disable_xch", "disable decoding of the XCh extension", 
offsetof(DCAContext, xch_disable), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_AUDIO_PARAM },
-{ "disable_xll", "disable decoding of the XLL extension", 
offsetof(DCAContext, xll_disable), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, 
AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_AUDIO_PARAM },
+{ "disable_xll", "disable decoding of the XLL extension", 
offsetof(DCAContext, xll_disable), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_AUDIO_PARAM },
 { NULL },
 };
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]libavcodec/dca: Make decoding xll the default

[Hendrik Leppkes]

On Sun, Jan 3, 2016 at 3:58 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Is there still something important missing?
>

Its still equally broken as it was when it was once commited - bugs
have not been fixed since then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]libavcodec/dca: Make decoding xll the default

[Carl Eugen Hoyos]

Hendrik Leppkes  gmail.com> writes:

> > Is there still something important missing?
> 
> Its still equally broken as it was when it was 
> once commited - bugs have not been fixed since 
> then.

Could you elaborate on (some of) the bugs, I 
was unable to find a report?

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 6:13 AM, Michael Niedermayer
 wrote:
> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
>> This gets rid of some branches to speed up table generation slightly
>> (impact higher on mulaw than alaw). Tables are identical to before,
>> tested with FATE.
>>
>> Sample benchmark (Haswell, GNU/Linux+gcc):
>> old:
>>  313494 decicycles in build_alaw_table,4094 runs,  2 skips
>>  315959 decicycles in build_alaw_table,8190 runs,  2 skips
>>
>>  323599 decicycles in build_ulaw_table,4095 runs,  1 skips
>>  318849 decicycles in build_ulaw_table,8188 runs,  4 skips
>>
>> new:
>>  261902 decicycles in build_alaw_table,4096 runs,  0 skips
>>  266519 decicycles in build_alaw_table,8192 runs,  0 skips
>>
>>  209657 decicycles in build_ulaw_table,4096 runs,  0 skips
>>  232656 decicycles in build_ulaw_table,8192 runs,  0 skips
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/pcm_tablegen.h | 24 
>>  1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavcodec/pcm_tablegen.h b/libavcodec/pcm_tablegen.h
>> index 1387210..7269977 100644
>> --- a/libavcodec/pcm_tablegen.h
>> +++ b/libavcodec/pcm_tablegen.h
>> @@ -87,21 +87,21 @@ static av_cold void build_xlaw_table(uint8_t 
>> *linear_to_xlaw,
>>  {
>>  int i, j, v, v1, v2;
>>
>> -j = 0;
>> -for(i=0;i<128;i++) {
>> -if (i != 127) {
>> -v1 = xlaw2linear(i ^ mask);
>> -v2 = xlaw2linear((i + 1) ^ mask);
>> -v = (v1 + v2 + 4) >> 3;
>> -} else {
>> -v = 8192;
>> -}
>> -for(;j> +j = 1;
>> +linear_to_xlaw[8192] = mask;
>> +for(i=0;i<127;i++) {
>> +v1 = xlaw2linear(i ^ mask);
>> +v2 = xlaw2linear((i + 1) ^ mask);
>> +v = (v1 + v2 + 4) >> 3;
>> +for(;j> +linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>>  linear_to_xlaw[8192 + j] = (i ^ mask);
>> -if (j > 0)
>> -linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>>  }
>>  }
>> +for(;j<8192;j++) {
>> +linear_to_xlaw[8192 - j] = (127 ^ (mask ^ 0x80));
>> +linear_to_xlaw[8192 + j] = (127 ^ mask);
>> +}
>
> removing the if(j>0) and replacing it by the direct init before
> is fine.
> do the other changes have any significnat speed effect ?
> i think they make the code harder to read and this is not really
> speed critical code

It is still "speed critical" enough for people to retain
CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
count down enough so that hardcoded tables can be removed here.

If patch 2 is fine as is, i.e if the current code is fast enough, than
I will just commit with the removal of if(j > 0).

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
>
> ___
> 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] lavfi/vf_decimate: do not compare the first frame to itself.

[Nicolas George]

Le quartidi 14 nivôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> I am not convinced your patch fixes every issue but it 
> definitely improves the current code.

Ok, pushed.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #4990 for me, I tested the following 
command line:
$ ffmpeg -loglevel debug -i bugged.avi -vf fieldmatch,decimate -f null -

The first frames show the following debug output:
before:
[Parsed_decimate_0 @ 0x329e160] 1/5 frame drop:
[Parsed_decimate_0 @ 0x329e160]   #1: totdiff=7fff 
maxbdiff=7fff sc [DROP]
[Parsed_decimate_0 @ 0x329e160]   #2: totdiff=00ca660c maxbdiff=000130d8
[Parsed_decimate_0 @ 0x329e160]   #3: totdiff=015715f3 maxbdiff=00022e12
[Parsed_decimate_0 @ 0x329e160]   #4: totdiff=00c6e459 maxbdiff=0001df5b
[Parsed_decimate_0 @ 0x329e160]   #5: totdiff=000d4fce maxbdiff=0d05 
lowest

after:
[Parsed_decimate_1 @ 0x2714720] 1/5 frame drop:
[Parsed_decimate_1 @ 0x2714720]   #1: totdiff=04ba4100 
maxbdiff=7fff
[Parsed_decimate_1 @ 0x2714720]   #2: totdiff=00ca660c maxbdiff=000130d8
[Parsed_decimate_1 @ 0x2714720]   #3: totdiff=015715f3 maxbdiff=00022e12
[Parsed_decimate_1 @ 0x2714720]   #4: totdiff=00c6e459 maxbdiff=0001df5b
[Parsed_decimate_1 @ 0x2714720]   #5: totdiff=000d4fce maxbdiff=0d05 
lowest [DROP]

With the patch, the frame with the lowest diff is actually dropped 
instead of the first frame that indicates a scene change without 
the patch (iiuc).

Please review, Carl Eugen
diff --git a/libavfilter/vf_decimate.c b/libavfilter/vf_decimate.c
index 8b950b4..91c6d7f 100644
--- a/libavfilter/vf_decimate.c
+++ b/libavfilter/vf_decimate.c
@@ -169,7 +169,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 prv = dm->fid ? dm->queue[dm->fid - 1].frame : dm->last;
 if (!prv) {
 dm->queue[dm->fid].maxbdiff = INT64_MAX;
-dm->queue[dm->fid].totdiff  = INT64_MAX;
+dm->queue[dm->fid].totdiff  = dm->scthresh;
 } else {
 calc_diffs(dm, >queue[dm->fid], prv, in);
 }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Michael Niedermayer]

On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> This gets rid of some branches to speed up table generation slightly
> (impact higher on mulaw than alaw). Tables are identical to before,
> tested with FATE.
> 
> Sample benchmark (Haswell, GNU/Linux+gcc):
> old:
>  313494 decicycles in build_alaw_table,4094 runs,  2 skips
>  315959 decicycles in build_alaw_table,8190 runs,  2 skips
> 
>  323599 decicycles in build_ulaw_table,4095 runs,  1 skips
>  318849 decicycles in build_ulaw_table,8188 runs,  4 skips
> 
> new:
>  261902 decicycles in build_alaw_table,4096 runs,  0 skips
>  266519 decicycles in build_alaw_table,8192 runs,  0 skips
> 
>  209657 decicycles in build_ulaw_table,4096 runs,  0 skips
>  232656 decicycles in build_ulaw_table,8192 runs,  0 skips
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/pcm_tablegen.h | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/pcm_tablegen.h b/libavcodec/pcm_tablegen.h
> index 1387210..7269977 100644
> --- a/libavcodec/pcm_tablegen.h
> +++ b/libavcodec/pcm_tablegen.h
> @@ -87,21 +87,21 @@ static av_cold void build_xlaw_table(uint8_t 
> *linear_to_xlaw,
>  {
>  int i, j, v, v1, v2;
>  
> -j = 0;
> -for(i=0;i<128;i++) {
> -if (i != 127) {
> -v1 = xlaw2linear(i ^ mask);
> -v2 = xlaw2linear((i + 1) ^ mask);
> -v = (v1 + v2 + 4) >> 3;
> -} else {
> -v = 8192;
> -}
> -for(;j +j = 1;
> +linear_to_xlaw[8192] = mask;
> +for(i=0;i<127;i++) {
> +v1 = xlaw2linear(i ^ mask);
> +v2 = xlaw2linear((i + 1) ^ mask);
> +v = (v1 + v2 + 4) >> 3;
> +for(;j +linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>  linear_to_xlaw[8192 + j] = (i ^ mask);
> -if (j > 0)
> -linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>  }
>  }
> +for(;j<8192;j++) {
> +linear_to_xlaw[8192 - j] = (127 ^ (mask ^ 0x80));
> +linear_to_xlaw[8192 + j] = (127 ^ mask);
> +}

removing the if(j>0) and replacing it by the direct init before
is fine.
do the other changes have any significnat speed effect ?
i think they make the code harder to read and this is not really
speed critical code

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] lavfi/vf_decimate: do not compare the first frame to itself.

[Nicolas George]

Le quartidi 14 nivôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> Please commit.

Last news were you saying that this patch did not fix anything. Is there an
update?

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH]lavfi/drawtext: Fix microsecond display

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #4792 for me, please comment.

Carl Eugen
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index e96bfb6..1ef3ecb 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -824,7 +824,7 @@ static int func_pts(AVFilterContext *ctx, AVBPrint *bp,
(int)(ms / (60 * 60 * 1000)),
(int)(ms / (60 * 1000)) % 60,
(int)(ms / 1000) % 60,
-   (int)ms % 1000);
+   (int)(ms % 1000));
 }
 } else if (!strcmp(fmt, "localtime") ||
!strcmp(fmt, "gmtime")) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/vf_decimate: do not compare the first frame to itself.

[Carl Eugen Hoyos]

Nicolas George  nsup.org> writes:

> Le quartidi 14 nivôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> > Please commit.
> 
> Last news were you saying that this patch did not fix 
> anything. Is there an update?

I am not convinced your patch fixes every issue but it 
definitely improves the current code.

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

Re: [FFmpeg-devel] [PATCH] libavcodec/ccaption_dec: remove unnecessary buffering of closed caption packets

[Clément Bœsch]

On Fri, Jan 01, 2016 at 04:40:06PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> CC data is fed to in small chunks (usually 60 bytes at a time)
> and is parsed fully by the eia608 decoder. There is no reason to copy it
> into a secondary buffer first.
> ---
>  libavcodec/ccaption_dec.c | 22 +-
>  1 file changed, 1 insertion(+), 21 deletions(-)
> 
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index 9f67caa..4b1d376 100644
> --- a/libavcodec/ccaption_dec.c
> +++ b/libavcodec/ccaption_dec.c
> @@ -167,8 +167,6 @@ typedef struct CCaptionSubContext {
>  int64_t startv_time;
>  int64_t end_time;
>  char prev_cmd[2];
> -/* buffer to store pkt data */
> -AVBufferRef *pktbuf;
>  }CCaptionSubContext;
>  
>  
> @@ -185,11 +183,6 @@ static av_cold int init_decoder(AVCodecContext *avctx)
>  if(ret < 0) {
>  return ret;
>  }
> -/* allocate pkt buffer */
> -ctx->pktbuf = av_buffer_alloc(128);
> -if( !ctx->pktbuf) {
> -ret = AVERROR(ENOMEM);
> -}
>  return ret;
>  }
>  
> @@ -197,7 +190,6 @@ static av_cold int close_decoder(AVCodecContext *avctx)
>  {
>  CCaptionSubContext *ctx = avctx->priv_data;
>  av_bprint_finalize( >buffer, NULL);
> -av_buffer_unref(>pktbuf);
>  return 0;
>  }
>  
> @@ -524,23 +516,11 @@ static int decode(AVCodecContext *avctx, void *data, 
> int *got_sub, AVPacket *avp
>  {
>  CCaptionSubContext *ctx = avctx->priv_data;
>  AVSubtitle *sub = data;
> -uint8_t *bptr = NULL;
> +uint8_t *bptr = avpkt->data;
>  int len = avpkt->size;
>  int ret = 0;
>  int i;
>  
> -if ( ctx->pktbuf->size < len) {
> -ret = av_buffer_realloc(>pktbuf, len);
> - if(ret < 0) {
> -av_log(ctx, AV_LOG_WARNING, "Insufficient Memory of %d truncated 
> to %d\n",len, ctx->pktbuf->size);
> -len = ctx->pktbuf->size;
> -ret = 0;
> -}
> -}
> -memcpy(ctx->pktbuf->data, avpkt->data, len);
> -bptr = ctx->pktbuf->data;
> -
> -
>  for (i  = 0; i < len; i += 3) {
>  uint8_t cc_type = *(bptr + i) & 3;
>  if (validate_cc_data_pair( bptr + i) )

This indeed LGTM, but I'm not the maintainer.

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] avcodec/h264: Fix regression caused by removial of default_ref_list

[Michael Niedermayer]

From: Michael Niedermayer 

This fixes a regression of the sample from Ticket 2371

Signed-off-by: Michael Niedermayer 
---
 libavcodec/h264.h  |1 +
 libavcodec/h264_refs.c |   11 +--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index 5d9aecd..a5fc3a0 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -669,6 +669,7 @@ typedef struct H264Context {
  */
 int max_pic_num;
 
+H264Ref default_ref[2];
 H264Picture *short_ref[32];
 H264Picture *long_ref[32];
 H264Picture *delayed_pic[MAX_DELAYED_PIC_COUNT + 2]; // FIXME size?
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index 52fedc1..f42d6a2 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -208,6 +208,8 @@ static void h264_initialise_ref_list(H264Context *h, 
H264SliceContext *sl)
 }
 }
 }
+for (i = 0; i < sl->list_count; i++)
+h->default_ref[i] = sl->ref_list[i][0];
 }
 
 static void print_short_term(H264Context *h);
@@ -351,10 +353,14 @@ int ff_h264_decode_ref_pic_list_reordering(H264Context 
*h, H264SliceContext *sl)
 if (   !sl->ref_list[list][index].parent
 || (!FIELD_PICTURE(h) && 
(sl->ref_list[list][index].reference&3) != 3)) {
 int i;
-av_log(h->avctx, AV_LOG_ERROR, "Missing reference picture\n");
+av_log(h->avctx, AV_LOG_ERROR, "Missing reference picture, 
default is %d\n", h->default_ref[list].poc);
 for (i = 0; i < FF_ARRAY_ELEMS(h->last_pocs); i++)
 h->last_pocs[i] = INT_MIN;
-return -1;
+if (h->default_ref[list].parent
+&& !(!FIELD_PICTURE(h) && 
(h->default_ref[list].reference&3) != 3))
+sl->ref_list[list][index] = h->default_ref[list];
+else
+return -1;
 }
 
av_assert0(av_buffer_get_ref_count(sl->ref_list[list][index].parent->f->buf[0]) 
> 0);
 }
@@ -524,6 +530,7 @@ void ff_h264_remove_all_refs(H264Context *h)
 }
 h->short_ref_count = 0;
 
+memset(h->default_ref, 0, sizeof(h->default_ref));
 for (i = 0; i < h->nb_slice_ctx; i++) {
 H264SliceContext *sl = >slice_ctx[i];
 sl->list_count = sl->ref_count[0] = sl->ref_count[1] = 0;
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: simplify parity check

[Clément Bœsch]

On Sun, Jan 03, 2016 at 06:53:34PM +0100, Clément Bœsch wrote:
> On Sun, Jan 03, 2016 at 05:43:26PM +, Derek Buitenhuis wrote:
> > On 1/3/2016 5:33 PM, Clément Bœsch wrote:
> > > +return (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1;
> > 
> > I mean, I see how it works, but it's incredibly non-obvious without the
> > patch context (table removal).
> > 
> 
> Any suggestion? Maybe a comment? Or you prefer the 32 lines table of 256
> bytes to store 256 redundant bits of information?
> 
> The name of the function gives the context here, if you look up the web
> for "bit parity" you'll get what you are looking for. I'm not sure the
> table is much more obvious about what's this parity is all about.
> 

Now that I think a bit about, I could just do return av_popcount(x) & 1...

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '741b494fa8cd28a7d096349bac183893c236e3f9'"

[Michael Niedermayer]

On Sat, Jan 02, 2016 at 06:20:53PM +0100, Hendrik Leppkes wrote:
> On Sat, Dec 19, 2015 at 10:35 AM, Michael Niedermayer
>  wrote:
> > On Thu, Dec 17, 2015 at 02:46:40PM +0100, Hendrik Leppkes wrote:
> >> On Thu, Dec 17, 2015 at 2:06 PM, Michael Niedermayer  
> >> wrote:
> >> > From: Michael Niedermayer 
> >> >
> >> > This fixes a regression of the sample from Ticket 2371
> >> >
> >> > This reverts commit bc66451e5e903698ee0500faf04c1214f3dd157f, reversing
> >> > changes made to 9d1fb9ef313e0fb709ac4c35c7bf00264963fd85.
> >> > ---
> >> >  libavcodec/h264.h   |8 +++
> >> >  libavcodec/h264_refs.c  |   57 
> >> > ++-
> >> >  libavcodec/h264_slice.c |   17 +-
> >> >  3 files changed, 56 insertions(+), 26 deletions(-)
> >>
> >> Reverting big commits to fix one sample and making future merges
> >> harder or impossible seems not like the best option, unless it can be
> >> shown that the entire change is flawed, and not just a small bug.
> >> Otherwise, it should be attempted to fix regressions the usual way -
> >> by fixing things, not reverting.
> >>
> >> Once reverted, the change will never come back, we all know that.
> >>
> >> At least thats IMHO. You are the maintainer of the H264 decoder, so if
> >> you want to revert it, feel free.
> >
> > Calculatig the default ref seems to take between 800 and 4700 or so
> > cpu cycles (messured with fate & START_TIMER)
> >
> > tests/data/fate/filter-paletteuse-sierra2_4a.err:  46958 decicycles in 
> > h264_initialise_ref_list,  64 runs,  0 skips
> > tests/data/fate/h264-conformance-caba3_sony_c.err:  26963 decicycles in 
> > h264_initialise_ref_list, 256 runs,  0 skips
> > tests/data/fate/h264-conformance-frext-hcafr4_hhi_a.err:  29306 decicycles 
> > in h264_initialise_ref_list,  15 runs,  1 skips
> > tests/data/fate/h264-conformance-sva_cl1_e.err:   7956 decicycles in 
> > h264_initialise_ref_list, 128 runs,  0 skips
> > ...
> >
> > with the default lists the time spend in Calculating them after the
> > first slice and including the checks needed to find out if they need
> > to be recalculated seem to be always below 500 cycles in fate
> >
> > tests/data/fate/h264-conformance-cvnlfi1_sony_c.err:   4196 decicycles in 
> > CMP, 256 runs,  0 skips
> > tests/data/fate/h264-conformance-cvfi1_sony_d.err:   3976 decicycles in 
> > CMP, 128 runs,  0 skips
> > tests/data/fate/h264-conformance-cvfi1_sony_d.err:   4142 decicycles in 
> > CMP, 256 runs,  0 skips
> > tests/data/fate/h264-conformance-basqp1_sony_c.err:381 decicycles in 
> > CMP, 128 runs,  0 skips
> > tests/data/fate/h264-conformance-cvnlfi2_sony_h.err:   3757 decicycles in 
> > CMP, 128 runs,  0 skips
> > tests/data/fate/h264-conformance-cvnlfi2_sony_h.err:   3687 decicycles in 
> > CMP, 256 runs,  0 skips
> > tests/data/fate/h264-conformance-ci1_ft_b.err:   4588 decicycles in CMP,
> >  128 runs,  0 skips
> > tests/data/fate/h264-conformance-ci1_ft_b.err:   4754 decicycles in CMP,
> >  256 runs,  0 skips
> > tests/data/fate/h264-conformance-cvfc1_sony_c.err:   4146 decicycles in 
> > CMP, 128 runs,  0 skips
> > tests/data/fate/h264-conformance-cabaci3_sony_b.err:   2739 decicycles in 
> > CMP, 128 runs,  0 skips
> > tests/data/fate/h264-conformance-cabaci3_sony_b.err:   2732 decicycles in 
> > CMP, 256 runs,  0 skips
> > tests/data/fate/h264-conformance-cabaci3_sony_b.err:   2878 decicycles in 
> > CMP, 512 runs,  0 skips
> > tests/data/fate/h264-conformance-ba1_ft_c.err:   4266 decicycles in CMP,
> >  128 runs,  0 skips
> > tests/data/fate/h264-conformance-ba1_ft_c.err:   4358 decicycles in CMP,
> >  256 runs,  0 skips
> > tests/data/fate/h264-conformance-cvfi2_sony_h.err:   4347 decicycles in 
> > CMP, 128 runs,  0 skips
> > tests/data/fate/h264-conformance-cvfi2_sony_h.err:   4179 decicycles in 
> > CMP, 256 runs,  0 skips
> >
> > its possible the extra list causes harder to meassure slowdowns
> > elsewhere of course (cache hit/miss ratio, more fields in the context,
> > whatever)
> >
> > but for files with many small slices recalculating the same list
> > for each seems a waste of time to me.
> >
> > i also suspect that libav had a bug in their default ref list
> > code or at least their checks look less complete than ours prior
> > to the removial in both trees
> >
> > I think the decission about which way to go here should be yours
> > as you might (or might not) be affected by this causing extra work
> > in the future
> >
> 
> Libavs patch doesn't actually fix the sample, and considering there
> may be a slowdown, revert is fine with me. Its not like H264 is going
> to change substantially in the future.

ive posted an alternative patch if people prefer not to reintroduce
the default list or rather it 

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[Hendrik Leppkes]

On Sun, Jan 3, 2016 at 6:49 PM, foo86  wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
>
> Any comments about the code are appreciated, as well as suggestions concerning
> how should I proceed with this patch. Should I aim for including it as a
> separate decoder or a replacement for existing DCA decoder? Or it might be 
> that
> you prefer to continue improving existing decoder instead and not merge this 
> at
> all.

Having two dca decoders with varying degrees of features is no
advantages, and considering the native decoder lacks a long list of
features and fails decoding a bunch of XLL streams, the aim should be
to replace.
I'm not aware of a single advantage of the old decoder, so...

>
> Attached decoder is feature complete enough to fully decode any practically
> available DTS stream configuration. It supports any possible combinations of
> XCH, XXCH, XBR and X96 core extensions to deliver up to 7.1 ch, 96 kHz 
> floating
> point output. It also implements lossless decoding of XLL extension to deliver
> up to 7.1 ch, 192 kHz fixed point output. Bit rate managed XLL streams are
> supported. Downmixing to 5.1 and stereo using embedded coefficients is
> supported.

I have been using libdcadec through the library wrapper in ffmpeg for
a while now, and I am not aware of any file that doesn't decode
properly today, so yes, I tend to agree.
Other people will probably want to apply fuzz testing, I'm not sure
how much you have done to this degree.

>
> Performance wise, this decoder used to be around 10% slower than pure floating
> point version of existing native DCA decoder. However, after native DCA 
> decoder
> has been partially converted to fixed point, this decoder became 5% faster 
> than
> native one. Measurements were done looping over 5.1 core only stream in
> floating point mode on a x86_64 system. Of course, decoding extensions like 
> X96
> and XLL makes the decoder much slower. These can be ignored with -core_only
> option.

Trying to get some extra functionality into SIMD-able functions would
be a good goal for later, but even the previous decoder doesn't have
that much.
So something for later.

>
> The libdcadec code this decoder is based on has been rather well tested and
> stable, thus I don't expect any fundamental issues with this new decoder. I
> might have introduced some bugs during porting; these should be hopefully 
> found
> by regression tests and fixed. Note that I've not run this decoder through any
> serious regression testing yet, I just checked that it works on several select
> samples.
>
> This decoder depends on assembly versions of existing native dcadsp, however 
> it
> only uses assembly optimized version of synth_filter currently. Because
> synth_filter implicitly depends on dcadsp this is required to allow decoder to
> build when existing DCA decoder is disabled. I plan to overhaul this area
> (interacting with existing dcadsp) later.
>

Out of curiousity, do you plan to continue developing the external
library, or would you abandon it if its merged?
And more directly, I would hope we can also count on basic maintenance
of the new decoder in ffmpeg? :)

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

Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: simplify parity check

[Carl Eugen Hoyos]

Clément Bœsch  pkh.me> writes:

> -if (!parity_table[cc_data_pair[2]]) {
> +if (!get_parity(cc_data_pair[2]))

I this slower or faster than before the patch?

Replacing it with popcount seems ok either way 
imo.

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

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[James Almer]

On 1/3/2016 2:49 PM, foo86 wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
> 
> Any comments about the code are appreciated, as well as suggestions concerning
> how should I proceed with this patch. Should I aim for including it as a
> separate decoder or a replacement for existing DCA decoder? Or it might be 
> that
> you prefer to continue improving existing decoder instead and not merge this 
> at
> all.

IMO this should replace the current dca decoder. Based on what i saw from 
libdcadec
yours is cleaner, more feature complete, you're a knowledgeable maintainer, and
since the current developer for ffdca over at libav is porting code from yours 
to
get bitexact xll working the code duplication would be considerable if we keep 
both.

> 
> Attached decoder is feature complete enough to fully decode any practically
> available DTS stream configuration. It supports any possible combinations of
> XCH, XXCH, XBR and X96 core extensions to deliver up to 7.1 ch, 96 kHz 
> floating
> point output. It also implements lossless decoding of XLL extension to deliver
> up to 7.1 ch, 192 kHz fixed point output. Bit rate managed XLL streams are
> supported. Downmixing to 5.1 and stereo using embedded coefficients is
> supported.
> 
> Performance wise, this decoder used to be around 10% slower than pure floating
> point version of existing native DCA decoder. However, after native DCA 
> decoder
> has been partially converted to fixed point, this decoder became 5% faster 
> than
> native one. Measurements were done looping over 5.1 core only stream in

Another reason to have this replace the current one, then.

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

Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: simplify parity check

[Kieran Kunhya]

On 3 January 2016 at 18:17, Carl Eugen Hoyos  wrote:
> Clément Bœsch  pkh.me> writes:
>
>> -if (!parity_table[cc_data_pair[2]]) {
>> +if (!get_parity(cc_data_pair[2]))

I doubt this is speed critical.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Derek Buitenhuis]

It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. Both stagefright itself, and MediaCodec, have
avcodec backends already, and this is the correct way to use it.
MediaCodec as a proper JNI API.

Furthermore, stagefright support in avcodec needs a series of
magic incantations and version-specific stuff, such that
using it actually provides downsides compared just using the actual
Android frameworks properly, in that it is a lot more work and confusion
to get it even running. It also leads to a lot of misinformation, like
these sorts of comments (in [1]) that are absolutely incorrect.

[1] http://stackoverflow.com/a/29362353/3115956

Signed-off-by: Derek Buitenhuis 
---
I am certain there are many more reasons to remvoe this as well. I know
its own author despises it, and I know j-b will same things to say.

I have CC'd the person listed in MAINTAINERS for this set of code as well.

Please discuss, and keep discourse civil and avoid ad hominems, etc.
---
 MAINTAINERS   |   1 -
 configure |   6 -
 libavcodec/Makefile   |   1 -
 libavcodec/allcodecs.c|   1 -
 libavcodec/libstagefright.cpp | 591 --
 libavcodec/version.h  |   2 +-
 tools/build_libstagefright|  58 -
 7 files changed, 1 insertion(+), 659 deletions(-)
 delete mode 100644 libavcodec/libstagefright.cpp
 delete mode 100644 tools/build_libstagefright

diff --git a/MAINTAINERS b/MAINTAINERS
index 9add13d..b62a4f8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -304,7 +304,6 @@ Codecs:
 Hardware acceleration:
   crystalhd.c   Philip Langdale
   dxva2*Hendrik Leppkes, Laurent Aimar
-  libstagefright.cppMohamed Naufal
   vaapi*Gwenole Beauchesne
   vda*  Sebastien Zwickert
   vdpau*Philip Langdale, Carl Eugen Hoyos
diff --git a/configure b/configure
index 6710f85..4d6d4fc 100755
--- a/configure
+++ b/configure
@@ -250,7 +250,6 @@ External library support:
   --enable-libsoxr enable Include libsoxr resampling [no]
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
-  --enable-libstagefright-h264  enable H.264 decoding via libstagefright [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
@@ -1478,7 +1477,6 @@ EXTERNAL_LIBRARY_LIST="
 libsoxr
 libspeex
 libssh
-libstagefright_h264
 libtesseract
 libtheora
 libtwolame
@@ -2639,7 +2637,6 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
-libstagefright_h264_decoder_deps="libstagefright_h264"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_aacenc_encoder_deps="libvo_aacenc"
@@ -5476,9 +5473,6 @@ enabled libsnappy && require snappy snappy-c.h 
snappy_compress -lsnappy
 enabled libsoxr   && require libsoxr soxr.h soxr_create -lsoxr && 
LIBSOXR="-lsoxr"
 enabled libssh&& require_pkg_config libssh libssh/sftp.h sftp_init
 enabled libspeex  && require_pkg_config speex speex/speex.h 
speex_decoder_init -lspeex
-enabled libstagefright_h264 && require_cpp libstagefright_h264 
"binder/ProcessState.h media/stagefright/MetaData.h
-media/stagefright/MediaBufferGroup.h media/stagefright/MediaDebug.h 
media/stagefright/MediaDefs.h
-media/stagefright/OMXClient.h media/stagefright/OMXCodec.h" 
android::OMXClient -lstagefright -lmedia -lutils -lbinder -lgnustl_static
 enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
 enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a18ca5b..b9ffdb9 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -829,7 +829,6 @@ OBJS-$(CONFIG_LIBSCHROEDINGER_ENCODER)+= 
libschroedingerenc.o \
 OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
-OBJS-$(CONFIG_LIBSTAGEFRIGHT_H264_DECODER)+= libstagefright.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBUTVIDEO_DECODER) += libutvideodec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 

Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: simplify parity check

[Derek Buitenhuis]

On 1/3/2016 6:05 PM, Clément Bœsch wrote:
> Now that I think a bit about, I could just do return av_popcount(x) & 1...

Sounds like a plan.

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

Re: [FFmpeg-devel] [PATCH 1/3] get_bits: add get_bitsz for reading 0-25 bits

[Andreas Cadhalpun]

On 03.01.2016 02:03, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 01:35:39AM +0100, Andreas Cadhalpun wrote:
>> --- a/libavcodec/get_bits.h
>> +++ b/libavcodec/get_bits.h
>> @@ -269,6 +269,14 @@ static inline unsigned int get_bits(GetBitContext *s, 
>> int n)
>>  return tmp;
>>  }
>>  
>> +/**
>> + * Read 0-25 bits.
>> + */
> 
>> +static inline int get_bitsz(GetBitContext *s, int n)
> 
> just realized when looking at the code this replaces, this should be
> always_inline possibly

OK, changed inline to av_always_inline.

On 03.01.2016 02:26, Luca Barbato wrote:
> On 03/01/16 01:36, Andreas Cadhalpun wrote:
>> -/* handle n = 0 too */
>> -static inline int get_bitsz(GetBitContext *s, int n)
>> -{
>> -return n ? get_bits(s, n) : 0;
>> -}
>> -
>> -
> 
> If you want to go the extra mile you might move this hunk in the first patch, 
> beside that seems fine.

Done.

Updated patches attached.

Best regards,
Andreas
>From 50cc356a559e55657e9d90ed4c7fc2ba3e50551a Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Sun, 3 Jan 2016 00:28:42 +0100
Subject: [PATCH 1/2] get_bits: add get_bitsz for reading 0-25 bits

This can be used to simplify code in a couple of places.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/get_bits.h  | 8 
 libavcodec/mpegaudiodec_template.c | 7 ---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 0a61c80..4cf61d6 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -269,6 +269,14 @@ static inline unsigned int get_bits(GetBitContext *s, int n)
 return tmp;
 }
 
+/**
+ * Read 0-25 bits.
+ */
+static av_always_inline int get_bitsz(GetBitContext *s, int n)
+{
+return n ? get_bits(s, n) : 0;
+}
+
 static inline unsigned int get_bits_le(GetBitContext *s, int n)
 {
 register int tmp;
diff --git a/libavcodec/mpegaudiodec_template.c b/libavcodec/mpegaudiodec_template.c
index d2420c1..5e3fe7e 100644
--- a/libavcodec/mpegaudiodec_template.c
+++ b/libavcodec/mpegaudiodec_template.c
@@ -816,13 +816,6 @@ static void exponents_from_scale_factors(MPADecodeContext *s, GranuleDef *g,
 }
 }
 
-/* handle n = 0 too */
-static inline int get_bitsz(GetBitContext *s, int n)
-{
-return n ? get_bits(s, n) : 0;
-}
-
-
 static void switch_buffer(MPADecodeContext *s, int *pos, int *end_pos,
   int *end_pos2)
 {
-- 
2.6.4

>From b3d5a2383264b98582a3f96132e72cd085a3f187 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Sun, 3 Jan 2016 01:19:23 +0100
Subject: [PATCH 2/2] lavc: use get_bitsz to simplify the code

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/atrac3plus.c | 13 +
 libavcodec/escape124.c  |  2 +-
 libavcodec/hevc.c   |  2 +-
 libavcodec/hevc_parser.c|  2 +-
 libavcodec/wavpack.c|  2 +-
 libavcodec/wmalosslessdec.c |  7 +++
 libavcodec/wmaprodec.c  |  2 +-
 7 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/libavcodec/atrac3plus.c b/libavcodec/atrac3plus.c
index b16a139..46e0bea 100644
--- a/libavcodec/atrac3plus.c
+++ b/libavcodec/atrac3plus.c
@@ -39,9 +39,6 @@ static VLC spec_vlc_tabs[112];
 static VLC gain_vlc_tabs[11];
 static VLC tone_vlc_tabs[7];
 
-#define GET_DELTA(gb, delta_bits) \
-((delta_bits) ? get_bits((gb), (delta_bits)) : 0)
-
 /**
  * Generate canonical VLC table from given descriptor.
  *
@@ -384,7 +381,7 @@ static int decode_channel_wordlen(GetBitContext *gb, Atrac3pChanUnitCtx *ctx,
 chan->qu_wordlen[i] = get_bits(gb, 3);
 
 for (i = pos; i < chan->num_coded_vals; i++)
-chan->qu_wordlen[i] = (min_val + GET_DELTA(gb, delta_bits)) & 7;
+chan->qu_wordlen[i] = (min_val + get_bitsz(gb, delta_bits)) & 7;
 }
 }
 break;
@@ -516,7 +513,7 @@ static int decode_channel_sf_idx(GetBitContext *gb, Atrac3pChanUnitCtx *ctx,
 /* all others are: min_val + delta */
 for (i = num_long_vals; i < ctx->used_quant_units; i++)
 chan->qu_sf_idx[i] = (chan->qu_sf_idx[i] + min_val +
-  GET_DELTA(gb, delta_bits)) & 0x3F;
+  get_bitsz(gb, delta_bits)) & 0x3F;
 } else {
 num_long_vals = get_bits(gb, 5);
 delta_bits= get_bits(gb, 3);
@@ -534,7 +531,7 @@ static int decode_channel_sf_idx(GetBitContext *gb, Atrac3pChanUnitCtx *ctx,
 /* all others are: min_val + delta */
 for (i = num_long_vals; i < ctx->used_quant_units; i++)
 chan->qu_sf_idx[i] = (min_val +
-  GET_DELTA(gb, delta_bits)) & 0x3F;
+  get_bitsz(gb, delta_bits)) & 0x3F;

Re: [FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Derek Buitenhuis]

On 1/3/2016 3:11 PM, Carl Eugen Hoyos wrote:
> With the patch, the frame with the lowest diff is actually dropped 
> instead of the first frame that indicates a scene change without 
> the patch (iiuc).

Is this for all scene changes or just frame 0? If for all scene changes, ignore
the lower comment.

> -dm->queue[dm->fid].totdiff  = INT64_MAX;
> +dm->queue[dm->fid].totdiff  = dm->scthresh;


Upstream uses +1 here, but I'm not sure why:

https://github.com/vapoursynth/vapoursynth/blob/master/src/filters/vivtc/vivtc.c#L1294

Any insights?

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[wm4]

On Sun,  3 Jan 2016 13:37:18 -0500
Derek Buitenhuis  wrote:

> It serves absolutely no purpose other than to confuse potentional
> Android developers about how to use hardware acceleration properly
> on the the platform. Both stagefright itself, and MediaCodec, have
> avcodec backends already, and this is the correct way to use it.
> MediaCodec as a proper JNI API.
> 
> Furthermore, stagefright support in avcodec needs a series of
> magic incantations and version-specific stuff, such that
> using it actually provides downsides compared just using the actual
> Android frameworks properly, in that it is a lot more work and confusion
> to get it even running. It also leads to a lot of misinformation, like
> these sorts of comments (in [1]) that are absolutely incorrect.
> 
> [1] http://stackoverflow.com/a/29362353/3115956
> 
> Signed-off-by: Derek Buitenhuis 
> ---
> I am certain there are many more reasons to remvoe this as well. I know
> its own author despises it, and I know j-b will same things to say.
> 
> I have CC'd the person listed in MAINTAINERS for this set of code as well.
> 
> Please discuss, and keep discourse civil and avoid ad hominems, etc.
> ---

+1

Yes, we should probably have Android support, but then we should use
the preferred APIs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[wm4]

On Sun, 3 Jan 2016 20:49:10 +0300
foo86  wrote:

> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
> 
> Any comments about the code are appreciated, as well as suggestions concerning
> how should I proceed with this patch. Should I aim for including it as a
> separate decoder or a replacement for existing DCA decoder? Or it might be 
> that
> you prefer to continue improving existing decoder instead and not merge this 
> at
> all.

Maybe we could have a vote whether or not the existing builtin decoder
should be replaced with this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Rostislav Pehlivanov]

Yes, considering the security vulnerabilities in stagefright, the reported
underuse, confusion and the fact that the Android framework already
provides a proper native API to do hardware and software (though plugins)
decoding, I see no reason why this should not be dropped from Git master
and the next stable release.

+1

On 3 January 2016 at 18:37, Derek Buitenhuis 
wrote:

> It serves absolutely no purpose other than to confuse potentional
> Android developers about how to use hardware acceleration properly
> on the the platform. Both stagefright itself, and MediaCodec, have
> avcodec backends already, and this is the correct way to use it.
> MediaCodec as a proper JNI API.
>
> Furthermore, stagefright support in avcodec needs a series of
> magic incantations and version-specific stuff, such that
> using it actually provides downsides compared just using the actual
> Android frameworks properly, in that it is a lot more work and confusion
> to get it even running. It also leads to a lot of misinformation, like
> these sorts of comments (in [1]) that are absolutely incorrect.
>
> [1] http://stackoverflow.com/a/29362353/3115956
>
> Signed-off-by: Derek Buitenhuis 
> ---
> I am certain there are many more reasons to remvoe this as well. I know
> its own author despises it, and I know j-b will same things to say.
>
> I have CC'd the person listed in MAINTAINERS for this set of code as well.
>
> Please discuss, and keep discourse civil and avoid ad hominems, etc.
> ---
>  MAINTAINERS   |   1 -
>  configure |   6 -
>  libavcodec/Makefile   |   1 -
>  libavcodec/allcodecs.c|   1 -
>  libavcodec/libstagefright.cpp | 591
> --
>  libavcodec/version.h  |   2 +-
>  tools/build_libstagefright|  58 -
>  7 files changed, 1 insertion(+), 659 deletions(-)
>  delete mode 100644 libavcodec/libstagefright.cpp
>  delete mode 100644 tools/build_libstagefright
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9add13d..b62a4f8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -304,7 +304,6 @@ Codecs:
>  Hardware acceleration:
>crystalhd.c   Philip Langdale
>dxva2*Hendrik Leppkes, Laurent Aimar
> -  libstagefright.cppMohamed Naufal
>vaapi*Gwenole Beauchesne
>vda*  Sebastien Zwickert
>vdpau*Philip Langdale, Carl Eugen Hoyos
> diff --git a/configure b/configure
> index 6710f85..4d6d4fc 100755
> --- a/configure
> +++ b/configure
> @@ -250,7 +250,6 @@ External library support:
>--enable-libsoxr enable Include libsoxr resampling [no]
>--enable-libspeexenable Speex de/encoding via libspeex [no]
>--enable-libssh  enable SFTP protocol via libssh [no]
> -  --enable-libstagefright-h264  enable H.264 decoding via libstagefright
> [no]
>--enable-libtesseractenable Tesseract, needed for ocr filter [no]
>--enable-libtheora   enable Theora encoding via libtheora [no]
>--enable-libtwolame  enable MP2 encoding via libtwolame [no]
> @@ -1478,7 +1477,6 @@ EXTERNAL_LIBRARY_LIST="
>  libsoxr
>  libspeex
>  libssh
> -libstagefright_h264
>  libtesseract
>  libtheora
>  libtwolame
> @@ -2639,7 +2637,6 @@ libshine_encoder_select="audio_frame_queue"
>  libspeex_decoder_deps="libspeex"
>  libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
> -libstagefright_h264_decoder_deps="libstagefright_h264"
>  libtheora_encoder_deps="libtheora"
>  libtwolame_encoder_deps="libtwolame"
>  libvo_aacenc_encoder_deps="libvo_aacenc"
> @@ -5476,9 +5473,6 @@ enabled libsnappy && require snappy
> snappy-c.h snappy_compress -lsnappy
>  enabled libsoxr   && require libsoxr soxr.h soxr_create -lsoxr &&
> LIBSOXR="-lsoxr"
>  enabled libssh&& require_pkg_config libssh libssh/sftp.h
> sftp_init
>  enabled libspeex  && require_pkg_config speex speex/speex.h
> speex_decoder_init -lspeex
> -enabled libstagefright_h264 && require_cpp libstagefright_h264
> "binder/ProcessState.h media/stagefright/MetaData.h
> -media/stagefright/MediaBufferGroup.h media/stagefright/MediaDebug.h
> media/stagefright/MediaDefs.h
> -media/stagefright/OMXClient.h media/stagefright/OMXCodec.h"
> android::OMXClient -lstagefright -lmedia -lutils -lbinder -lgnustl_static
>  enabled libtesseract  && require_pkg_config tesseract
> tesseract/capi.h TessBaseAPICreate
>  enabled libtheora && require libtheora theora/theoraenc.h
> th_info_init -ltheoraenc -ltheoradec -logg
>  enabled libtwolame&& require libtwolame twolame.h twolame_init
> -ltwolame &&
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index a18ca5b..b9ffdb9 100644
> --- a/libavcodec/Makefile
> +++ 

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Derek Buitenhuis]

On 1/3/2016 6:47 PM, Rostislav Pehlivanov wrote:
> I see no reason why this should not be dropped from Git master
> and the next stable release.

I was unsure if this should be dropped in a minor or major bump, actually.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Philip Langdale]

On Sun,  3 Jan 2016 13:37:18 -0500
Derek Buitenhuis  wrote:

> It serves absolutely no purpose other than to confuse potentional
> Android developers about how to use hardware acceleration properly
> on the the platform. Both stagefright itself, and MediaCodec, have
> avcodec backends already, and this is the correct way to use it.
> MediaCodec as a proper JNI API.
> 
> Furthermore, stagefright support in avcodec needs a series of
> magic incantations and version-specific stuff, such that
> using it actually provides downsides compared just using the actual
> Android frameworks properly, in that it is a lot more work and
> confusion to get it even running. It also leads to a lot of
> misinformation, like these sorts of comments (in [1]) that are
> absolutely incorrect.
> 
> [1] http://stackoverflow.com/a/29362353/3115956
> 
> Signed-off-by: Derek Buitenhuis 
> ---
> I am certain there are many more reasons to remvoe this as well. I
> know its own author despises it, and I know j-b will same things to
> say.
> 
> I have CC'd the person listed in MAINTAINERS for this set of code as
> well.
> 
> Please discuss, and keep discourse civil and avoid ad hominems, etc.
> ---
>  MAINTAINERS   |   1 -
>  configure |   6 -
>  libavcodec/Makefile   |   1 -
>  libavcodec/allcodecs.c|   1 -
>  libavcodec/libstagefright.cpp | 591
> --
> libavcodec/version.h  |   2 +- tools/build_libstagefright
> |  58 - 7 files changed, 1 insertion(+), 659 deletions(-)
>  delete mode 100644 libavcodec/libstagefright.cpp
>  delete mode 100644 tools/build_libstagefright
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9add13d..b62a4f8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -304,7 +304,6 @@ Codecs:
>  Hardware acceleration:
>crystalhd.c   Philip Langdale
>dxva2*Hendrik Leppkes, Laurent
> Aimar
> -  libstagefright.cppMohamed Naufal
>vaapi*Gwenole Beauchesne
>vda*  Sebastien Zwickert
>vdpau*Philip Langdale, Carl Eugen
> Hoyos diff --git a/configure b/configure
> index 6710f85..4d6d4fc 100755
> --- a/configure
> +++ b/configure
> @@ -250,7 +250,6 @@ External library support:
>--enable-libsoxr enable Include libsoxr resampling [no]
>--enable-libspeexenable Speex de/encoding via libspeex [no]
>--enable-libssh  enable SFTP protocol via libssh [no]
> -  --enable-libstagefright-h264  enable H.264 decoding via
> libstagefright [no] --enable-libtesseractenable Tesseract, needed
> for ocr filter [no] --enable-libtheora   enable Theora encoding
> via libtheora [no] --enable-libtwolame  enable MP2 encoding via
> libtwolame [no] @@ -1478,7 +1477,6 @@ EXTERNAL_LIBRARY_LIST="
>  libsoxr
>  libspeex
>  libssh
> -libstagefright_h264
>  libtesseract
>  libtheora
>  libtwolame
> @@ -2639,7 +2637,6 @@ libshine_encoder_select="audio_frame_queue"
>  libspeex_decoder_deps="libspeex"
>  libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
> -libstagefright_h264_decoder_deps="libstagefright_h264"
>  libtheora_encoder_deps="libtheora"
>  libtwolame_encoder_deps="libtwolame"
>  libvo_aacenc_encoder_deps="libvo_aacenc"
> @@ -5476,9 +5473,6 @@ enabled libsnappy && require snappy
> snappy-c.h snappy_compress -lsnappy enabled libsoxr   &&
> require libsoxr soxr.h soxr_create -lsoxr && LIBSOXR="-lsoxr" enabled
> libssh&& require_pkg_config libssh libssh/sftp.h
> sftp_init enabled libspeex  && require_pkg_config speex
> speex/speex.h speex_decoder_init -lspeex -enabled libstagefright_h264
> && require_cpp libstagefright_h264 "binder/ProcessState.h
> media/stagefright/MetaData.h
> -media/stagefright/MediaBufferGroup.h
> media/stagefright/MediaDebug.h media/stagefright/MediaDefs.h
> -media/stagefright/OMXClient.h media/stagefright/OMXCodec.h"
> android::OMXClient -lstagefright -lmedia -lutils -lbinder
> -lgnustl_static enabled libtesseract  && require_pkg_config
> tesseract tesseract/capi.h TessBaseAPICreate enabled
> libtheora && require libtheora theora/theoraenc.h
> th_info_init -ltheoraenc -ltheoradec -logg enabled libtwolame
> && require libtwolame twolame.h twolame_init -ltwolame && diff --git
> a/libavcodec/Makefile b/libavcodec/Makefile index a18ca5b..b9ffdb9
> 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -829,7
> +829,6 @@ OBJS-$(CONFIG_LIBSCHROEDINGER_ENCODER)+=
> libschroedingerenc.o \ OBJS-$(CONFIG_LIBSHINE_ENCODER)   +=
> libshine.o OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
> OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
> -OBJS-$(CONFIG_LIBSTAGEFRIGHT_H264_DECODER)+= libstagefright.o
> 

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[James Almer]

On 1/3/2016 3:44 PM, wm4 wrote:
> On Sun, 3 Jan 2016 20:49:10 +0300
> foo86  wrote:
> 
>> This is initial version of libdcadec DCA decoder port I hacked together over
>> the last week. This patch is of RFC/inquiry type and not meant for immediate
>> inclusion.
>>
>> Any comments about the code are appreciated, as well as suggestions 
>> concerning
>> how should I proceed with this patch. Should I aim for including it as a
>> separate decoder or a replacement for existing DCA decoder? Or it might be 
>> that
>> you prefer to continue improving existing decoder instead and not merge this 
>> at
>> all.
> 
> Maybe we could have a vote whether or not the existing builtin decoder
> should be replaced with this?

I think calling for a vote would make sense if people start commenting against 
it.
So far nobody did, but in any case there's time to discuss.

Keep in mind there are not many things, if any, in favor of the current decoder,
especially now that it stopped being faster. There's no maintainer for it 
working
on ffmpeg side of things, has less features, and the current developer on libav
is essentially taking bits from this one to catch up on features.

But by all means lets not have another prores or asf/wmv demuxer situation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Derek Buitenhuis]

On 1/3/2016 6:37 PM, Derek Buitenhuis wrote:
> Both stagefright itself, and MediaCodec, have
> avcodec backends already, and this is the correct way to use it.

This bit is wrong. The correct way is to use MediaCodecs API,
since stagefright is not a public API, I have been informed.

I think Martin will respond with a much more informed reply.

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

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[Rostislav Pehlivanov]

>IMO this should replace the current dca decoder. Based on what i saw from
libdcadec
>yours is cleaner, more feature complete, you're a knowledgeable
maintainer, and
>since the current developer for ffdca over at libav is porting code from
yours to
>get bitexact xll working the code duplication would be considerable if we
keep both.

I agree.

On 3 January 2016 at 18:24, James Almer  wrote:

> On 1/3/2016 2:49 PM, foo86 wrote:
> > This is initial version of libdcadec DCA decoder port I hacked together
> over
> > the last week. This patch is of RFC/inquiry type and not meant for
> immediate
> > inclusion.
> >
> > Any comments about the code are appreciated, as well as suggestions
> concerning
> > how should I proceed with this patch. Should I aim for including it as a
> > separate decoder or a replacement for existing DCA decoder? Or it might
> be that
> > you prefer to continue improving existing decoder instead and not merge
> this at
> > all.
>
> IMO this should replace the current dca decoder. Based on what i saw from
> libdcadec
> yours is cleaner, more feature complete, you're a knowledgeable
> maintainer, and
> since the current developer for ffdca over at libav is porting code from
> yours to
> get bitexact xll working the code duplication would be considerable if we
> keep both.
>
> >
> > Attached decoder is feature complete enough to fully decode any
> practically
> > available DTS stream configuration. It supports any possible
> combinations of
> > XCH, XXCH, XBR and X96 core extensions to deliver up to 7.1 ch, 96 kHz
> floating
> > point output. It also implements lossless decoding of XLL extension to
> deliver
> > up to 7.1 ch, 192 kHz fixed point output. Bit rate managed XLL streams
> are
> > supported. Downmixing to 5.1 and stereo using embedded coefficients is
> > supported.
> >
> > Performance wise, this decoder used to be around 10% slower than pure
> floating
> > point version of existing native DCA decoder. However, after native DCA
> decoder
> > has been partially converted to fixed point, this decoder became 5%
> faster than
> > native one. Measurements were done looping over 5.1 core only stream in
>
> Another reason to have this replace the current one, then.
>
> Thanks.
> ___
> 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]lavf/decimate: Fix total difference for the first frame

[Carl Eugen Hoyos]

Derek Buitenhuis  gmail.com> writes:

> 
> On 1/3/2016 3:11 PM, Carl Eugen Hoyos wrote:
> > With the patch, the frame with the lowest diff is actually dropped 
> > instead of the first frame that indicates a scene change without 
> > the patch (iiuc).
> 
> Is this for all scene changes or just frame 0? If for all 
> scene changes, ignore the lower comment.

Afaict, prv==NULL only for the the first frame.

> > -dm->queue[dm->fid].totdiff  = INT64_MAX;
> > +dm->queue[dm->fid].totdiff  = dm->scthresh;
> 
> Upstream uses +1 here, but I'm not sure why:

"dm->scthresh+1" is equivalent to INT_MAX afaict and 
makes the given sample fail with our decimate filter.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Derek Buitenhuis]

On 1/3/2016 7:04 PM, Carl Eugen Hoyos wrote:
> "dm->scthresh+1" is equivalent to INT_MAX afaict and 
> makes the given sample fail with our decimate filter.

I think it should be OK, then.

Perhaps Clement can comment if not.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Kieran Kunhya]

> It is still "speed critical" enough for people to retain
> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
> count down enough so that hardcoded tables can be removed here.

How are you going to guarantee this across all arches?
Whilst by all means feel free to work on what you want, there are way
more interesting things out there.

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

Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: simplify parity check

[Derek Buitenhuis]

On 1/3/2016 5:33 PM, Clément Bœsch wrote:
> +return (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1;

I mean, I see how it works, but it's incredibly non-obvious without the
patch context (table removal).

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ronald S. Bultje]

Hi,

On Sun, Jan 3, 2016 at 11:21 AM, Ganesh Ajjanagadde 
wrote:

> It is still "speed critical" enough for people to retain
> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
> count down enough so that hardcoded tables can be removed here.


Can you explain why? Does CONFIG_HARDCODED_TABLES hurt your eyes? Or is it
morally corrupt? Or something else?

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

Re: [FFmpeg-devel] [PATCH]lavfi/drawtext: Fix microsecond display

[Derek Buitenhuis]

On 1/3/2016 1:00 PM, Carl Eugen Hoyos wrote:
> Attached patch fixes ticket #4792 for me, please comment.

Looks OK.

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

Re: [FFmpeg-devel] [PATCH]libavcodec/dca: Make decoding xll the default

[Paul B Mahol]

On 1/3/16, Carl Eugen Hoyos  wrote:
> Hendrik Leppkes  gmail.com> writes:
>
>> > Is there still something important missing?
>>
>> Its still equally broken as it was when it was
>> once commited - bugs have not been fixed since
>> then.
>
> Could you elaborate on (some of) the bugs, I
> was unable to find a report?
>

Try foo decoder and this one and compare hash of decoded output.

> Thank you, Carl Eugen
>
> ___
> 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] lavc/ccaption_dec: simplify parity check

[Clément Bœsch]

On Sun, Jan 03, 2016 at 05:43:26PM +, Derek Buitenhuis wrote:
> On 1/3/2016 5:33 PM, Clément Bœsch wrote:
> > +return (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1;
> 
> I mean, I see how it works, but it's incredibly non-obvious without the
> patch context (table removal).
> 

Any suggestion? Maybe a comment? Or you prefer the 32 lines table of 256
bytes to store 256 redundant bits of information?

The name of the function gives the context here, if you look up the web
for "bit parity" you'll get what you are looking for. I'm not sure the
table is much more obvious about what's this parity is all about.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 9:35 AM, Kieran Kunhya  wrote:
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcoded tables can be removed here.
>
> How are you going to guarantee this across all arches?

I don't. But what really matters is the static vs runtime cost, see
e.g the thread I created. The ratio will be far more similar across
arches.

> Whilst by all means feel free to work on what you want, there are way
> more interesting things out there.

No one has told me what is interesting, and in the last 6 months, I
have not seen a commit that I find interesting either to get an idea
of what can be done for the project. This is nothing against the
authors, who are all fantastic people, just my opinion. I am here to
serve the project, not because I find it "interesting", but because it
lacks manpower, and I find its goals worthy.
This philosophy has already been mentioned:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182508.html.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 9:43 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, Jan 3, 2016 at 11:21 AM, Ganesh Ajjanagadde 
> wrote:
>
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcoded tables can be removed here.
>
>
> Can you explain why? Does CONFIG_HARDCODED_TABLES hurt your eyes? Or is it
> morally corrupt? Or something else?

Please refrain from hyperbole, it has nothing to do with my eyes or
"moral corruption". More seriously, I have mentioned this already: wm4
said it is a worthy goal.

wm4, being a lead of mpv (a main client of FFmpeg), is someone whose
opinion I take seriously and think hard about, even if I don't agree
with it personally in some cases. Many things I did in the past were
not liked by many here, and are still not liked by many going by
recent IRC logs. I wanted to find a common ground, and here was
something where I actually agreed with wm4 even from my own
convictions.
Again, this goes back to what I said: I do things not because I find
it interesting, but because someone whose needs are more than mine
benefits from it.

More generally, I find something very inconsistent here: table
generation is claimed to not be "speed-critical", yet there are a few
people here who still think it is "critical enough" to justify
retaining hardcoded tables, and the associated complexity of the
configure/build system.

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

[FFmpeg-devel] [PATCH] lavc/ccaption_dec: simplify parity check

[Clément Bœsch]

---
 libavcodec/ccaption_dec.c | 43 +++
 1 file changed, 7 insertions(+), 36 deletions(-)

diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 9f67caa..1fdf7ed 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -101,40 +101,6 @@ static const unsigned char pac2_attribs[32][3] = // Color, 
font, ident
 /* total 32 entries */
 };
 
-/* 0-255 needs 256 spaces */
-static const uint8_t parity_table[256] = { 0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   0, 1, 1, 0, 1, 0, 0, 1,
-   1, 0, 0, 1, 0, 1, 1, 0 };
-
 struct Screen {
 /* +1 is used to compensate null character of string */
 uint8_t characters[SCREEN_ROWS][SCREEN_COLUMNS+1];
@@ -221,6 +187,11 @@ static int write_char (CCaptionSubContext *ctx, char 
*row,uint8_t col, char ch)
 }
 }
 
+static inline int get_parity(uint8_t x)
+{
+return (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1;
+}
+
 /**
  * This function after validating parity bit, also remove it from data pair.
  * The first byte doesn't pass parity, we replace it with a solid blank
@@ -238,10 +209,10 @@ static int validate_cc_data_pair (uint8_t *cc_data_pair)
 
 // if EIA-608 data then verify parity.
 if (cc_type==0 || cc_type==1) {
-if (!parity_table[cc_data_pair[2]]) {
+if (!get_parity(cc_data_pair[2])) {
 return AVERROR_INVALIDDATA;
 }
-if (!parity_table[cc_data_pair[1]]) {
+if (!get_parity(cc_data_pair[1])) {
 cc_data_pair[1]=0x7F;
 }
 }
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 3/3] lavc/g729dec: use ff_parity()

[Clément Bœsch]

---
 libavcodec/g729dec.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/libavcodec/g729dec.c b/libavcodec/g729dec.c
index 99053ad..7265883 100644
--- a/libavcodec/g729dec.c
+++ b/libavcodec/g729dec.c
@@ -181,14 +181,6 @@ static inline uint16_t g729_prng(uint16_t value)
 }
 
 /**
- * Get parity bit of bit 2..7
- */
-static inline int get_parity(uint8_t value)
-{
-   return (0x6996966996696996ULL >> (value >> 2)) & 1;
-}
-
-/**
  * Decodes LSF (Line Spectral Frequencies) from L0-L3 (3.2.4).
  * @param[out] lsfq (2.13) quantized LSF coefficients
  * @param[in,out] past_quantizer_outputs (2.13) quantizer outputs from 
previous frames
@@ -480,7 +472,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame_ptr,
 
 ac_index  = get_bits(, format->ac_index_bits[i]);
 if(!i && format->parity_bit)
-bad_pitch = get_parity(ac_index) == get_bits1();
+bad_pitch = ff_parity(ac_index >> 2) == get_bits1();
 fc_indexes= get_bits(, format->fc_indexes_bits);
 pulses_signs  = get_bits(, format->fc_signs_bits);
 gc_1st_index  = get_bits(, format->gc_1st_index_bits);
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 1/3] common: add ff_parity()

[Clément Bœsch]

---
 configure   | 2 ++
 libavutil/x86/intmath.h | 9 +
 2 files changed, 11 insertions(+)

diff --git a/configure b/configure
index 6710f85..610be92 100755
--- a/configure
+++ b/configure
@@ -1738,6 +1738,7 @@ BUILTIN_LIST="
 machine_rw_barrier
 MemoryBarrier
 mm_empty
+parity
 rdtsc
 sarestart
 sync_val_compare_and_swap
@@ -5242,6 +5243,7 @@ check_builtin sarestart signal.h "SA_RESTART"
 check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; 
__sync_val_compare_and_swap(ptr, oldval, newval)"
 check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, tm)"
 check_builtin localtime_r time.h "time_t *time; struct tm *tm; 
localtime_r(time, tm)"
+check_builtin parity "" "__builtin_parity(123)"
 
 case "$custom_allocator" in
 jemalloc)
diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
index 611ef88..9c36bf2 100644
--- a/libavutil/x86/intmath.h
+++ b/libavutil/x86/intmath.h
@@ -75,6 +75,15 @@ static av_always_inline av_const int ff_ctzll_x86(long long 
v)
 
 #endif /* __POPCNT__ */
 
+static av_always_inline av_const int ff_parity(uint32_t v)
+{
+#if HAVE_PARITY
+return __builtin_parity(v);
+#else
+return av_popcount(v) & 1;
+#endif
+}
+
 #if defined(__BMI2__)
 
 #if AV_GCC_VERSION_AT_LEAST(5,1)
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH]libavcodec/dca: Make decoding xll the default

[Michael Niedermayer]

On Sun, Jan 03, 2016 at 03:58:04PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Is there still something important missing?

the code below or a change to bits_long
also there are segfaults
try with a fuzzer

diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
index 98fd4c8..60efa16 100644
--- a/libavcodec/dca_xll.c
+++ b/libavcodec/dca_xll.c
@@ -487,6 +487,11 @@ int ff_dca_xll_decode_audio(DCAContext *s, AVFrame *frame)
 params->pancAuxABIT[i] = get_bits(gb, bits4ABIT) + 1;
 else
 params->pancAuxABIT[i] = 0;
+
+if (params->pancAuxABIT[i] > 25) {
+av_log(s->avctx, AV_LOG_WARNING, "XLL: pancAuxABIT too 
large\n");
+params->pancAuxABIT[i] = 0;
+}
 }

 for (i = 0; i < num_param_sets; i++) {
@@ -510,6 +515,10 @@ int ff_dca_xll_decode_audio(DCAContext *s, AVFrame *frame)
 if (params->rice_code_flag[i] == 0 && params->pancABIT[i] 
> 0)
 /* For linear code */
 params->pancABIT[i]++;
+if (params->pancABIT[i] > 25 || params->pancABIT0[i] > 25) 
{
+av_log(AV_LOG_WARNING, "XLL: pancABIT too large\n");
+goto next_chset;
+}
 }
 }
 for (i = 0; i < chset->channels; i++) {

[...]

-- 
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] [PATCH 1/3] common: add ff_parity()

[Clément Bœsch]

On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
> ---
>  configure   | 2 ++
>  libavutil/x86/intmath.h | 9 +
>  2 files changed, 11 insertions(+)
> 
> diff --git a/configure b/configure
> index 6710f85..610be92 100755
> --- a/configure
> +++ b/configure
> @@ -1738,6 +1738,7 @@ BUILTIN_LIST="
>  machine_rw_barrier
>  MemoryBarrier
>  mm_empty
> +parity
>  rdtsc
>  sarestart
>  sync_val_compare_and_swap
> @@ -5242,6 +5243,7 @@ check_builtin sarestart signal.h "SA_RESTART"
>  check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; 
> __sync_val_compare_and_swap(ptr, oldval, newval)"
>  check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, 
> tm)"
>  check_builtin localtime_r time.h "time_t *time; struct tm *tm; 
> localtime_r(time, tm)"
> +check_builtin parity "" "__builtin_parity(123)"
>  
>  case "$custom_allocator" in
>  jemalloc)
> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
> index 611ef88..9c36bf2 100644
> --- a/libavutil/x86/intmath.h
> +++ b/libavutil/x86/intmath.h

... moved locally to libavutil/intmath.h under proper ff_parity_c
ifdefery, sorry for the noise.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [RFC v5] libavcodec: add a native Daala decoder

[Andreas Cadhalpun]

On 02.01.2016 18:56, Rostislav Pehlivanov wrote:
> --- /dev/null
> +++ b/libavcodec/daala_entropy.h
> @@ -0,0 +1,464 @@
[...]
> +/* Expectation value is in Q16 */
> +static inline int daalaent_decode_generic(DaalaEntropy *e, DaalaCDF *c, int 
> *ex,
> +  int max, int integrate)
> +{
> +int rval, lsb = 0, log_ex = daalaent_log_ex(*ex);
> +const int shift = FFMAX(0, (log_ex - 5) >> 1);
> +const int id = FFMIN(DAALAENT_MODEL_TAB - 1, log_ex);
> +const int ms = (max + (1 << shift >> 1)) >> shift;
> +int xs = (max == -1) ? 16 : FFMIN(ms + 1, 16);
> +ent_rng *cdf = >cdf[id*c->y];
> +if (!max)
> +return 0;
> +if ((xs = daalaent_decode_cdf(e, cdf, xs, 0, CDF_UNSCALED)) == 15) {
> +int g = ((2*(*ex) >> 8) + (1 << shift >> 1)) >> shift;

This can still overflow to -256 causing the following line to crash.
A first step towards fixing this would be to replace '2*(*ex) >> 8'
with '*ex >> 7'. That has the same result whenever the first expression
is not undefined and should be faster, as well. ;)

This prevents most of these crashes, but a few remain, because *ex
can already be negative here due to a previous overflow.

> +ent_win decay = FFMAX(2, FFMIN(254, 256*g/(g + 256)));
> +xs += daalaent_decode_laplace(e, decay, (max == -1) ? -1 : ms - 15);
> +}
> +if (shift) {
> +if (shift > !xs)
> +lsb = daalaent_decode_bits(e, shift - !xs);
> +lsb -= !!xs << (shift - 1);
> +}
> +rval = (xs << shift) + lsb;
> +daalaent_exp_model_update(c, ex, rval, xs, id, integrate);
> +return rval;
> +}

> --- /dev/null
> +++ b/libavcodec/daala_pvq.h
> @@ -0,0 +1,491 @@
[...]
> +static void daalapvq_decode_vector(DaalaEntropy *e, DaalaPVQ *pvq,
> +   dctcoef *out, dctcoef *ref, const double 
> beta,
> +   uint8_t key_frame, int p, uint8_t 
> *skip_rest,
> +   uint8_t has_err, int band_idx,
> +   int qm_off, enum DaalaBsize bsize)
> +{
> +int i, k;
> +int qg = 0, skip = 0, itheta = (!!key_frame), has_ref = !key_frame;
> +double qcg, gain, theta = 0.0f, gr = 0.0f, gain_off = 0.0f;
> +dctcoef tmp[DAALAPVQ_MAX_PART_SIZE] = {0};
> +
> +const int robust = has_err || key_frame;
> +const int band_len = pvq->size[band_idx];
> +const int16_t *qmatrix = >qmatrix[qm_off];
> +const int16_t *qmatrix_inv = >qmatrix_inv[qm_off];
> +
> +if (!skip_rest[(band_idx + 2) % 3]) {
> +int iloc = (!!p)*DAALA_NBSIZES*DAALAPVQ_PARTITIONS_MAX + 
> bsize*DAALAPVQ_PARTITIONS_MAX + band_idx;
> +i = daalaent_decode_cdf_adapt(e, >pvqtheta_gain_cdf, iloc, 8 + 
> 7*pvq->skip[band_idx]);
> +if (!key_frame && i >= 10)
> +i++;
> +if (key_frame && i >= 8)
> +i++;
> +if (i >= 8) {
> +i -= 8;
> +skip_rest[0] = skip_rest[1] = skip_rest[2] = 1;
> +}
> +qg = i & 1;
> +itheta = (i >> 1) - 1;
> +has_ref = !(itheta == -1);
> +}
> +if (qg) {
> +int *ex = pvq->pvqgain_ex[p][bsize] + band_idx, ex_tmp = *ex;
> +DaalaCDF *mcdf = has_ref ? >pvqgain_ref_mcdf : 
> >pvqgain_noref_mcdf;
> +qg = 1 + daalaent_decode_generic(e, mcdf, _tmp, -1, 2);
> +*ex += ((qg << 16) - *ex) >> 2;

Here is the other overflow that can cause above crash.
To avoid this problem, this line could be replaced with:
*ex += (qg << 14) - (*ex >> 2);

This illustrates quite well why I think that overflows should be fixed
if reasonably possible, as they can cause weird problems in different
parts of the code.

> --- /dev/null
> +++ b/libavcodec/daaladec.c
> @@ -0,0 +1,824 @@
[...]
> +static int daala_decode_frame(AVCodecContext *avctx, void *data,
> +  int *got_frame, AVPacket *avpkt)
> +{
> +int i, j, p, ret;
> +AVFrame *frame  = data;
> +DaalaContext *s = avctx->priv_data;

The width, height and pixel format can change in the middle of a stream,
which currently causes segmentation faults due to out of bounds
reads/writes.

It's probably possible to re-initialize the decoder for the new values,
but until that is implemented there should be a check here preventing
the crashes, e.g.:
if (avctx->width > s->width || avctx->height > s->height || avctx->pix_fmt 
!= s->fmt->fmt) {
av_log(avctx, AV_LOG_ERROR, "reinit not yet implemented (s:%dx%d %s; 
c:%dx%d %s)\n",
   s->width, s->height, av_get_pix_fmt_name(s->fmt->fmt),
   avctx->width, avctx->height, 
av_get_pix_fmt_name(avctx->pix_fmt));
return AVERROR_PATCHWELCOME;
}

> --- /dev/null
> +++ b/libavcodec/daaladsp.c
> @@ -0,0 +1,1890 @@

The code in this file still overflows quite often, but fixing above overflows
also fixes a few of these. So maybe fixing all overflows outside this file
will magically fix the 

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[Carl Eugen Hoyos]

James Almer  gmail.com> writes:

> But by all means lets not have another prores 

> or asf/wmv demuxer situation.

The asf situation can be fixed anytime, nobody 
is working on the broken demuxer...

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/3] get_bits: add get_bitsz for reading 0-25 bits

[Michael Niedermayer]

On Sun, Jan 03, 2016 at 07:41:49PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 02:03, Michael Niedermayer wrote:
> > On Sun, Jan 03, 2016 at 01:35:39AM +0100, Andreas Cadhalpun wrote:
> >> --- a/libavcodec/get_bits.h
> >> +++ b/libavcodec/get_bits.h
> >> @@ -269,6 +269,14 @@ static inline unsigned int get_bits(GetBitContext *s, 
> >> int n)
> >>  return tmp;
> >>  }
> >>  
> >> +/**
> >> + * Read 0-25 bits.
> >> + */
> > 
> >> +static inline int get_bitsz(GetBitContext *s, int n)
> > 
> > just realized when looking at the code this replaces, this should be
> > always_inline possibly
> 
> OK, changed inline to av_always_inline.
> 
> On 03.01.2016 02:26, Luca Barbato wrote:
> > On 03/01/16 01:36, Andreas Cadhalpun wrote:
> >> -/* handle n = 0 too */
> >> -static inline int get_bitsz(GetBitContext *s, int n)
> >> -{
> >> -return n ? get_bits(s, n) : 0;
> >> -}
> >> -
> >> -
> > 
> > If you want to go the extra mile you might move this hunk in the first 
> > patch, beside that seems fine.
> 
> Done.
> 
> Updated patches attached.
> 
> Best regards,
> Andreas

>  get_bits.h  |8 
>  mpegaudiodec_template.c |7 ---
>  2 files changed, 8 insertions(+), 7 deletions(-)
> 0d68f088494147aaab5cdd3b3e42fed473b6bc4f  
> 0001-get_bits-add-get_bitsz-for-reading-0-25-bits.patch
> From 50cc356a559e55657e9d90ed4c7fc2ba3e50551a Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Sun, 3 Jan 2016 00:28:42 +0100
> Subject: [PATCH 1/2] get_bits: add get_bitsz for reading 0-25 bits

both patches LGTM

thx

[...]

-- 
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] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[foo86]

On Sun, Jan 03, 2016 at 07:14:28PM +0100, Hendrik Leppkes wrote:
> Having two dca decoders with varying degrees of features is no
> advantages, and considering the native decoder lacks a long list of
> features and fails decoding a bunch of XLL streams, the aim should be
> to replace.
> I'm not aware of a single advantage of the old decoder, so...

Having both decoders available during development makes things like
comparing their output and performance a bit simpler, but I agree that
keeping both decoders doesn't make much sense in the end. The final
version of the patch should probably replace the old decoder. This will
offer some opportunity to clean up dcadata.c, etc.

> I have been using libdcadec through the library wrapper in ffmpeg for
> a while now, and I am not aware of any file that doesn't decode
> properly today, so yes, I tend to agree.
> Other people will probably want to apply fuzz testing, I'm not sure
> how much you have done to this degree.

I did a few manual runs with valgrind/ubsan and zzuf to make sure the
decoder doesn't do anything particularly stupid, but no real stress
testing yet.

> Trying to get some extra functionality into SIMD-able functions would
> be a good goal for later, but even the previous decoder doesn't have
> that much.
> So something for later.

If someone hinted what parts of code are easily optimizable with SIMD I
could later provide DSP hooks for it.

> Out of curiousity, do you plan to continue developing the external
> library, or would you abandon it if its merged?
> And more directly, I would hope we can also count on basic maintenance
> of the new decoder in ffmpeg? :)

I've implemented basically everything I wanted in external library, so I
don't really expect any more substanial development, just the bug fixes.
Regaring the new decoder in FFmpeg, I'll try to be around, assuming
nothing bad happens to me :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/avf_showspectrum: add option to draw legend

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/avf_showspectrum.c | 357 -
 1 file changed, 285 insertions(+), 72 deletions(-)

diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index d9fae7f..a40d189 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -31,8 +31,10 @@
 #include "libavcodec/avfft.h"
 #include "libavutil/audio_fifo.h"
 #include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
 #include "libavutil/channel_layout.h"
 #include "libavutil/opt.h"
+#include "libavutil/xga_font_data.h"
 #include "audio.h"
 #include "video.h"
 #include "avfilter.h"
@@ -73,6 +75,8 @@ typedef struct {
 AVAudioFifo *fifo;
 int64_t pts;
 int single_pic;
+int legend;
+int start_x, start_y;
 } ShowSpectrumContext;
 
 #define OFFSET(x) offsetof(ShowSpectrumContext, x)
@@ -256,8 +260,15 @@ static int config_output(AVFilterLink *outlink)
 outlink->w = s->w;
 outlink->h = s->h;
 
-h = (s->mode == COMBINED || s->orientation == HORIZONTAL) ? outlink->h : 
outlink->h / inlink->channels;
-w = (s->mode == COMBINED || s->orientation == VERTICAL)   ? outlink->w : 
outlink->w / inlink->channels;
+if (s->legend) {
+s->start_x = log10(inlink->sample_rate) * 25;
+s->start_y = 64;
+outlink->w += s->start_x * 2;
+outlink->h += s->start_y * 2;
+}
+
+h = (s->mode == COMBINED || s->orientation == HORIZONTAL) ? s->h : s->h / 
inlink->channels;
+w = (s->mode == COMBINED || s->orientation == VERTICAL)   ? s->w : s->w / 
inlink->channels;
 s->channel_height = h;
 s->channel_width  = w;
 
@@ -343,23 +354,23 @@ static int config_output(AVFilterLink *outlink)
 }
 }
 
-if ((s->orientation == VERTICAL   && s->xpos >= outlink->w) ||
-(s->orientation == HORIZONTAL && s->xpos >= outlink->h))
+if ((s->orientation == VERTICAL   && s->xpos >= s->w) ||
+(s->orientation == HORIZONTAL && s->xpos >= s->h))
 s->xpos = 0;
 
 outlink->frame_rate = av_make_q(inlink->sample_rate, s->win_size * 
(1.-s->overlap));
 if (s->orientation == VERTICAL && s->sliding == FULLFRAME)
-outlink->frame_rate.den *= outlink->w;
+outlink->frame_rate.den *= s->w;
 if (s->orientation == HORIZONTAL && s->sliding == FULLFRAME)
-outlink->frame_rate.den *= outlink->h;
+outlink->frame_rate.den *= s->h;
 
 if (s->orientation == VERTICAL) {
 s->combine_buffer =
-av_realloc_f(s->combine_buffer, outlink->h * 3,
+av_realloc_f(s->combine_buffer, s->h * 3,
  sizeof(*s->combine_buffer));
 } else {
 s->combine_buffer =
-av_realloc_f(s->combine_buffer, outlink->w * 3,
+av_realloc_f(s->combine_buffer, s->w * 3,
  sizeof(*s->combine_buffer));
 }
 
@@ -430,6 +441,56 @@ static void scale_magnitudes(ShowSpectrumContext *s, float 
scale)
 }
 }
 
+static void color_range(ShowSpectrumContext *s, int ch,
+float *yf, float *uf, float *vf)
+{
+switch (s->mode) {
+case COMBINED:
+// reduce range by channel count
+*yf = 256.0f / s->nb_display_channels;
+switch (s->color_mode) {
+case RAINBOW:
+case MORELAND:
+case NEBULAE:
+case FIRE:
+case FIERY:
+case INTENSITY:
+*uf = *yf;
+*vf = *yf;
+break;
+case CHANNEL:
+/* adjust saturation for mixed UV coloring */
+/* this factor is correct for infinite channels, an approximation 
otherwise */
+*uf = *yf * M_PI;
+*vf = *yf * M_PI;
+break;
+default:
+av_assert0(0);
+}
+break;
+case SEPARATE:
+// full range
+*yf = 256.0f;
+*uf = 256.0f;
+*vf = 256.0f;
+break;
+default:
+av_assert0(0);
+}
+
+if (s->color_mode == CHANNEL) {
+if (s->nb_display_channels > 1) {
+*uf *= 0.5 * sin((2 * M_PI * ch) / s->nb_display_channels);
+*vf *= 0.5 * cos((2 * M_PI * ch) / s->nb_display_channels);
+} else {
+*uf = 0.0f;
+*vf = 0.0f;
+}
+}
+*uf *= s->saturation;
+*vf *= s->saturation;
+}
+
 static void pick_color(ShowSpectrumContext *s,
float yf, float uf, float vf,
float a, float *out)
@@ -499,58 +560,14 @@ static int plot_spectrum_column(AVFilterLink *inlink, 
AVFrame *insamples)
 
 /* fill a new spectrum column */
 /* initialize buffer for combining to black */
-clear_combine_buffer(s, s->orientation == VERTICAL ? outlink->h : 
outlink->w);
+clear_combine_buffer(s, s->orientation == VERTICAL ? s->h : s->w);
 
 for (ch = 0; ch < s->nb_display_channels; ch++) {
 float *magnitudes = s->magnitudes[ch];
 

Re: [FFmpeg-devel] [PATCH 1/3] get_bits: add get_bitsz for reading 0-25 bits

[Andreas Cadhalpun]

On 03.01.2016 20:39, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 07:41:49PM +0100, Andreas Cadhalpun wrote:
>>  get_bits.h  |8 
>>  mpegaudiodec_template.c |7 ---
>>  2 files changed, 8 insertions(+), 7 deletions(-)
>> 0d68f088494147aaab5cdd3b3e42fed473b6bc4f  
>> 0001-get_bits-add-get_bitsz-for-reading-0-25-bits.patch
>> From 50cc356a559e55657e9d90ed4c7fc2ba3e50551a Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Sun, 3 Jan 2016 00:28:42 +0100
>> Subject: [PATCH 1/2] get_bits: add get_bitsz for reading 0-25 bits
> 
> both patches LGTM

Pushed both.

Best regards,
Andreas


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

Re: [FFmpeg-devel] [PATCH 1/3] ffmdec: reset packet_end in case of failure

[Andreas Cadhalpun]

On 03.01.2016 15:52, Michael Niedermayer wrote:
> On Sat, Jan 02, 2016 at 07:43:03PM +0100, Andreas Cadhalpun wrote:
>>  ffmdec.c |9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>> 1600298d54df3b7c7c74d4437521405b38342c60  
>> 0001-ffmdec-reset-packet_end-in-case-of-failure.patch
>> From a0faebf31ab37083e140c6d276b16dd024f97ffb Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Sat, 2 Jan 2016 16:27:02 +0100
>> Subject: [PATCH 1/3] ffmdec: reset packet_end in case of failure
>>
>> This fixes segmentation faults caused by passing a packet_ptr of NULL to
>> memcpy.
>>
>> Signed-off-by: Andreas Cadhalpun 
> 
> should be ok

Pushed.

Best regards,
Andreas

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