2014-09-18 14:34 GMT+02:00 Rémi Denis-Courmont <[email protected]>:
> Le 2014-09-18 14:39, Gwenole Beauchesne a écrit :
>>>
>>> You could define a function for the special case that the application
>>> wants
>>> to use hardware decoding in a completely transparent fashion. But that is
>>> a
>>> special case of its own. I still don't see the benefit in not having
>>> specific functions for what are non-transparent cases anyway.
>>
>>
>> The transparent usage model doesn't need anything special, but a flag
>> and possibly the hwaccel_device if libavcodec is not told to allocate
>> its own.
>
>
> Even that's not true. The application may still want to negotiate which
> piece of hardware does the decoding. This is true on dual-GPU laptops, this
> is true on transcoding hardware (where you may want to match decoding and
> encoding sides) and this is true if you have run-time selection for the
> rendering primitives (say X11 vs Wayland vs EGL).
I don't think we are telling different things here...
> Not only that but hardware acceleration can be slower or faster depending on
> what happens downstream. Or maybe hardware acceleration is slower but more
> energy-efficient. Then too, the application should know what it's doing,
> even if decoding can be accelerated transparently.
The application is bound to know, since it would have explicitly
created an hwaccel_context in the first place. I am not proposing to
automagically enable hwaccel by default, without user control. That's
insane. I am proposing for the application to provide the
hwaccel_device it wants, or nothing if it lets libavcodec create one,
should this be desired and possible, conditioned by the fact that the
hwaccel_context is bound to be created based on a particular hwaccel
impl.
hwaccel_context != hwaccel_device here. Or help me find better names
if you want. Here, hwaccel_device = opaque that holds a VADisplay, or
{ VdpDevice, VdpVTable } pair that is created with say
av_hwaccel_bind_vdpau_device(), and where you can stuff additional
things, like your surface pool. hwaccel_context = opaque for
libavcodec purposes that holds that hwaccel_device and any other
relevant data for the hwaccel impl.
> Even if you can decode "transparently" into CPU-addressable memory, that
> does not mean you should. No matter what, the application needs to
> explicitly sign up for hardware acceleration, even if libavcodec takes care
> of everything internally.
I don't want that to be the norm either, far from it. But if some
people really want that, that shouldn't be a hard step either, instead
of having the same amount of code around for every single application.
I personally don't care of having the decoded pixels in system memory,
but that could be helpful for certain usages. One was actually VLC.
>>>> Your hwaccel_device is where you could import a pool of hwaccel
>>>> surfaces if needed.
>>>>
>>>> However, we need to have at least one common baseline usage model.
>>>
>>>
>>>
>>> This may be possible for decoding-only acceleration (into CPU memory),
>>> but I
>>> don't think it even makes sense for full acceleration. Surface allocation
>>> is
>>> per-backend, post-processing is per-backend and rendering is per-backend.
>>
>>
>> Surface allocation is per-backend, and video processing is
>> per-backend, yes. But that backend implementation can live in
>> libavcodec in most practical use cases on Linux at least. There is no
>> real reason to have that process be a per-application burden either...
>
>
> No thank you. This breaks VDPAU and you know it.
Haven't I mentioned already that there is no breakage here, that is
still possible. I said, "can", not "shall". I use precise words for a
reason. If you think that's not clear enough, I can elaborate for
sure.
>> As to rendering, on certain platforms (Linux), this can be a quite
>> common thing... called EGL for instance. i.e. you'd just need an
>> additional way to expose the underlying surface buffer handles.
>
>
> I don't want to limit hwaccel to EGL output.
Fortunately, neither do I. That was an example. You can output to KMS
too if you want. Or still use the system hwaccel APIs to do that.
That's absolutely not an issue.
> I think limitting VA-API in such a way is a terrible idea, though I don't
> really care. But limitting ALL backends with only VA-API in mind, that's
> just wrong.
Please read up, where did I mention this to be exclusively based off
VA-API, which isn't at all? I am actually thinking with VDPAU, among
others in mind, and I don't see incompatible usage models.
Have you read Luca's blueprint page? We are talking of the same thing,
and I don't even see any mention of "vaapi" there.
> (...)
>>
>> I honestly think we should start off an application developer point of
>> view.
>
>
> Oh really? I was under the impression that as the most active VLC developer,
> I qualified as an application developper. Hendrik is also an application and
> seems to agree with me.
>
>> Do we really want him to know the finest details of per-hwaccel
>> initialization process, hand cruft various rendering options, etc.?
>
>
> No. I don't care about the codec-specifics and that's why I'm trying to
> shovel them behind the libavcodec API. But I do care about hardware device
> initialization and surface allocation.
Great! We are saying the same things then. The model we were
discussing allowed all this.
{ HW device initialization } x { built-in, external surface allocation
} x { native hwaccel surfaces for rendering, sysmem, or dma_buf
sharing }.
>> Or should we try to make usages simple, while still making it possible to
>> have more elaborated use-cases?
>
>
> You are trying to simplify it at the expense of functionality, of
> compatibility with existing applications and of support for some of the
> existing back-ends. That's not acceptable.
It is still possible to maintain compatibility. If you can browse
through the archives, 3+ years, there was actually an initial
implementation that worked and provided the normal compat layer.
Besides, I didn't say the libavcodec implementation would be simple,
it won't. But at least, it can offer various usage models to the
application developer.
> I can see how this fits the Intel OTC agenda though.
You will hardly see libavcodec on Intel agenda, tbh. Or do you have
any other information I don't?
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
