AVBufferPool is actually super lazy. It does not allocate N buffers at initialization. So for images, in all three cases (per-stream, per-media, and no pool), the behaviour is the same : 1 av_malloc per stream.
To be sure, I ran more tests: On image1.heic (48-streams), as reported by massif with `--peak-inaccuracy=0` : - master: 50.5 MiB - per-stream: 51.9MiB - per-media: 51.9MiB (the 1MiB increase is likely due to av_malloc being called with the next power-of-two) `ffmpeg -c:v copy -f framecrc` performance on the same image, as reported by hyperfine: - master: 40.4ms (+/-6.2ms) - per-stream: 40.5ms (+/-1.9ms) - per-media: 39.3ms (+/-1.7ms) Same but on a 1-stream, 8k .heic file: - master: 6.4ms (+/-1.1ms) - per-stream: 5.9ms (+/-1.2ms) - per-media: 6.6ms (+/-1.1ms) Variance is quite high (I can do actual benchmarks instead of just using hyperfine if needed, just ask), but it highlights that there is no big performance gap, since the behaviour is the same anyway. So, I still tend towards the per-stream approach, which I find cleaner, but I can definitely change. > > heif/heic/avif can (and most likely will) spawn several streams as a > that's how tiled images are handled. So a 4k photo taken from a phone > can have about 50 512x512 single frame hevc/av1 streams, which is > another argument in favor of having the pools be container level and not > stream. > > For single stream images, a pool will probably be slightly slower. > _______________________________________________ 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".
