[FFmpeg-devel] About xvmc_acceleration
Fri Feb 13 13:40:33 CET 2009
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
> 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(),
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
More information about the ffmpeg-devel