[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 

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).


More information about the ffmpeg-devel mailing list