[vdr] Re: Problems with xine's aspect ratio & padding with 4:3
lucianm at users.sourceforge.net
Wed Apr 12 12:35:07 CEST 2006
>> 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
> 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
> 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.
> 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