On Wed, 4 Oct 2017 11:47:39 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Wed, Oct 04, 2017 at 11:34:18AM +0200, wm4 wrote: > > On Wed, 4 Oct 2017 11:22:37 +0200 > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > 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 > > > > Well, you're wrong anyway. > > > > > such hacks should not be added, we do have enough hacks already > > > > It's not a hack. > > please accept my veto to this patch. That's completely unreasonable. You didn't even respond to my arguments. I can't accept your veto. > also, please stop sending me insults. > > * Loaded log from Sun Feb 26 13:41:05 2017 > 11:34 <wm4> I don't want to hear this from the king of ugly hacks I have the feeling your objections to this patch were bullshit in the first place, so I overreacted a little. But this "insult" wasn't meant to be public, so this is up to you. Anyway, you certainly never had problems with adding ugly hacks. It's possibly that you don't even deny this in most cases, but that you felt they were absolute "necessary" still. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
