Make that three I have just started experimenting with my Pi and our old CRT TV (a widescreen Toshiba), and even though my config.txt file includes "sdtv_aspect=3" (for 16:9), the Pi appears to be outputting 4:3 (according to xrandr, it's 656x416). I could just about live with that, except the TV seems to be stretching a 4:3 image to widescreen, which looks awful.Emill wrote:I have the same problem.
I have sdtv_aspect=3 in my config.txt file but I still get a 4:3 picture. omxplayer adds big borders. I know that 16:9 over composite use to send the picture in 720x576 pixels, but each pixel is not a square on the screen of course. However omxplayer should do a correct scale.
I have a CRT scren.
I'm not really sure what the Pi is capable of with the composite video output, but I suppose I'd ideally like it to display PAL or PAL widescreen resolutions (off the top of my head, not sure what the figures are for those) without the image being stretched badly or whatever.dom wrote:So what is the desired behaviour?
Would you like a framebuffer that is reported as:
720*(16/9)/(4/3) = 960 wide?
There's another method used to switch between 16:9 and 4:3 aspect ratio, and is the Wide Screen Signalling, that is a series of white dots embedded in a particular line(26) of the video signal, the nice thing is that preserved on analogue signals. http://en.wikipedia.org/wiki/Widescreen_signalingBurngate wrote:One of the features of the SCART system is the wide-screen switching implemented on pin 8 of the connector. If the voltage on that pin is ~12v the TV assumes 4/3: ~6v tells it to switch to 16/9. Of course if you are using an RCA-SCART adapter, there will be 0v on that pin.
The other thing is that most TVs try to be intelligent. Some will look for black at top and bottom or at the sides, and stretch the picture to hide that. Somewhere in the set-up menu there should be a way to switch off the cleverness so it does what you want it to do instead of what it thinks you should want.
psergiu wrote:Same issue,
The sdtv_aspect setting looks like a placebo, everyone seems to ignore-it.
I think there's a bug in omxplayer.NTSC - "display aspect 1.500000" and tvservice -s will return "720x480 @ 60Hz, interlaced"
PAL - "display aspect 1.250000" and tvservice -s will return "720x576 @ 50Hz, interlaced"
Shall i fill this as a bug against omxplayer on github ?
Code: Select all
vcgencmd get_config int && vcgencmd get_config str
vcgencmd get_config reports the sdtv_mode and sdtv_aspect correctly, so it's possible to know for an userspace application the scrren format reading these values and "get the pixels right"dom wrote:I'm not sure if the host can query the sdtv aspect ratio from the firmware using TV service.
(the fbset values could be used to guess, but they may have been changed).
I'd suggest registering a github firmware issue to support this first. Once that's available then file an omxplayer issue to make use of it.
That feels very hacky to me. Calling something like vc_tv_get_state (which gets the width/height of display) sounds like the correct solution.michele.x wrote:vcgencmd get_config reports the sdtv_mode and sdtv_aspect correctly, so it's possible to know for an userspace application the scrren format reading these values and "get the pixels right"
using s lookup table.
Are you sure, that this break compatibility, I thought that the size element in the omx structures is included in order to not break binary compatibility, if you add another value to a structure. (But may be it is something else).It adds a display_x/display_y to OMX_CONFIG_DISPLAYREGIONTYPE, which breaks /opt/vc/lib vs start.elf compatibility,
I've added aspect ratio to the query function to tvservice in the "next" firmware tree. I've (locally) modified omxplayer to respect that, and I believe I'm getting correct scaling on PAL/NTSC and 4:3 and 16:9.Raimu wrote:Now that I've picked up my Raspi I can confirm this problem is real. OMXplayer amongst other things doesn't respect the sdtv_aspect setting, which makes watching a video on a composite 16:9 telly rather jarring.
That is, if Raspi applications were aspect ratio aware, the video they output should emerge out the composite cable crunched horizontally, so the television could stretch it back to the correct aspect ratio. That doesn't happen, to my observations.