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

[Anton Khirnov <anton@khirnov.net>]

Quoting Andreas Rheinhardt (2022-06-23 16:21:18)
> Anton Khirnov:
> > Quoting Carotti, Elias (2022-06-21 10:48:07)
> >> Hi,
> >>
> >> extending AVVideoEncParams was the first hypothesis I made but it
> >> didn't seem it was the proper place to add the mb_info flags.
> >>
> >> I may be wrong but my impression is that AVVideoEncParams is used to
> >> carry encoding parameters read from the bitstream at the decoder side
> >> while here were going the other direction, i.e., were passing
> >> information from the application to the encoder.
> >>
> >> Secondly, mb_info can't be strictly considered encoding parameters and
> >> it's not present in the bitstream at all. 
> >> It's just a way to give hints to the libx264 encoder on which
> >> macroblock we know have not changed since the previous frame and could
> >> be coded as P_SKIPs. Libx264 however, may or may not oblige according
> >> to its logic, and this specific information is not transmitted in the
> >> bitstream nor can be recovered at the decoder.
> > 
> > Right, seems I was too hasty in reading your patch.
> > 
> > But then I have to wonder whether this really needs a new installed
> > header, with a struct and a destructor, given that it's specific to a
> > single encoder for a single codec that is about 20 years old now.
> > 
> > Wouldn't AV_FRAME_DATA_X264_MBINFO that would be just a raw array of
> > uint8_t serve your needs just as fine? You could even get custom buffer
> > management by using AVFrameSideData.buf.
> > 
> 
> There is one problem though: libx264's free functions don't accept an
> opaque parameter, so one can't easily create a reference for libx264 to
> unref. I don't see a way around duplicating this buffer in the encoder.
> (Or is there a way to know when libx264 is done with using this buffer?)

An ugly, but workable hack could be
- user allocates the AVBuffer with extra space at the end
- lavc/libx264.c checks that there is extra space AND the buffer is
  writable (so the same side data wasn't passed to multiple encoders),
  then stores its AVBufferRef* in there

-- 
Anton Khirnov
_______________________________________________
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".