[FFmpeg-devel] [PATCH v5 1/5] libavcodec: VAAPI support infrastructure

wm4 nfxjfg at googlemail.com
Sun Jan 31 17:58:11 CET 2016


On Sun, 31 Jan 2016 16:32:24 +0000
Mark Thompson <sw at jkqxz.net> wrote:

> On 31/01/16 16:24, Mark Thompson wrote:
> > On 31/01/16 16:13, wm4 wrote:  
> >> On Sat, 30 Jan 2016 22:11:52 +0000
> >> Mark Thompson <sw at jkqxz.net> wrote:  
> >>> +
> >>> +static AVClass vaapi_class = {
> >>> +    .class_name = "vaapi",
> >>> +    .item_name  = av_default_item_name,
> >>> +    .version    = LIBAVUTIL_VERSION_INT,
> >>> +};
> >>> +static AVClass *vaapi_log = &vaapi_class;
> >>> +  
> >>
> >> I'll give a more thorough review tomorrow, but let me just point out
> >> that this is not really the point of the log mechanism. It should be
> >> bound to an actual instance, like the vaapi hw context or whatever. We
> >> hope to get rid of the global log callback one day, and then all av_log
> >> calls have to go to an instance of some sort (so that it can find the
> >> log callback), even if this doesn't matter today yet.
> >>  
> > 
> > I wanted to put an AVClass into the hardware context structure, but it doesn't work without breaking the compatibility with struct vaapi_context (because it has to be the first thing in the structure).
> > 
> > Without that, there is just nothing to bind it to in many of those functions.
> > 
> > - Mark
> >   
> 
> And then I see the hackaround just after sending...
> 
> struct {
>     foo;
>     const AVClass *class;
> } bar;
> 
> av_log(&bar->class, ...);
> 
> Nasty, but I can use that.  (And not really worse than the existing "log" static variable.)
> 

Why does AVClass have to be the first field in vaapi_context? Unless
you pass a vaapi_context pointer as argument to av_log, I don't see why
it would be needed.


More information about the ffmpeg-devel mailing list