Hi, On Sun, Nov 24, 2024 at 12:25 PM Arnaud Masserann <arnaud1...@gmail.com> wrote:
> 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. > Ah, I see, clever. OK, so when you use something like /usr/bin/time to measure peak memory usage before/after, I assume it's roughly the same? Very cool. > As for the perf regarding small packet sizes: is my answer to compn > enough ? Would you like some more detailed analysis ? > I think it's fine. Some statistical variation is probably expected, and if the average gets better, that's probably good enough (at least from my perspective). 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".
