Hi, Apologies for commenting on this so many months after it was pushed.
> ffmpeg | branch: master | Sasi Inguva <isasi-at-google.com at ffmpeg.org> | > Mon Dec 18 15:31:16 2017 -0800| [58a25aeb8e69532aae6ed1762fe7e0b260990010] | > committer: Michael Niedermayer > > lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header. > > Signed-off-by: Sasi Inguva <isasi at google.com> > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc> > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=58a25aeb8e69532aae6ed1762fe7e0b260990010 > --- This commit massively tanked perf of mov demuxer when opening files. On average it has doubled and/or tripled (!!!) the amount of cycles that opening an MP4 needs. Also, I'm not sure why generic PTS reordering/delay code is in mov.c, rather than utils.c or something. There's nothing inherently mov-specific about this, unless you count "has an index". On an example file (24h long, warm runs): Before Patch ------------ 4446217810 decicycles in mov_build_index, 1 runs, 0 skips 4603125860 decicycles in mov_build_index, 2 runs, 0 skips After Patch ----------- 14457275100 decicycles in mov_build_index, 1 runs, 0 skips 9608655040 decicycles in mov_build_index, 2 runs, 0 skips I happen to call the mov open API quite heavily (in my case, for on-the-fly remuxing), and this increase CPU load around 25%+ per core, overall, which is nontrivial. I appreciate the perf of opening a file may not be something we care about, so I see a few options: * I just patch it out at $dayjob; not ideal, since I prefer to upstream, but I can understand the usecase is too niche for upstreaming. * Add a yet another option to mov.c to bypass it entirely. * Add yet another option to mov.c to restrict the calculations to the first MAX_REORDER_FRAMES+1 frames of the file. This would make it unsuitable for seeking. * Move the code to a generic place like utils.c and add a generic option to bypass it. * Some algorithmic trickery to make it faster - I tried to think of a better way to do it, but all the things I could think of would only yeild minor gains, leaving the overal big-O complexity the same. * Some mix of the above, or something not listed here. Ideas and comments very welcome, even if they amount to "go pound sand". Cheers, - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel