Hi, On Sat, Jan 2, 2016 at 4:08 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
> On Sat, Jan 2, 2016 at 1:02 PM, Ronald S. Bultje <rsbul...@gmail.com> > wrote: > > Hi, > > > > On Sat, Jan 2, 2016 at 3:23 PM, Ganesh Ajjanagadde <gajja...@mit.edu> > wrote: > >> > >> On Fri, Jan 1, 2016 at 8:07 AM, Ganesh Ajjanagadde <gajja...@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. ffmpeg has a lot of abilities. But most of our users are not harvard (or MIT :-) ) PhDs, so they're unlikely to do it in the most optimal way, and very likely to do it in the easiest way. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
