[FFmpeg-devel] [FFmpeg-cvslog] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.
Derek Buitenhuis
derek.buitenhuis at gmail.com
Tue Jul 10 18:31:39 EEST 2018
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
More information about the ffmpeg-devel
mailing list