720x480 over Composite?

I was wondering how the Raspberry Pi can be configured to output video in widescreen (720x480) over composite video. Right now, I'm just getting a 4:3 aspect ratio output, with black bars on the top and bottom. This is my config.txt (these options don't seem to be doing anything):

Code: Select all

sdtv_aspect=3
hdmi_group=1
hdmi_mode=6


framebuffer_width=720
framebuffer_height=480
(and you can remove the other commands)

framebuffer_width=720
framebuffer_height=480
(and you can remove the other commands)

I tried but everything looks the same (4:3 aspect ratio with black bars on top and bottom, LXDE display settings claim a resolution of 656x416).

The picture isn't very good, but illustrates the problem. I've got the Pi plugged into a portable TV, if that matters.

EDIT: On a side note, when I set disable_overscan=1, I lose the black bars on the top and bottom, but everything is still in a 4:3 ratio, so the left and right portions of the screen are covered up by black bars.

(I have a widescreen composite driven display as well, and mine just doesn't support a widescreen signal. It only supports a stretched fullscreen/4:3 signal.)

Can you confirm anywhere the native resolution of the display? (Online specs, etc.)

Because the display is a portable LCD TV, it has a low resolution (I forget what exactly). However, it does support the input of widescreen TV (I've tried over-the-air HD and it worked perfectly). Essentially, it is a widescreen TV that supports the input of resolutions greater than itself. It is possible that it only supports 4:3 ratios (I will test this soon with a DVD player), but this still doesn't explain why changing the framebuffer size did nothing.

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

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.

To make matters worse, the TV's original remote controller no longer works, and the replacement doesn't have all the functions, so I can't set the aspect ratio manually.

Mind you, all this is largely academic, as the low refresh rate gives me a headache anyway Back to "booking time" on the main TV until I can find a cheap monitor...?

[mahjongg]

Maybe I'm missing something, and correct me if I'm wrong, but my impression from what I've read about the composite functionality is that its simply a down scaled (to PAL or NTSC resolutions) version of whatever is output on the HDMI port. AFAIK you do not have any control over what resolutions are output, except that you can switch between TV norms.

[dom]

So what is the desired behaviour?

Would you like a framebuffer that is reported as:
720*(16/9)/(4/3) = 960 wide?

I.e 960x480?

So what is the desired behaviour?

Would you like a framebuffer that is reported as:
720*(16/9)/(4/3) = 960 wide?

I.e 960x480?

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.

That said, I can't take the awful flickering (maybe it would be tolerable on a 12" or 14" CRT, but on a 32" one, it's torture), so I'm probably going to plug the Pi back into our flat-screen TV soon. I have a tendency towards migraines

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.

Same issue,

The sdtv_aspect setting looks like a placebo, everyone seems to ignore-it.

I connected my RPi to a cheap 4.3" LCD whose aspect ratio is 16:9 and accepts PAL, NTSC & NTSC_J signals.

Regardless of what sdtv_aspect or framebuffer_width/framebuffer_height i set, omxplayer will say:

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 ?

Thanks.

Not sure if this helps or not but in analogue land "widescreen" doesn't really exist. Even DVDs are only ever 720x576 or 720x480. Widescreen films simply have a flag that tells a display device to stretch the picture. So I'm not really sure if the composite output can output "widescreen" as such. I think all the Pi can do is squash a widescreen shaped grid of pixels into a 4:3 screen which a display can then stretch back out to widescreen.

That's what i'm talking about. The "squash_everything_horizontaly_because_the_display_will_strech_to_16_9" flag.

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.

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_signaling

In this article a lot of photos where the signal is visible on some broadcasts. http://www.associazionemarconi.com/publ ... 321-125239

Now, the difference between a 4:3 and a 16:9 broadcasting is that the image is squeezed vertically, on CRT TV sets this means that the vertical amplitude is reduced to accomplish a 16:9 aspect ratio, but the resolution is the same.


Look, ma! 16:9! And some teletext is visible too!

Where I worked we had a wide screen studio fitted with very expensive grade 1 wide screen CRT monitors. Actually they were very expensive grade 1 4x3 CRT monitors with a bit of cheap plastic masking off the top and bottom

Same issue,

The sdtv_aspect setting looks like a placebo, everyone seems to ignore-it.

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 ?

Thanks.

I think there's a bug in omxplayer.
I've made some test: using yhe yt program, I displayed

* a test card W video http://www.youtube.com/watch?v=OzHB5oFrCvc for 16:9 test
* a PM5544 test card video http://www.youtube.com/watch?v=G-M9_k2N4uo for 4:test
* the result of the command:

Code: Select all

vcgencmd get_config int && vcgencmd get_config str

Then i feed the signal into a bt878 screen capture card and there are the results (click on the images to enlarge):

When in 4:3 mode i get:



Note that the geometry is 640x480, due the overscan adjust, and that omxplayer displays the image in another layer, superimposed to ther framebuffer device: you'll se in the test card w image with yt menus behind.

When in 16:9 mode for the omxplayer output I get the same images from omxplayer:




Note that the geometry on the framebuffer is 880x480, the characters are shrinked, but the output of omxplayer is the same for the 4:3 version. The Linux framebuffer reads the aspect ratio flag and changes the framebuffer used, but omxplayer seems that discards this information ad assumes a 4:3 output.

[dom]

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.

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

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.

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.

[dom]

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.

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.

Actually I think the problem is much deeper.
Somehow the video_render of the omx framework does not care about the aspect ratio of the SDTV mode set with tvservice. The video render always assumes, I think square pixel, which is not desired for anamorphic output.
Ok you can say maybe, that maybe it cannot communicate with tvservice, but I have found so far no was to set the pixel aspect ratio of the display in the renderer.
You can of course set the source pixel aspect ration in OMX_CONFIG_DISPLAYREGIONTYPE, but this is not the display pixel aspect ration (thus the destination pixel aspect ratio), but the pixel aspect ratio of the video you are playing.
Anyway, any suggestion how to tell the video render the display pixel aspect ratio is appreciated.

Marten

[dom]

OMX_CONFIG_DISPLAYREGIONTYPE contains a source rectange and a dest rectangle.
If you set noaspect=1, then with the source and dest rectangle you have complete control over scaling.

Assuming you know pixel aspect ratio and display aspect ratio you can compensate for both.

I agree it would be nice to set noaspect=0 and rely on letterbox/fill just working, and in fact I've found a patch on another branch that implements this.
It adds a display_x/display_y to OMX_CONFIG_DISPLAYREGIONTYPE, which breaks /opt/vc/lib vs start.elf compatibility, so I'm probably not going to pick this up soon.
I'll try and grab it before we switch to newer firmware tree. (I'll also add aspect ratio information to vec_get_display_state).

For now source and dest rects should do what you want.

Thank, well I know about the dest and source rects. Anyway I will wait until a more elegant solution is available, since I believe most users will use vomp with hdmi. (For analog output the mvp is better than raspberry pi)

It adds a display_x/display_y to OMX_CONFIG_DISPLAYREGIONTYPE, which breaks /opt/vc/lib vs start.elf compatibility,

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

Just another question, the aspect ratio you pass to vc_tv_sdtv_power_on, what does it mean?
Well, I think it is related to WSS, but there are at least two possibilities in WSS. One is saying a 4:3 image carring let say 16:9 content in letterboxing or an anamorphic 16:9 image.
If it is the first one, OMX behaves correctly. But it would then be nice to also add the second one.

Marten

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.

[dom]

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.

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.
Hopefully we'll switch to "next" firmware tree as a default, and then I can commit my omxplayer changes.