[FFmpeg-devel] About xvmc_acceleration

[Gwenole Beauchesne]

On Fri, 13 Feb 2009, Reimar D?ffinger wrote:

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

I think we can declare those cases as "undefined behaviour". Really, there 
are already variables specified as "don't touch, used by libavcodec XXX". 
If the user wants to do things that clearly are not allowed to, then I 
think it's his fault and let him burn himself. i.e. let's just declare 
that as "read-only, set by libavcodec foo()". Or create an 
AVCodecContextPrivate struct and stuff any libavcodec things into it?

BTW, a user could very well do stupid things like avctx->codec=NULL, 
avctx->codec_id=0, or whatever. I don't think we have to care beyond what 
we decide he is allowed to do or not.

Oh, I found a place for your flags instead. What about the 
HWAccelCodec::capabilities? Though, I don't like bitmasks for 
decode|idct|whatever. IOW, what would a SKIP_DECODE|SKIP_IDCT mean, 
especially if the former implies the latter? I mean, there would be "dead 
combinations" that wouldn't mean anything useful or are partially implied.

> 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
- Initialize the display dependent parts of it, if any.
- Implement AVCodecContext::get_format(), ::get_buffer(), ::release_buffer()
- Put the rendered surface on-screen (or) use the rendered surface 
readback 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
- Have libavcodec call vaRenderPicture(), VdpDecoderRender() et al. 
itself. Note: that supposes the accelerator support libs are not display 
dependent. i.e. they are split into a "core" part and a "display" part, if 
any.

Do we at least agree on those requirements/use-case?