[FFmpeg-devel] About xvmc_acceleration
Fri Feb 13 14:17:36 CET 2009
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
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
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. ;-)
More information about the ffmpeg-devel