The library delivers us pixel width/height relative to display size
so we must compute it accordingly, otherwise we have conflicting data
in i_sar_num/i_sar_den and i_aspect.

There is only one button on a touch screen.

Those are highly incomplete, especially as they aren't unrolled.
But it already decreases libmpeg2 CPU usage by 20%.

400 Mb buffer would kill almost any such (existing) system.

(This kinda sucks, but liba52 does not export is build mode through
 any public header)

It's not implemented for fixed-point. And it's so slow that it would
probably not make sense anyway.

Currently, we do not have any architecture where this would not be
a build-time constant. Constancy helps fixing a few issues in the audio
path.

The default VLC font does not exist here.

Hildon is not Maemo-specific (Ubuntu Mobile...).
And Maemo soon won't be Hildon-GTK anymore.

 It seems that depending on your driver, the resize done by
IDirect3DDevice9::Present can be of very low quality. The resize is now
done by IDirect3DDevice9::StretchRect.

All ports from an adaptor must have the same format anyway.

We *do* check the image size when parsing the format.

Simplify and avoid running a thread and an interval timer
when there is no video output.

xdg-screensaver takes care of that...
...without the 30 seconds interval timer.

Closes #3006

Closes #805

Note that this won't work on OMAP1 (ARMv<6). However a trivial change
could enable that (the JIT supports ARMv5 too).

Regression from 724461bd

Anyway, Maemo does not support XvMC, and our GLX plugin won't work
either. Also, calling D-Bus from the video output thread was causing
visible latencies in with the former Xlib/Xv plugin.