[vdr] xine-lib and vaapi support
h at realh.co.uk
Mon Nov 8 16:02:24 CET 2010
On 08/11/10 12:50, Theunis Potgieter wrote:
> On 8 November 2010 13:59, lucian orasanu<o_lucian at yahoo.com> wrote:
>> how about moving to mplayer instead of xine-lib, is not maintained
>> very well any more?
> My personal experience with mplayer is that it lacks proper aspect
> ratio detection or guessing based on source that does not contain the
> correct info. xine-lib seems to handle this much better. Also
> automatic cropping is a nice feature that works quite well in the
> vdr-xineliboutput plugin (even with vdpau). Most people doesn't seem
> to mind that the output is stretched or squeezed incorrectly, but I
> do. I prefer it that a circle appears to be that and not in the
> elliptical form.
What??! You can tell mplayer the exact ratio of your monitor and the
exact ratio of the video on the command line and it correctly calculates
how to display it. vdr-sxfe and vdr-fbfe have an equivalent of
-monitoraspect but xine-ui and gxine don't, or didn't last time I
looked. Instead they query the display's dimensions from the X server,
which often gives bogus information, or xine doesn't use the information
correctly. For example, X thinks my Sony TV (1366x768 physically, but
uses a 1360x768 native resolution, connected by HDMI), measures 16m x 9m
(yes, metres!) so I override it with:
Identifier "32in TV"
#DisplaySize 708 398 # real size
DisplaySize 320 180 # lie to avoid tiny fonts
Option "UseEdiDpi" "false"
Option "DPI" "96 x 96"
Option "DPMS" "false"
But when I tried xine it was OK windowed, while in full-screen mode it
scaled and applied letterboxing as if for a 4:3 display for some reason
With xine you can override the aspect ratio of the video stream too. It
has the advantage over mplayer that you can do it on the fly, but the
disadvantage that it only has a few presets with names that don't
indicate what the aspect ratio actually is in numbers.
TH * http://www.realh.co.uk
More information about the vdr