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).
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.
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.
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.
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.
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.
(...)
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.
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.
I can see how this fits the Intel OTC agenda though.
--
Rémi Denis-Courmont
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
