On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote: > On Tue, 3 Oct 2017 21:40:58 +0200 > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote: > > > From: Anton Khirnov <an...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
