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

wm4 nfxjfg at googlemail.com
Wed Oct 4 13:04:23 EEST 2017


On Wed, 4 Oct 2017 11:47:39 +0200
Michael Niedermayer <michael at 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 <michael at 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 <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  
> > 
> > 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.


More information about the ffmpeg-devel mailing list