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@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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
