[FFmpeg-devel] [FFmpeg-cvslog] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Michael Niedermayer michael at niedermayer.cc
Wed Jul 11 03:05:49 EEST 2018


On Tue, Jul 10, 2018 at 11:31:39AM -0400, Derek Buitenhuis wrote:
> 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.

ill post a patchset that seems to make it much faster but i need to test it
first a bit


> * 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180711/71adb8fd/attachment.sig>


More information about the ffmpeg-devel mailing list