[FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

Michael Niedermayer michael at niedermayer.cc
Wed Oct 18 14:04:59 EEST 2017


On Tue, Oct 17, 2017 at 07:26:01AM +0200, wm4 wrote:
[...]

> 
> > it also violates the API IMO, but thats not so much the point
> 
> It does not. I created the fucking API.
> 
> > The data the user application wants to attach to a AVFrame for the
> > user applications extrenal purposes
> > and
> > The data libavcodec wants to attach for internal (hwaccel) use.
> > 
> > Are 2 distinct things. You can have none, either one or both theres
> > no relation between them.
> 
> AVFrame does not dictate a use for this field. The use of the field is
> determined by the owner of the AVFrame, which is libavcodec while the
> frame is in libavcodec.
> 
> How often did I repeat this and how often did you not understand this?

opaque_ref is defined to have the same semantics as opaque.
opaque definitly does NOT have the semantics you write about in this
thread.
opaque is a field that exists for a very long time

I think you and Libav misunderstood the opaque field semantics

Just think about it, the opaque field existed when the *frame structure
was defined in libavcodec. The user of libavcodec is NOT libavcodec
This field was never intended to be used by any of our libs to store
their private data.

It was the move of AVFrame to libavutil that made the documentation
of opaque ambigous and this likely lead to this misunderstanding


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171018/a4460ba6/attachment.sig>


More information about the ffmpeg-devel mailing list