Yes, exactly. It relies on x264 to free it.
Not really. It can rely on x264 if you explicitly want that behavior. If you do not set a deallocator, it remains the caller responsibility.
What happens if x264 is not involved, but some other encoder, which does not check for that kind of side data?
How does the caller know that the data was consumed, and the ownership passed on?
Again, you don't have to pass the ownership, and in fact in my use case I do not pass it since I actually recycle and update the same buffer for subsequent frames. If you do intentionally pass the ownership you need to be aware of what you are doing. As I said, I see a leak only in case of a programming error. Maybe we could explicitly state it in the comment section in mb_info.h: if you set the deallocator you're relinquishing ownership of the buffer. Plus, there's one more flag (b_mb_info_update) in libx264 which allows to pass back information to the caller about which macroblocks among the flagged ones were actually encoded as P_SKIP. I did not add support for that though but in the future somebody may want to. In principle I could've put the buffer into the side information and not just pass a pointer to it but I thought that it would require adding more semantics which would imply a stronger dependency on libx264. Right now, mb_info is a vector of uint8_t flags and the only possible value - to date - is X264_MBINFO_CONSTANT. What if, say, one day libx264 decides the buffer has to be a vector of uint16_t or still uint8_t but the flags are packed? On the other hand, this, AFAIK, is only supported by libx264. Other codecs may want to choose a different semantic for a similar field and the only possibility to make it generic is letting the caller handling the low level details.
The only sane way would be for the caller to hand over the ownership to ffmpeg, which then takes care of making sure it gets freed.
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
NICE SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese di Milano Monza Brianza Lodi REA n. 2096882, Capitale Sociale: 10.329,14 EUR i.v., Cod. Fisc. e P.IVA 01133050052, Societa con Socio Unico