Fix OSD font width and height for non-4:3 display, letterbox modes

[gtgj@…]

This patch corrects the OSD font aspect ratio in non-4:3 displays and in different letterbox zoom modes. Currently, the fonts are too "fat" in 16:9 displays.

It also uses the actual font size in height calculations so that lines are not too close/don't overlap with >480 line video streams.

This patch also restricts the Closed Caption OSD to a 4:3 area in eg. a 16:9 video. This will be used by the ATSC CC patch provided in a separate ticket.

[danielk]

First, thanks for working on this. Now for the problems:

• The pillarboxing 16:9 screen would make implementing real ATSC captions (EIA-708) more difficult, right? Problem?
• You are grabbing the XJ_aspect for the 'aspect ratio', except in the case of 16:9 zoom. This doesn't account for non-square pixels, and it looks like you are assuming the total OSD dimensions have some correspondence to the display window size or the video size. You can not make this assumption. 'total' is sometimes the dimension of the video and sometimes the dimension of the display window...

[gtgj@…]

Thanks for the feedback.

• I haven't looked much into EIA-708 but I was thinking it would be different enough that it would likely use a different (new) OSD container (maybe more like what is going to be used for DVB/IVTV teletext?). If the current container will be extended to support EIA-708, I figured we could change its boundaries at that time.

• I don't think I've changed how the OSD dimensions are currently calculated, did I? I was only trying to change the way the fonts were displayed and how the text dimensions were calculated. I added an "aspect" ratio parameter that is supposed to specify the target OSD aspect ratio so that the fonts can be correctly scaled. This aspect ratio is normally the video aspect ratio but not in certain letterbox modes. I thought XJ_aspect was a better representation but I have to admit I'm not sure how certain letterbox modes are supposed to look like. Is there a better aspect ratio to use?

Also, I thought the displaywidth/height in the OSD class represented the OSD dimensions, not the display window size. I don't think it's even aware of the display window size.

The calculation of "wscale" is supposed to account for non-square pixels but I've only tested non-square source video pixels and not non-square display pixels. Is there a good way of testing non-square display pixels?

[danielk]

You are probably right about EIA-708 needing a different OSDSet.

Don't worry you didn't change how the OSD dimensions are calculated.

I think as is the wscale only accounts for non-square pixels in the source video, but not for non-square pixels on the display. The best way to test non-square pixels on the screen is to put your monitor in a non-square mode. If you have a 1920x1080 display, send it something like a 1600x1024 signal.

Perhaps it makes the most sense to tell the OSD about the physical aspect ratio of the dispw x disph.

[gtgj@…]

Okay, I just tried 1280x1024 resolution on a 1920x1080 display. With the patch, the OSD fonts look correct and look the same as they did with 1920x1080 resolution. This is with 1080i, 720p, and 480x480 bttv videos.

GetOSDBounds tells the OSD its width and height in "video" pixels. I think that it is sufficient to tell the OSD its physical aspect ratio (not the display aspect ratio) so that it can scale its widths appropriately. Then, only the VideoOutput? class needs to be aware of the actual display width/height/aspect -- as long as VideoOutput? scales/frames the video so that the OSD ends up shown with the correct aspect ratio. This is automatically true in normal operation because I think VideoOutput? ensures that the video is displayed with the correct aspect ratio, and in normal operation, the video aspect ratio is the same as the OSD aspect ratio.

This is what I was trying to accomplish by adding "aspect" to GetOSDBounds. I think you're probably right that "XJ_aspect" is not the appropriate number in some letterbox modes but I guess I'm still a little unclear how the various modes are supposed to look like with different display aspect ratios.

[gtgj@…]

Revert changes to OSD menu spacing and margin. This is a separate issue and that change is not the way to fix the problem (menu spacing, margin are inconsistent at different OSD sizes).

[danielk]

This was closed by [7983].

[bjm <bjm@…>]

This patch causes wide stretched fonts with normal 4:3 playback.

[bjm <bjm@…>]

Fonts are stretched relative to the recording resolution. IOW, a recording at 640X480 and displayed on 4:3 would have correct fonts. 480x480 would result in stretched fonts and 352x480 would show nearly double width fonts.

[gtgj@…]

In the OSD constructor and Reinit code, I think the calculation of wscale should be:

wscale = (float)displaywidth/(visibleAspect*displayheight);

to correct for non-square source pixels.

[anonymous]

You can't use the visible bounds of the OSD to guess at the video sources aspect ratio. It won't work for chromakey OSD, for example. Any such calculation must be done in VideoOutput? classes which have all the information needed for it.

[bjm]

(In [7993]) Closes #667

Fix for broken font scaling offered by gtgj at pacbell.net. This corrects the bug introduced this morning in [7983].

"anonymous" [sic] objects but offers no solution. He or she is welcome to generate a patch that will work for all display environments.

[danielk]

bjm, couldn't you just use XJ_aspect instead of videoAspect for the visible_aspect calculation? I think you would get the same effect without breaking things quite as much.

[danielk]

(In [7994]) References #667.

• Account for font size change caused by wscale.
• Use letterbox aspect ratio for video rather than the aspect ratio reported in the video.

[anonymous]

Refs #652.

The recent changes here have impacted my problems in #652. I'm currently running SVN 8007. In the recent bout of commits, it has changed, but not fixed, the behavior of my OSD. Before 7983, 7993 and 7994, my fonts used to normally proportioned, but the entire OSD was too large and overflowed over the left and right boundaries of my screen.

Now in 8007, the fonts are too wide and look bold. The OSD is now aligned properly relative to the left edge, but runs over the right edege.

[danielk]

(In [8021]) References #667.

• Add aspect adjustment for display pixel aspect ratio for chromakey OSD mode.
• Add aspect adjustment for video pixel aspect ratio in blended OSD mode.
• Add font size adjustment for video scaling in blended OSD mode.

[anonymous]

8021 fixes my fonts. Thanks.

The OSD boundary on is still off, for at least one theme, but I think I should leave that under #652

[danielk]

Ok, it sounds like this is working.

If someone still has problems reopen w/description.

A frontend log with the "#if 0" in videooutbase changed to "#if 1" would help.

[anonymous]

For all these sizes I tried, the fonts are virtually uniform in their width and height relative to the picture. A multi-line description wraps at the same points at any resolution. so I think you have the relative scaling licked.

However, they are uniformly compressed too narrow at any resolution. Attached is a screenshot that shows the narrowed fonts. Perhaps 1.333333 is factored in one too many times?

Decreasing recording width 640, 480, 320

VideoOutput::MoveResize:
Img(0,0 640,480)
Disp(0,0 640,480)
Offset(9,9)
Vscan(0.000000, 0.000000)
DisplayAspect: 1.333300
VideoAspect(1.333330)
XJ_aspect(1.333330)
CDisplayAspect: 1.333333
Letterbox: 0
VideoOutput::MoveResize:
Img(0,0 640,480)
Disp(0,0 640,480)
Offset(9,9)
Vscan(0.000000, 0.000000)
DisplayAspect: 1.327869
VideoAspect(1.333330)
XJ_aspect(1.333330)
CDisplayAspect: 1.333333
Letterbox: 0
2005-11-23 15:24:29.060 XJ_aspect:      1.33333
2005-11-23 15:24:29.077 videoAspect:    1.33333
2005-11-23 15:24:29.078 display_aspect: 1.32787 dpa: 0.995902
2005-11-23 15:24:29.078 vb scale:       1.33264
2005-11-23 15:24:29.078 visible_aspect: 0.995386
2005-11-23 15:24:29.078 font_scaling: 0.882425

VideoOutput::MoveResize:
Img(0,0 480,480)
Disp(0,0 640,480)
Offset(9,9)
Vscan(0.000000, 0.000000)
DisplayAspect: 1.333300
VideoAspect(1.333330)
XJ_aspect(1.333330)
CDisplayAspect: 1.333333
Letterbox: 0
VideoOutput::MoveResize:
Img(0,0 480,480)
Disp(0,0 640,480)
Offset(9,9)
Vscan(0.000000, 0.000000)
DisplayAspect: 1.327869
VideoAspect(1.333330)
XJ_aspect(1.333330)
CDisplayAspect: 1.333333
Letterbox: 0
2005-11-23 15:26:13.605 XJ_aspect:      1.33333
2005-11-23 15:26:13.605 videoAspect:    1.33333
2005-11-23 15:26:13.605 display_aspect: 1.32787 dpa: 0.995902
2005-11-23 15:26:13.605 vb scale:       1
2005-11-23 15:26:13.605 visible_aspect: 0.746928
2005-11-23 15:26:13.605 font_scaling: 0.810505

VideoOutput::MoveResize:
Img(0,0 320,480)
Disp(0,0 640,480)
Offset(9,9)
Vscan(0.000000, 0.000000)
DisplayAspect: 1.333300
VideoAspect(1.333330)
XJ_aspect(1.333330)
CDisplayAspect: 1.333333
Letterbox: 0
VideoOutput::MoveResize:
Img(0,0 320,480)
Disp(0,0 640,480)
Offset(9,9)
Vscan(0.000000, 0.000000)
DisplayAspect: 1.327869
VideoAspect(1.333330)
XJ_aspect(1.333330)
CDisplayAspect: 1.333333
Letterbox: 0
2005-11-23 15:27:34.373 XJ_aspect:      1.33333
2005-11-23 15:27:34.373 videoAspect:    1.33333
2005-11-23 15:27:34.374 display_aspect: 1.32787 dpa: 0.995902
2005-11-23 15:27:34.374 vb scale:       0.66736
2005-11-23 15:27:34.375 visible_aspect: 0.49847
2005-11-23 15:27:34.375 font_scaling: 0.754908

Decreasing recording height 480, 368, 240

See 640x480 above

VideoOutput::MoveResize:
Img(0,0 640,368)
Disp(0,0 640,480)
Offset(9,9)
Vscan(0.000000, 0.000000)
DisplayAspect: 1.333300
VideoAspect(1.333330)
XJ_aspect(1.333330)
CDisplayAspect: 1.333333
Letterbox: 0
VideoOutput::MoveResize:
Img(0,0 640,368)
Disp(0,0 640,480)
Offset(9,9)
Vscan(0.000000, 0.000000)
DisplayAspect: 1.327869
VideoAspect(1.333330)
XJ_aspect(1.333330)
CDisplayAspect: 1.333333
Letterbox: 0
2005-11-23 15:32:12.372 XJ_aspect:      1.33333
2005-11-23 15:32:12.372 videoAspect:    1.33333
2005-11-23 15:32:12.372 display_aspect: 1.32787 dpa: 0.995902
2005-11-23 15:32:12.372 vb scale:       1.73713
2005-11-23 15:32:12.372 visible_aspect: 1.29751
2005-11-23 15:32:12.372 font_scaling: 0.986669

[bjm]

Screenshot of compressed narrow fonts.

[anonymous]

Not fixed here. The latest change is an improvement over the breakage caused earlier but hasn't returned the text to the correct size, as it was a week ago.

I'm using a 4:3 standard monitor (1280x1024) without any aspect ratio or overscan overides and the isthmus OSD theme. When viewing 16:9 recordings the OSD text is _very_ small. 4:3 recordings are fine, although the text seems subtly stretched vertically. I had the OSD text set to small but switching to default didn't seem to have any affect on size at all.

[danielk]

(In [8028]) References #667.

Fix a problem with all fonts being uniformly too narrow with blended OSD.

[danielk]

anon, I can reproduce the font size changes... It looks like it is connected with the aspect ratio of the video. I'll look at this in about 1.5 hours (after dinner).

[bjm <bjm@…>]

Verified that OSD fonts look correct on 4:3 playback of 640x480, 480x480, 320x480 and 640x480, 640x368, 640x240 with [8028].

[danielk]

BTW As a quick fix for the aspect ratio problem, you can place this before "return vb;" in videooutbase.cpp: "font_scaling *= (XJ_aspect/1.3333f);".

I'm pretty sure I know where the root cause is though, so this won't the permanent fix.

[danielk]

(In [8030]) References #667.

• Adjust for aspect ratio effect on font scale.

I believe this is due to the fonts being scaled on hmult alone in OSD instead of the scale in x&y. This adjustment appears to work for video aspect ratios in the range 1.3333 - 2.0. The font size is now proportional to the vertical size of the visible video window, which appears to work well with my test streams.

[anonymous]

As the anon poster @ 11/24/05 00:21:46 I can confirm my problems now seem fixed.

[danielk]

Ok, there haven't been any new problems reported since the last commit so I'll consider this fixed until I hear otherwise.

[Simon Kenyon]

this problem has reappeared.

i originally comment thus on the -dev list and a couple of people have said that they also have the same problem.

i do believe that i have my display size set correctly.

only 4:3 and 4:3 zoom seem to get it correct. in all the rest the text appears to be "squashed" with characters overlapping each other. this is on two different frontends, both running an up to date svn on gentoo. one has an nvidia chipset and the other ATI.

[danielk]

Simon, can you narrow the regression down to a changeset? Two years of changes is a very long list of changes for me to go through to find a problem I can't reproduce...

Also, do you have non-square pixels, I've only tested with 16:10 and 4:3 displays with square pixels. If you have a 16:9 screen with a 4:3 resolution, let me know and I can test that setup.

[danielk]

Note: I found the message where Torbjörn Jansson posted about this problem last November. And I did test with non-square pixels then. So that isn't it.

Please get me the "-v playback" log using no Aspect Ratio overrides. And a picture of the screen with the OSD menu up, also without any Aspect Ratio overrides, so I can try measure the fonts to figure out exactly how much they are out of spec. Reopen the ticket when you have these.

[Simon Kenyon <simon@…>]

Replying to danielk:

Note: I found the message where Torbjörn Jansson posted about this problem last November. And I did test with non-square pixels then. So that isn't it.

Please get me the "-v playback" log using no Aspect Ratio overrides. And a picture of the screen with the OSD menu up, also without any Aspect Ratio overrides, so I can try measure the fonts to figure out exactly how much they are out of spec. Reopen the ticket when you have these.

i'm attaching two screenshots. one is 16:9 and the second is 4:3. as you can see the 16:9 one is quite distorted. the logs will follow shortly.

[Simon Kenyon <simon@…>]

screen grab of frontend in 16:9 mode

[Simon Kenyon <simon@…>]

i had to cut down the sizes so they would fit. also note that the file names were munged.

[Simon Kenyon <simon@…>]

log file with -v playback

[danielk]

Closing as fixed, user error caused this to be reopened.

Simon, look run "man xorg.conf" and look for "DisplaySize?", if option doesn't work you are probably using nvidia drivers and need to look at their documentation. Your monitor, or you via xorg.conf options, are telling X11 to advertise a screen aspect ratio of 25:16 on a 16:10 screen.