On Sun, 31 Jan 2016 16:32:24 +0000
Mark Thompson <s...@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 <s...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
