Deleted


25 posts
by karl128k » Tue Jun 12, 2012 11:26 pm
Deleted
Last edited by karl128k on Wed Mar 19, 2014 5:06 pm, edited 1 time in total.
Posts: 11
Joined: Tue Mar 06, 2012 4:11 am
by JeremyF » Wed Jun 13, 2012 1:11 am
framebuffer_width=720
framebuffer_height=480
(and you can remove the other commands)
{sig} Setup: Original version Raspberry Pi (B, rev1, 256MB), Dell 2001FP monitor (1600x1200), 8GB Class 4 SD Card with Raspbian and XBMC, DD-WRT wireless bridge
Posts: 522
Joined: Wed Jan 25, 2012 9:06 pm
by karl128k » Wed Jun 13, 2012 1:43 am
Deleted
Last edited by karl128k on Wed Mar 19, 2014 5:06 pm, edited 1 time in total.
Posts: 11
Joined: Tue Mar 06, 2012 4:11 am
by JeremyF » Wed Jun 13, 2012 1:59 am
(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.)
{sig} Setup: Original version Raspberry Pi (B, rev1, 256MB), Dell 2001FP monitor (1600x1200), 8GB Class 4 SD Card with Raspbian and XBMC, DD-WRT wireless bridge
Posts: 522
Joined: Wed Jan 25, 2012 9:06 pm
by karl128k » Wed Jun 13, 2012 4:20 am
Deleted
Last edited by karl128k on Wed Mar 19, 2014 5:06 pm, edited 1 time in total.
Posts: 11
Joined: Tue Mar 06, 2012 4:11 am
by Emill » Wed Jun 20, 2012 10:22 am
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.
Posts: 1
Joined: Wed Jun 20, 2012 10:07 am
by tawalker » Mon Jun 25, 2012 5:39 pm
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.

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...?
---
Raspberry Pi Model B ("ryo-ohki") - Arch Linux/ARM (hard float)
Visit Eee 701 Planetoid (http://eee701planetoid.wordpress.com/) for continuing adventures with an Eee 701SD and Raspberry Pi...
---
Posts: 180
Joined: Tue Jan 17, 2012 9:02 am
by mahjongg » Mon Jun 25, 2012 5:55 pm
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.
User avatar
Moderator
Moderator
Posts: 4505
Joined: Sun Mar 11, 2012 12:19 am
by dom » Mon Jun 25, 2012 6:08 pm
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?
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by tawalker » Mon Jun 25, 2012 6:15 pm
dom wrote: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 :(
---
Raspberry Pi Model B ("ryo-ohki") - Arch Linux/ARM (hard float)
Visit Eee 701 Planetoid (http://eee701planetoid.wordpress.com/) for continuing adventures with an Eee 701SD and Raspberry Pi...
---
Posts: 180
Joined: Tue Jan 17, 2012 9:02 am
by Burngate » Tue Jun 26, 2012 9:06 am
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.
User avatar
Posts: 2334
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by psergiu » Mon Sep 10, 2012 8:04 am
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.
User avatar
Posts: 212
Joined: Mon Nov 07, 2011 8:36 am
Location: Bucharest, Romania
by MattHawkinsUK » Sat Nov 03, 2012 11:04 pm
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.
My Raspberry Pi blog and home of the BerryClip Add-on board : http://www.raspberrypi-spy.co.uk/
Follow me on Google+, Facebook and Twitter (@RPiSpy)
User avatar
Posts: 450
Joined: Tue Jan 10, 2012 8:48 pm
Location: UK
by psergiu » Sun Nov 04, 2012 7:38 am
That's what i'm talking about. The "squash_everything_horizontaly_because_the_display_will_strech_to_16_9" flag.
User avatar
Posts: 212
Joined: Mon Nov 07, 2011 8:36 am
Location: Bucharest, Romania
by michele.x » Sun Nov 04, 2012 10:50 am
Burngate 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.

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.

Image
Look, ma! 16:9! And some teletext is visible too!
User avatar
Posts: 73
Joined: Sat Sep 22, 2012 8:15 pm
by Burngate » Sun Nov 04, 2012 11:53 am
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
User avatar
Posts: 2334
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by michele.x » Sun Nov 04, 2012 4:02 pm
psergiu wrote: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:
Image
Image
Image
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:
Image
Image
Image

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.
User avatar
Posts: 73
Joined: Sat Sep 22, 2012 8:15 pm
by dom » Sun Nov 04, 2012 4:16 pm
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.
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by michele.x » Sun Nov 04, 2012 5:21 pm
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).


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.
User avatar
Posts: 73
Joined: Sat Sep 22, 2012 8:15 pm
by dom » Sun Nov 04, 2012 5:25 pm
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.

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.
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by MartenR » Tue Nov 06, 2012 7:33 am
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
Posts: 46
Joined: Sat Mar 03, 2012 9:15 am
by dom » Tue Nov 06, 2012 1:28 pm
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.
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by MartenR » Wed Nov 07, 2012 7:09 am
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
Posts: 46
Joined: Sat Mar 03, 2012 9:15 am
by Raimu » Thu Dec 13, 2012 1:58 pm
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.
Posts: 2
Joined: Thu Dec 13, 2012 1:53 pm
by dom » Thu Dec 13, 2012 4:31 pm
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.

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.
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge