[FFmpeg-devel] About xvmc_acceleration

Ivan Kalvachev ikalvachev
Fri Feb 13 11:41:49 CET 2009


On 2/13/09, Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> On Fri, Feb 13, 2009 at 09:59:04AM +0100, Gwenole Beauchesne wrote:
>> Is some xvmc_acceleration different than 2 used nowadays? I wonder because
>>
>> I'd like to replace xvmc_acceleration by an hwaccel_id = {HWACCEL_ID_NONE,
>>
>> HWACCEL_ID_XVMC, HWACCEL_ID_VAAPI, ...}.
>
> What exactly would be the purpose of this?
> I do not like having a global, user modifiable variable that exactly
> duplicates the information in pix_fmt.
> 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
> 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).
> Admittedly that assumes that the different API will mostly need to skip
> mostly the same parts of the code, and mostly the codec-specific packing
> into AVFrames/slices will need to differ between the APIs.

It is speed enhancement.

xvmc_accel/hdaccel_id having value of 0, is sure indication that
we are in full software mode and there is no need to mandatory
check 4-5 different pixfmt values to figure out that.
These checks could cause significant speed loos if used in inner loops


I don't mind changing the xvmc_acceleration name, but I object
making it enum. Compilers could choose to use uint8_t for enum
if the values could fit into it. It's kind of hazard for binary compatibility.
The gcc does that with -fshort-enums




More information about the ffmpeg-devel mailing list