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

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


There is no 32-stream limit.
Each AVBufferPool needs to be initialized with a fixed allocation
size. So, the 32 pools are for 1^1 bit allocations, 1^2 bit
allocations, ...2^32 bit allocations. See mov_pool_get in the patch.

This is why moving pools[32] to MOVContext could be ok: audio packets
would statistically use pools[4...10], and video packets pools[12..20]
or something like that. Personally I find it cleaner to separate the
buffers per-stream, but maybe there are reasons to do it the other
way.

As for the perf regarding small packet sizes: is my answer to compn
enough ? Would you like some more detailed analysis ?

Arnaud

On Sat, Nov 23, 2024 at 1:46 PM Ronald S. Bultje <rsbultje at gmail.com> wrote:
>
> Hi Arnaud,
>
> On Fri, Nov 22, 2024 at 1:08 PM Arnaud Masserann <arnaud1602 at gmail.com>
> wrote:
>
> > - Should the pools be per-stream (in MOVStreamContext) or per file (in
> > MOVContext) ?
> >
>
> I'm assuming the per-stream is because their bitrates (and packet sizes)
> will typically be substantially different. For example, video will have
> much higher packet sizes than audio, especially in situations where the
> video is only lightly compressed - like what we're talking about here. If
> we mix video and audio pools, the audio will take half the video size, and
> effective application size in a 1video+1audio stream will as much as double
> in the worst case. So I think what you're doing here is better - per-stream
> pools.
>
> I don't know if the 32-stream (*pool[32]) limit is because of practical
> limits or to prevent double allocations, but if latter, it seems iffy and
> should maybe be double-allocated so it works for any-streamcount media,
> even if > 32.
>
> Question: does the pooling help with small packet sizes? If not, does it
> make sense to only (by default) use pools for large-packet streams (if we
> know this in advance)? Or for codecs known to generate large packets?
>
> Ronald
> _______________________________________________
> 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