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

[Michael Niedermayer]

On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote:
> On Tue, 3 Oct 2017 21:40:58 +0200
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote:
> > > From: Anton Khirnov <anton at khirnov.net>
> > >   
> > 
> > > Use the AVFrame.opaque_ref field. The original user's opaque_ref is
> > > wrapped in the lavc struct and then unwrapped before the frame is
> > > returned to the caller.  
> > 
> > this is a ugly hack
> > 
> > one and the same field should not be used to hold both the
> > users opaque_ref as well as a structure which is itself not a user
> > opaque_ref
> 
> While the AVFrame is within libavcodec, it's libavcodec's frame, not
> the user's. Thus your claim doesn't make too much sense. libavcodec
> fully controls the meaning for its own AVFrames' opaque_ref, but
> reconstruct the user's value when returning it.

i disagree
such hacks should not be added, we do have enough hacks already

AVFrames are not really seperated into isolated classes
There arent "the users AVFrames" vs. "the internal AVFrames"

its fragile to create and maintain such seperation with interfaces
that all wrap and unwrap the opaque_ref. Any mistake being a potential
security issue and or crash

Its MUCH more robust and also easier to understand to use a sperate
field
more so, opaque_ref is used in only 5 lines in the whole codebase,
so there is not much code to consider when using a different solution

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- 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/20171004/f641dfa8/attachment.sig>