One Video Decoding API to rule them all

One Video Decoding API to rule them all

[Peter Paul]

Hi,
currently we've got three APIs to accelerate video decoding in hardware,
but to cover all available video decoding hardware, an application
writer would have to support all of them.
There is VDPAU which has a prominent supporter with nvida and is
implemented by the proprietary nvidia and S3 driver.
Than there is VA-API that is implemented in the proprietary poulsbo
driver and that can use VDPAU or AMD's proprietary XvBA as a backend.
And more recently we got CrystalHD that is implemented by Broadcom's
eponymous driver and targets their dedicated video decoding chips.
Now there are already applications that take advantage of one or more of
those APIs, but hardly anyone can support all of them, thus always
excluding users of specific hardware.
I think it would therefore be helpful to have an official statement
which API is the preferable one so, that the open source drivers and
applications could migrate to that one.

Regards,
Peter

Re: One Video Decoding API to rule them all

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Fri, 19 Feb 2010 17:39:00 +0100, Peter Paul said:

> I think it would therefore be helpful to have an official statement
> which API is the preferable one so, that the open source drivers and
> applications could migrate to that one.

What you need is a statement that API XYZ is the One True API, *and* statements
from the non-XYZ vendors that they intend to move in that direction.  Let's
face it - if you don't get NVidia and AMD saying they're both going in the
same direction, you end up having to support both directions no matter what
we say regarding the desired direction.

Anybody who doesn't believe that is invited to look at some of the APIs that
distros are carrying as patches for 18 months and more, even though Linus
has publicly called the API a piece of crap.

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: One Video Decoding API to rule them all

[Peter Paul]

On Friday, 19.02.2010, 13:48 -0500 Valdis.Kletnieks@vt.edu wrote:

> What you need is a statement that API XYZ is the One True API, *and* statements
> from the non-XYZ vendors that they intend to move in that direction.  Let's
> face it - if you don't get NVidia and AMD saying they're both going in the
> same direction, you end up having to support both directions no matter what
> we say regarding the desired direction.

I was more thinking of what the Open Source drivers will move to (e.g.
will Gallium3D support VDPAU or VA-API, will the CrystalHD API remain or
will it be changed to use VDPAU/VA-API).

Re: One Video Decoding API to rule them all

[Felipe Contreras]

On Fri, Feb 19, 2010 at 6:39 PM, Peter Paul <abnominales@web.de> wrote:
> currently we've got three APIs to accelerate video decoding in hardware,
> but to cover all available video decoding hardware, an application
> writer would have to support all of them.
> There is VDPAU which has a prominent supporter with nvida and is
> implemented by the proprietary nvidia and S3 driver.
> Than there is VA-API that is implemented in the proprietary poulsbo
> driver and that can use VDPAU or AMD's proprietary XvBA as a backend.
> And more recently we got CrystalHD that is implemented by Broadcom's
> eponymous driver and targets their dedicated video decoding chips.
> Now there are already applications that take advantage of one or more of
> those APIs, but hardly anyone can support all of them, thus always
> excluding users of specific hardware.
> I think it would therefore be helpful to have an official statement
> which API is the preferable one so, that the open source drivers and
> applications could migrate to that one.

Who cares about the API's? I think first we need implementations, then
people can re-factor the API's.

Currently most people can use all of them through FFmpeg so there's
not much problem. So the standard API could be FFmpeg for now.

There's also OpenMAX IL which most embedded vendors provide, like
Texas Instruments. But at least on the Nokia N900 we decided to drop
the wrapper and access the ioctls directly.

Cheers.

-- 
Felipe Contreras