[FFmpeg-devel] hwaccel infrastructure in libavcodec

Stefan Gehrer stefan.gehrer
Wed Mar 16 07:45:08 CET 2011

On 03/16/2011 05:04 AM, Gregor Riepl wrote:
> Drawing attention away from the recent happenings (I noticed only after
> the switch to the new list domain today), I want to address a topic that
> has been bothering me for a while.
> Over the last 12 months or so, the support for hardware accelerated
> video in PC platforms has improved considerably. Apple released VDA[1],
> AMD has finally opened up XvBA to the public[2].
> Having tried (and given up for now) to integrate VDA support into
> MPlayer and libavcodec, I'm coming forth to ask for some help improving
> the hwaccel parts of ffmpeg. This would facilitate integrating the
> various APIs (notably DXVA, VDPAU, vaapi, XvBA, VDA, XvMC and
> Openchrome) into existing video players that already rely on libavcodec
> for video decoding.
> There are other options, for example improving vaapi support, so
> decoders that are accessible through this API can be easily made
> compatible. This has the disadvantage that it would only work on Linux
> and similar platforms, where vaapi is currently available.
> As for now, I have a basic understanding on how to use VDA and how XvBA
> and VDPAU work. I have started working on a VDA patch for ffmpeg on my
> own, but hit three major showstoppers. One of them is a specific quirk
> of VDA, requiring a valid avcC block for initialization (which is not
> available from every container format I believe).

Requiring an avcC block for initialization is a bad approach as this
block contains headers that may change during the course of a stream.
But being as it is, this sounds like you need kind of the reverse of
h264_mp4toannexb_bsf.c, which takes an avcC block and injects the
contained headers into an AnnexB (elementary) stream. Such reverse
would not be possible for all streams, but for many.

More information about the ffmpeg-devel mailing list