[FFmpeg-devel] [PATCH] Added support for MB_INFO

Carotti, Elias eliascrt at amazon.it
Fri Jun 17 13:59:15 EEST 2022


> 
> 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 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".



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




More information about the ffmpeg-devel mailing list