[FFmpeg-devel] [PATCH] Convert XvMC to hwaccel v2

Ivan Kalvachev ikalvachev at gmail.com
Thu Dec 19 16:24:11 CET 2013

On 12/19/13, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> Ivan Kalvachev <ikalvachev at gmail.com> wrote:
>>In addition to the changes in the previous patch:
>>- this one doesn't use the define CONFIG_MPEG_XVMC_DECODER, as the
>>decoder is no longer needed and will be removed. The change involves
>>makefile too.
>>- leave FF_API_XVMC around the CODEC_CAP_HWACCEL, it is not really
>>- move the newly introduces  decode_mb() to the end of AVHWAccel struct
>>- write some explanation for pack_pblock variable.
>>Now, this is the last chance for you to review the changes before they
>>hit main repository and paint FATE in red. ;)
> I did a cursory review and found no issues. In particular I tried to make
> sure there's nothing that would break VDPAU, but still it would be good if
> someone could check.
The radeon mesa/gallium driver provides both xvmc and vdpau. So I've
tested vdpau too.

> One small issue though: it seems to me you remove the old pixfmts, does that
> mean applications not updated will break?
With the major API bump applications that are not updated will break anyway.
My first patch had old pixfmt, but it had different value from the
av_pix_fmt. If I left the original old pixfmt, it would cause
difference in the other defines (very much like
https://trac.ffmpeg.org/ticket/3144 )

> Also what about IDCT vs. MC-only XvMC, how is that selected?

The render struct/token already contains flag that indicates if the
surface is MC or IDCT. That flag have been used from the beginning to
determine if software IDCT should be used inside  mpegvideo_xvmc. So
there is no functional change in ffmpeg.

The calling application might need some changes, the biggest change
would be in the function that picks up the surfaces. If available IDCT
should always be preferred.
That's why I've used define for the new AV_PIX_FMT_XVMC that's linking
it to the existing IDCT one.

It is known that MC might be slower that software decoding, because it
expands component pixel size to 16 bits (short). Even theoretically it
needs a lot of non-coded blocks to provide any benefit.

On another note, I'm not that sure that VDPAU removal of AV_PIX_FMTs
based on codec type is that good of idea. But in XvMC case it is not a
big of a problem since it support only mpeg12.

Best Regards

More information about the ffmpeg-devel mailing list