C.Y.M wrote:

C.Y.M wrote:

...

I am viewing NTSC-M with a 4:3 aspect ratio using vdr-1.3.46 and xine-0.7.8. Standard definition broadcasting. My television resolution is set to 720x480@60Hz with my ModeLine:

ModeLine "720x480_60" 28.20 720 736 856 896 480 490 493 525 -hsync -vsync

I have noticed that when I play a vdr recording (001.vdr) with mplayer using the XV video output, I get full screen on my television (no black borders) with perfect aspect ratio. But, when I play the same vdr recording (001.vdr) with xine and XV video output, there are huge amounts of padding (black borders) on the television. It is like xine can not expand the 4:3 aspect ratio to properly fit my tv. Is there a way to make it zoom out a little so it doesnt look like that with the black borders on all four sides of the video on the tv? Mplayer looks just fine at full screen.. I'm just trying to get the same output. I have tried disabling video scaling inside xine and that did not help.

Manually using the horizontal and vertical zoom in xine fixes the aspect ratio. But, I hate to have to manually fix it each time I start xine. Is there a way to automate the zoom for dvb?

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...

Just my 2 cents, Lucian

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.

Lucian