[vdr] Re: Problems with xine's aspect ratio & padding with 4:3 aspect ratio

Lucian Muresan lucianm at users.sourceforge.net
Wed Apr 12 12:35:07 CEST 2006

C.Y.M wrote:
>> Not yet, I think. I know, it's very annoying, and when using a non-X11
>> xine frontend like fbxine or df_xine there isn't any possibility to
>> _properly_ adjust the aspect ratio on TV. Having to manually adjust
>> zooming or even fixed aspect ratios is nothing we would want to do on a
>> STB-like system when switching channels.
>> Once I fixed this behaviour in df_xine (DirectFB-devel ML), but the
>> author of df_xine then didn't care to adopt my patch, mainly because he
>> doesnt see such artifacts, I think, like it often happens with someone
>> who has no need for something, or due to own hardware/software setup
>> can't reproduce odd behaviours.
>> Well, my patch was finally achieving what I wanted: not having me to
>> cycle through df_xine's built in fixed aspect ratios on each switch to a
>> channel with strange resolutions (like 544x576 or even less horizontal
>> resolution -  you see I'm talking about PAL, but the problems are the
>> same). The "automatic" setting which df_xine was origanlly offering
>> produced terrible judder on the TV-out, mainly because of field parity,
>> I guess, and it didn't care of pixel aspect anyway.
>> I think it is time to try and fix this deeper in the code of xine-lib...
> I have finally been able to fix the aspect ratio on the television with the
> nvidia XV display drivers. :)  There are a few things that I had to do.
> 1) I am using version 8178 proprietary drivers (not latest version)
> 2) In xorg.conf, it is necessary to have the following options set (please note
> that "DisplaySize" is *required* for xine to get the right aspect ratio and also
> note that these ModeLines are specific to my setup only):
> Section "Monitor"
>         Identifier      "Monitor1"
>         HorizSync       30-50
>         VertRefresh     60
>         Option          "DPMS"
>         UseModes        "tv modes"
>         DisplaySize     648 488 # Width(mm) x Height(mm) of tv's display
> EndSection
> Section "Modes"
>         Identifier      "tv modes"
>         ModeLine        "800x600_60"      40.00    800  840  968 1056    600
> 601  605  628 +hsync +vsync
>         ModeLine        "720x480_60"      28.20    720  736  856  896    480
> 490  493  525 -hsync -vsync
> #       ModeLine        "720x480_NTSC"    27.5     720  744  800  872    480
> 483  485  525 -hsync -vsync
> #       Modeline        "720x480_NTSC"    27.5     720  760  816  872    480
> 483  485  525 -hsync -vsync
> EndSection
> 3) THIS DUMB OPTION WAS THE MAIN PROBLEM. After reading all the documentation, I
> thought that the "TVOutFormat" option was required. When I commented out the
> following line in my xorg.conf, all of the sudden, the picture was not skewed:
> #Option          "TVOutFormat"                   "SVIDEO"
> The black borders around the picture were gone.  So, I really recommend you dont
> use the "TVOutFormat" directive. haha.  Xine looks good now.. although, it sure
> would be nice to be able to control the vertical and horizontal overscan via
> VDR's options. :) Sometimes a little vertical overscan is necessary. Also,
> setting up dual X displays with a single dual head card is the way to go.  I do
> not recommend using TwinView.
> ftp://download.nvidia.com/XFree86/Linux-x86_64/1.0-8756/README/appendix-p.html
> Hope that helps someone.

I'm glad there is a solution for X11-based setups. Then, what I said 
about pixel aspect ratio still has to be handled for framebuffer 
frontends, as there is no way to tell them like in x11 windows, what 
geometry to use, they just display at screen resolution, but they are 
ignoring physical display sizes, therefore aspect is mostly wrong with 
content which is not 720x576 for PAL, or 720x480 for NTSC, (and those 
are mostly with much smaller horizontal resolutions, and the content 
aspect ratio set to 4:3). Anyway, a xine problem.


More information about the vdr mailing list