[FFmpeg-devel] About xvmc_acceleration
Gwenole Beauchesne
gbeauchesne
Fri Feb 13 14:02:45 CET 2009
On Fri, 13 Feb 2009, Reimar D?ffinger wrote:
>> I think a user shall only have to do the following:
>> - Choose the HW accelerator he wants
>
> Should not be necessary for case 2), can be done in get_format, so what
> is the point of it for that case?
And how would you decide between VA API, VDPAU or other accelerators if,
as requested, we hand out all possible HW accelerated formats to
::get_format()?
What if the user does want to use VA API instead of VDPAU, or a CUDA
implementation instead of VDPAU, or whatever?
>> - Initialize the display dependent parts of it, if any.
>
> Obviously only for case 2)
For case 3) too, because the video acceleration API on Linux depend on an
X display (or EGL context). Those APIs, though not all, have functions to
read the surface back.
>> - Implement AVCodecContext::get_format(), ::get_buffer(),
>> ::release_buffer()
>
> Should not be needed for case 3) (and obviously not for 1) )
This is true for a display-independant accelerators (OpenMAX, Davinci,
CUDA?) but it's still needed for those that allow reading the surfaces
back into system RAM.
>> The rest is internal magic the user shall not have to care about. That is,
>> we need to:
>> - Drop any form of hardware accelerated "AVCodec" exposed to the user
>> - Internally, we'd need an "AVHWAccelCodec" instead that contains callbacks
>> to actually do the work
>
> Sorry if you already explained it and I missed it, but what kind of
> callbacks?
I have just sent a mail with my current WIP of yesterday. Not cleaned yet,
but it should give a rough idea. Note, this does not include the VDPAU
replacements, so it will fail if used as is (MPlayer parts are missing
too, for testing).
HTH,
Gwenole.
More information about the ffmpeg-devel
mailing list