Avoid OSD resize from 4:3 when viewing 16:9 TV

[anonymous]

This patch fixes a small glitch in the OSD when starting to watch a 16:9 broadcast.

Currently, when you start watching 16:9 live TV the following happens ... the screen goes black and the OSD appears showing the tuner in use and the current program details. The OSD seems is sized for a 4:3 aspect ratio (not taking up the full screen width), then once the tuner locks on and the picture appears, the OSD resizes to the full width of the screen. It just looks a bit ugly and unpolished.

This happens because the video player has a hard-coded assumption about the video it will start playing, and assume 4:3. It uses this to setup a dummy video stream while waiting for the channel to tune.

This patch sets up the dummy video stream to match the display aspect ratio.

It's a bit of a hack, but it results in a much improved/polished behavior in most cases.

[devel@…]

This makes the transition smoother. However, when watching 16:9 content on a 4:3 display the osd resizes from 4:3 to 16:9. It would probably be better if the osd continued to fill the whole screen. I'll see if I can whip up a modified patch sometime next week.

[matt.doran@…]

I'm not sure how you can do much better without changing the OSD in a more fundamental way. At the time the dummy video stream is setup, you don't know the aspect ratio of the content.

I guess one approach is to give each channel an aspect ratio override. I think the default should be the aspect ratio of the screen like the above patch implements.

[danielk]

(In [13540]) Fixes #3505. Avoids some OSD resizes on first channel tune with digital tuners.

This is based on a patch by Matt Doran, the only difference is that this snaps the aspect to 4:3 or 16:9 as appropriate to deal with 16:10 and other sligtly off displays and the code was placed in the dummy video initialization so it is only run when it will be useful.

This only works properly when the channel being tuned matches the display aspect ratio and the display has square pixels. But the fallback is to do the same thing we do currently so there is no loss for the many people this doesn't do anything for.

[danielk]

(In [13553]) Refs #3505. Reverts [13540], it was causing problems for Timo-Pekka Viljamaa.

[danielk]

No one has posted an updated patch that resolves Timo-Pekka's problem in with this enhancement patch in two months...