[FFmpeg-devel] About xvmc_acceleration

[Gwenole Beauchesne]

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

>> 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?
>
>
> Well, that is all quite ok, but if you do _not_ allow the user to set it
> you still lack a way to request real hardware decoding (i.e. returning
> YV12).

I probably forgot to mention an extra bit to request the accelerator fetch 
the resulting frames. either a CODEC_FLAG_* or something else. And, if we 
have another variable than pix_fmt to specify the accelerator, we can 
stick pix_fmt to YV12 + setting that flag if we need decoded frames in 
system RAM.

But I am missing a way to actually handle the following case:
- an accelerator that needs ::get_buffer() et al. for correct operations 
(typically VDPAU, VA API)
+ the user requested the decoded frames in system RAM.
What would be the correct interface for that and that would avoid 
round-trips to libavcodec?

I agree, there is no problem with a pure HW accelerator otherwise.

i.e. I would like to avoid:
- FFmeg: "hey, here are the HW formats I propose you"
- User: "OK, I choose X"
- FFmpeg: "Do you want the decoded frames in system RAM?"
- User: "No, thanks" -- or "Yes, in Y format"
=> any way to have a single answer/reply?

If the user sets the CODEC_FLAG_ for decoded frames in system RAM itself, 
and returns the non-HW pix_fmt right away (single pass), libavcodec would 
have no chance to actually initialze the AVHWAccelCodec based on the 
initially matching pix_fmt. Do you follow me?

> So do I understand you right that xvmc_acceleration would be a purely
> internal thing that the user is supposed to never set or read and only
> part of the public API for lack of a better place?

Exactly. Though, to be honest, the original values for xvmc_acceleration 
are obscure to me, which was my initial question too. ;-)