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 <rsbul...@gmail.com> wrote: > > Hi Arnaud, > > On Fri, Nov 22, 2024 at 1:08 PM Arnaud Masserann <arnaud1...@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@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".
