[FFmpeg-devel] hwaccel infrastructure in libavcodec

[Gregor Riepl]

> I was under the impression that the "right" API for OSX would be VideoToolBox:
> http://www.tuaw.com/2011/01/20/xbmc-for-ios-and-atv2-now-available/
> (It supports more hardware and more features, iiuc.)

I haven't looked at that so far. But if the comments further down (about
being a private framework) are true, I don't think it wise to use it.
Apple can change or deprecate it at any point of time. I know the hell
of kernel extensions that tap into private part parts of the Mach
kernel, and the situation with frameworks is only slightly better.

> (I can only speak for VDPAU)
> I am not sure if this is what the users of the players would find helpful.
> Decoding alone is nice, but - imo - not what makes VDPAU so (very) useful: The
> De-interlacer is the important part, especially since it is not easy to find a
> system where decoding with VDPAU is faster than with the CPU.
> (Disclaimer: I - still - did not test this but I would be surprised if that were
> wrong.)

Well, for one, I don't think there is any reason why VDPAU deinterlacing
should not be offered by ffmpeg.
Suggestion: Add a module to libavfilter that accepts only the
PIX_FMT_VDPAU_* picture formats as input and outputs the same. Behind
the scenes, it sets up deinterlacing or whatever filters VDPAU offers
instead of doing the filtering in software.

As for VDPAU being better than CPU decoding, there's NVIDIA Ion, which
is usually paired with a very slow CPU. For example, my Media Player Box
has a Atom D510 and a Ion2. Playing 1080p material on this CPU would be
outright impossible. The Ion can handle it nicely, even if it is 60fps,
has lots of motion and insane bitrates.
I expect the situation will be similar with AMD Fusion, especially the
low-power variants (C-50 et al).