[Arm-netbook] Sorry state of Linux hardware video decoder libraries / lack of single API

[Gordan Bobic]

On 06/25/2012 02:44 PM, Alexey Eromenko wrote:
> Hi All !
>
> The ARM CPUs, unlike Intel Core i CPUs are not strong enough to run HD
> video in software.
>
> The Allwinner A10 VPU has a cedarx library, so the main difficulty is
> developing a
> bridge between cedarx API and the various GNU/Linux media players, HTML5
> browsers and media frameworks.
> HTML5 browsers are, in fact, HD video players. (due to HTML5 video)
>
> GNU/Linux has lots of components, that may require patching:
> -Chromium browser
> -FFox browser
> -libva
> -libvpx (VP8/WebM codec library)
> -ffmpeg
> -libavcodec
> -xine
> -gstreamer
> -KDE phonon
> -VLC media player
> -VLC media framework
> -anything I forgot
> ...
>
> In other words: GNU/Linux O.S has too many multi-media frameworks,
> which makes it difficult to develop decoder drivers for various
> low-power chips (including ARM SoCs).
> This is not a problem for the powerful Intel x86 CPUs, as they can run
> HD video in software, so having dozens of MM-frameworks  works for
> them.

I'm not convinced it works for them, either. Scaling HD video (e.g. if 
you have a 1080p video and blow it up to full screen on a 2560x1600 
monitor) without accelerated GPU drivers even on x86 doesn't produce 
passable results. Not to mention oddball cases such as stretching things 
across two screens (e.g. if you have an IBM T221 3840x2400 setup), in 
which case the poor quality of even the mature proprietary drivers from 
ATI and Nvidia is likely going to bite you.

> Standardization and OpenGL:
> In the old times, before hardware acceleration, everyone did his own
> software renderer for 3D, so drivers could not be developed as each
> (MS-DOS) game used own API / library.

I suspect you'll find there are more codec libraries available today 
than there were different games using 3D acceleration under DOS 20 years 
ago. So much for standards.

> When hardware acceleration for 3D became common, the libraries for it
> became common, such as OpenGL, to unify all applications, OS vendors
> and hardware vendors.
> Same thing needs to be done for hardware video decoding stack.
>
> What can be done to address this issue ?

Cat herding?

> Is patching specific codecs (libvpx, ...) necessary ?

Maybe. It depends on whether the clever acceleration trickery can be 
performed equally well using OpenGL primitives. And on whether suitable 
OpenGL drivers are actually available.

Gordan