[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