[FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

wm4 nfxjfg at googlemail.com
Fri Mar 2 20:19:29 EET 2018

On Fri, 2 Mar 2018 14:30:28 -0300
James Almer <jamrial at gmail.com> wrote:

> On 3/2/2018 1:47 PM, wm4 wrote:
> > On Fri, 2 Mar 2018 13:11:35 -0300
> > James Almer <jamrial at 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.
> I mean keep the buffer and the int fields all in a single opaque (for
> the user) struct handled by a single side data type. The user still only
> needs to worry about using the get/set functions and nothing else.
> See the attached, untested PoC to get an idea of what i mean.
> If I'm really missing the entire point of this patch (Which i don't
> discard may be the case), then ignore this.

That would be nice, but unfortunately it's not allowed. An API user can
treat side data as byte arrays, and e.g. copy & restore it somewhere
(presumably even if the data is opaque and implementation defined).

So the side data can't contain any pointers. The user could copy
the byte data, unref the AVBufferRef, and later add it back as side
data using the copied bytes. Then it'd contain a dangling pointer.

The side data merging (which we even still provide as API) would be an
application for that - it's for AVPacket, but there's nothing that
prevents the same assumptions with AVFrames.

Unless we decide that at least AVFrame side data can contain pointers,
and the user must strictly use the AVBufferRef to manage the life time
of the data. Maybe I'm just overthinking this.

More information about the ffmpeg-devel mailing list