Hello,
Le vendredi 5 septembre 2014, 18:13:49 wm4 a écrit :
> > +static VdpStatus vdp_enosys(/* Unspecified, not void - leave empty */)
> > +{
> > + return VDP_STATUS_NO_IMPLEMENTATION;
> > +}
> > +
> > +static void *ff_vdpau_get_proc_address(AVCodecContext *avctx, VdpFuncId
> > id) +{
> > + AVVDPAUContext *hwctx = avctx->hwaccel_context;
> > + void *ret;
> > +
> > + av_assert0(hwctx->device != VDP_INVALID_HANDLE);
> > +
> > + if (hwctx->get_proc_address(hwctx->device, id, &ret) !=
> > VDP_STATUS_OK)
> > + ret = vdp_enosys;
>
> Isn't this very questionable? IMO initialization should just fail if a
> required function is missing. But if a C language lawyer can confirm
> that this use of vdp_enosys is indeed legal, why not (although I
> have my doubt).
I think vdp_enosys is legal thanks to the C calling convention (i.e. the
called function does not need to know its parameters - this is necessary for
variadic functions). I can change it to NULL but it will mostly result in more
extra error handling boilerplate - only to handle completely broken VDPAU
drivers (of which I know none).
For such hypothetically broken driver, I think not failing safe is good
enough.
> The idea seems generally ok (and making libavcodec handle more aspects
> of hw decoding is welcome). But I have some doubts whether it will
> still be possible for me to handle preemption as well as I could, and I
> wouldn't appreciate if a small incremental improvement breaks all of my
> code.
Unless you have a _concrete_ enhancement request before next Tuesday, I will
go ahead and try to address Diego and any further feedback. I am definitely not
waiting an indefinite amount of time for the sake of an abstract request, and
potentially holding up new codec support. Plus I would like to fix this before
VLC 2.2.0.
Specifically as regards preemption, I think it remains doable. In principles,
this makes no real difference; you can still wrap the callback in a similarly
inconvenient manner as before and with the same limitations.
I think however that you have already demonstrated that preemption needs fixing
at the back-end. But the venue for that discussion is the VDPAU FreeDesktop
list, not libav-devel. Regardless, this patch does not increase the risk of
needing yet another API change for preemption for those apps that do care; I
don't see why yet another interface break would be needed either way.
> Also, think of the API users: do they have to update their vdpau code
> every month now? WTF?
I fail to see how this forces anybody to update. This should be backward
compatible with the previous three variants of the VDPAU hardware
acceleration. Once a month? obvious troll is obvious.
Of course, backward compatibility will break if/when new chroma types are
implemented, e.g. Hi10p. Sorry but I *told* *you* *so*. IIRC, you were among
the developers to object to different pixel formats for different chroma types.
I can still make that change if people changed their mind.
> A solution to this might be not deprecating the "old" API. Then
> downstreams can wait it out until the API finally becomes sane after a
> bunch of more incremental improvements. This is true for the other
> hwaccels as well (since I always hear of hwaccel 1.x...).
The whole point of the series is to insulate applications from:
- new codecs, profiles and levels (for real),
- new chroma types,
- new function calls (as far as possible).
If we postpone the change, all VDPAU-enabled applications will need updates
for HEVC then Hi10 and who-knows-what later. That seems like a worse
alternative on all counts.
My NVIDIA colleagues and I would also prefer to have more exemplary code in
libavcodec. I cannot say that I am satisfied with the current state of affairs.
In fact, I wanted something like this patch from the beginning. Only at the
time, that was not yet possible for lack of init, uninit and priv_data_size.
--
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
