[FFmpeg-devel] About xvmc_acceleration

[Reimar Döffinger]

On Fri, Feb 13, 2009 at 01:32:23PM +0100, Gwenole Beauchesne wrote:
>> Also there are different cases:
>> 1) software decoding
>> 2) no hardware decoding and no or only partial software decoding (what
>> currently incorrectly is called hardware decoding)
>> 3) hardware decoding, FFmpeg calls VDPAU or whatever lib and returns a
>> fully decoded frame exactly as if software decoding had been done.
>>
>> How will your concept differentiate between those? My suggestion was to
>> use the PIX_FMT to pick out 2) (instead of using the codec), but that
>> still leaves the question of how to select 3) over 1)...
>> Obviously this can be done by making a different codec (the way we
>> currently select 2) ), but IMO this implies too much user code for
>> selecting what should be a "minor" implementation detail (at least from
>> the viewpoint of the user).
>
> IMHO, reading the decoded surface back is a matter of an extra flag, set by 
> the user (e.g. CODEC_FLAG_NEEDS_SURFACE_BITS?), and provided the 
> AVHWAccelCodec::capabilities have a FF_HWACCEL_CODEC_CAP_READBACK flag for 
> instance.
>
> 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?

> - Initialize the display dependent parts of it, if any.

Obviously only for case 2)

> - Implement AVCodecContext::get_format(), ::get_buffer(), 
> ::release_buffer()

Should not be needed for case 3) (and obviously not for 1) )

> 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?