[FFmpeg-devel] About xvmc_acceleration

[Reimar Döffinger]

On Fri, Feb 13, 2009 at 11:40:12AM +0100, Gwenole Beauchesne wrote:
> On Fri, 13 Feb 2009, Reimar D?ffinger wrote:
>> The XvMC case is just checking against two different PIX_FMTs,
>> the codec-specific checks for VDPAU can be replaced by 1 or two pix_fmt
>
> XvMC has only two PIX_FMTs, but VDPAU has 5, VA API has 8, DXVA will have 
> at least 3.

They have at most two per codec-specific file like h264.c

> Will you want to check against each individual pix_fmt for the 
> common code?

very much hope/expect that all hardware decoders will use the same code
in the common parts/performance critical parts, so that things like
avctx->flags & CODEC_FLAG_SKIP_DECODE
or
avctx->flags & CODEC_FLAG_SKIP_IDCT
could be used.

>> checks, too, and the stuff in the common code IMO would be much nicer if
>> it used a check against a appropriately named flag, e.g.
>> CODEC_FLAG_SKIP_DECODE (actually this should be used in the codec
>> specific parts, too, where it is appropriate).
>
> And where would this CODEC_FLAG_SKIP_DECODE flag added? Assuming/hoping the 
> user won't forget about it in his initialization code?

Of course not! I actually dislike that this information would be in some
kind of user-visible place at all (which also is one of my objections
about xvmc_acceleration).
The question is: what is xvmc_acceleration supposed to mean when it is
set before calling avcodec_open (will that be allowed)?
What is it supposed to mean when the codec sets it (is that allowed)?
What happens when the user sets it directly after avcodec_open or in the
middle of decoding (would that make any sense to do)?
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).

Greetings,
Reimar D?ffinger