On Fri, 2 Mar 2018 13:11:35 -0300 James Almer <jamr...@gmail.com> wrote:
> On 3/2/2018 8:16 AM, wm4 wrote: > > This adds a way for an API user to transfer QP data and metadata without > > having to keep the reference to AVFrame, and without having to > > explicitly care about QP APIs. It might also provide a way to finally > > remove the deprecated QP related fields. In the end, the QP table should > > be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS. > > > > There are two side data types, because I didn't care about having to > > repack the QP data so the table and the metadata are in a single > > AVBufferRef. Otherwise it would have either required a copy on decoding > > (extra slowdown for something as obscure as the QP data), or would have > > required making intrusive changes to the codecs which support export of > > this data. > > Why not add an AVBufferRef pointer to the qp_properties struct instead? > You don't need to merge the properties fields into the buffer data. Not sure what you mean. The whole purpose of this is _not_ to add new pointers because it'd require an API user to deal with extra fields just for QP. I want to pretend that QP doesn't exist. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
