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?) - Andreas _______________________________________________ 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".
