Good question. I just benchmarked all the .mov files in the samples repo. On average, there is a 1.3x speedup. A few files are slower, but 75% of the files have at least a 1.11x speedup, and 25% of the files have at least 1.49x.
Outliers include openquicktime/aletrek-tga-8bit.mov (0.8x, so slower), and wmv3/Bluem.mov (10.4x). Full data: https://etconlyview-my.sharepoint.com/:x:/g/personal/a_masserann_etc-onlyview_com/EXomK72G3LdJgoBHCgnYcBUBnxd0FAe90nrIkL4EFZKEuw?e=vj3TRl And FATE passes with valgrind, btw. On Fri, Nov 22, 2024 at 8:56 PM compn <f...@hawaiiantel.net> wrote: > > On Fri, 22 Nov 2024 18:46:19 +0100 > Arnaud Masserann <arnaud1...@gmail.com> wrote: > > > Most demuxers allocate a new buffer for each packet. > > For MOV, this can be problematic, because of some high-bitrate > > codecs like ProRes/HAPQ/NotchLC. > > > > Use pools of buffer instead. > > > > For some test media, demuxing goes from 20ms/frame to 11ms/frame, > > close to the perf of ReadFile (10ms/frame), making it possible > > to read the media at 60Hz. > > was this tested with all mov samples or just those high bitrate ones ? > > i am wondering if it helps/hurts demuxing the ancient mov samples we > also support. see the nightmares here https://samples.ffmpeg.org/mov/ > > if hurts, i wonder if buffer pools could be used only for specific high > bitrate codecs in mov demuxer? > > not important just curious. nice job on the speedup! > > -compn > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
