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

Reply via email to