[FFmpeg-devel] hwaccel infrastructure in libavcodec

[Stefan Gehrer]

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.