[FFmpeg-devel] About xvmc_acceleration
Fri Feb 13 13:32:23 CET 2009
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
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
Do we at least agree on those requirements/use-case?
More information about the ffmpeg-devel