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

[Ganesh Ajjanagadde]

On Sat, Jan 2, 2016 at 1:02 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
>
> On Sat, Jan 2, 2016 at 3:23 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>>
>> On Fri, Jan 1, 2016 at 8:07 AM, Ganesh Ajjanagadde <gajjanag at mit.edu>
>> 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 < 200000. Note that cbrt tables are only
>> > used in aacdec.
>>
>> To start some effort towards a more principled understanding of the
>> costs of runtime table initialization, I did some benchmarks.
>> Note: I am not familiar with avcodec, so I don't know if this reflects
>> correctly the static vs dynamic cost.
>> file: ~/samples/aac/al04_44.mp4
>> stream_loop: 100
>> number of calls of avcodec_decode_audio4: 35956
>> cost per call (avcodec_decode_audio4):
>>  834030 decicycles in decode_audio4,       1 runs,      0 skips
>>  556200 decicycles in decode_audio4,       2 runs,      0 skips
>> [...]
>>  177365 decicycles in decode_audio4,   16384 runs,      0 skips
>>  177059 decicycles in decode_audio4,   32768 runs,      0 skips
>> decoding cost: 17706*35956 = 636,636,936 cycles
>> duration: 832.55 seconds
>> cost per second of audio: 764,683 cycles
>> cost of table init: 200,000 cycles
>> fraction: 0.26
>>
>> So in a clip of n seconds duration, the relative overhead of dynamic
>> initialization of these cbrt tables is 0.26/n. For a more concrete
>> number, say a clip is of 180 seconds duration, then the overhead is
>> 0.26/180 = 0.15%.
>
>
> What if I only want to play the first 3 second of 1000 clips by calling
> ffmpeg.exe in a shell script? E.g. for fingerprinting. The number of use
> cases you cover needs to be more than just playback, ffmpeg can do much more
> than just that.

Two remarks:
1. As I said, this was only a start of the discussion; and the general
c/t decay holds; constant c should be close to what I obtained. So
yes, if you have such a thing, it will be slower.
2. I thought ffmpeg had the ability to handle multiple input files in
a single invocation? Thus, someone doing such a thing is IMHO doing it
incorrectly.

>
> Ronald