[FFmpeg-devel] [PATCH] Use AVBufferPool in MOV

Arnaud Masserann arnaud1602 at gmail.com
Sun Nov 24 19:14:03 EET 2024


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 <ff at hawaiiantel.net> wrote:
>
> On Fri, 22 Nov 2024 18:46:19 +0100
> Arnaud Masserann <arnaud1602 at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list