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. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
