Video aspect ratio wrong with mythfrontend in window

[Klaas de Waal]

With today's master, the video aspect ratio is wrong when playing a recording, or live TV, with mythfrontend in a window. The window has 16:9 aspect ratio but the width of the video is less. Screenshot is attached.

This is on my two-monitor development system but it the problem is also present when the second monitor is disconnected and the system is rebooted. Intel graphics only.

The settings in Setup\Appearance\Theme/Screen? Settings\Virtual monitor aspect ratio, available when using two monitors, do not have any influence.

This problem must have been introduced in the last two weeks or so.

The aspect ratio with full screen playback on a TV is correct; this system runs also today's master but has different hardware (nvidia).

[Klaas de Waal]

Wrong aspect ratio of video in window

[jpilk]

I had aspect ratio problems too, but c535f96 and b2a0e82 work for me; I'm using my longstanding --geometry overrides, though, which may be thought undesirable.

[Klaas de Waal]

Log of the ./configure of the configuration that produces the video aspect ratio issue.

[Klaas de Waal]

Log of mythfrontend playing video fragment first with VAAPI and then with OpenGL High Quality, both showing the video aspect ratio issue.

[Mark Kendall]

Klaas

Can you confirm a few things:-

• per the email discussion, are you running wayland?
• what is the actual aspect ratio of your monitor? 16:9 or 16:10?

Can you also attach

• the full log using '-v playback' logging.
• the full output from 'xrandr --verbose'
• the EDID itself.

For the EDID, I think it should be as easy as:-

cat /sys/class/drm/card0-HDMI-A-2/edid > monitor.edid

Though you may need to check that HDMI-A-2 is the correct device.

[Mark Kendall]

Can you also confirm what is shown in the "Virtual monitor aspect ratio" field of the appearance settings page. Thanks

[Klaas de Waal]

About Wayland or X11, my understanding is that I run X11, as indicated by the following:

[klaas@modu mythtv]$ loginctl
SESSION  UID USER  SEAT  TTY 
      6 1000 klaas seat0 tty1

1 sessions listed.
[klaas@modu mythtv]$ loginctl show-session 6 -p Type
Type=x11
[klaas@modu mythtv]$

[klaas@modu mythtv]$ echo $XDG_SESSION_TYPE
x11
[klaas@modu mythtv]$

About monitor aspect ratio. Main monitor is 16:10, second monitor is 16:9. Arranged side-by-side. When only the main monitor (16:10) is connected the problem is the same.

About the "Virtual monitor aspect ratio". The setting is "Auto" but I have also tried "32:10 Side by side" and a few others. This did not make any difference.

Logs are attached.

[Klaas de Waal]

Log of mythfrontend with -v playback. Playing a SD recording in 1280x720 window on 1920x1200 screen.

[Klaas de Waal]

Output of xrandr --verbose

[Klaas de Waal]

EDID of main monitor, Samsung 1920x1200

[Klaas de Waal]

EDID of second monitor, HP 1920x1080

[Klaas de Waal]

Log of mythfrontend with -v playback. Playing a SD recording in 1280x720 window on 1920x1080 screen. Aspect ratio is correct.

[Klaas de Waal]

Rebooted the system with only the HP 16:9 1920x1080 monitor connected. The video aspect ratio is now correct! Log of mythfrontend -v playback is attached. It looks like the problem is the 16:10 form factor of the Samsung monitor.

[jpilk]

Running 1c97471de5f on my F30 box-with-nVidia I found it difficult to get settings that properly nested the video into the GUI on both the monitor and the TV.

Previously my default 'mythfrontend' setup has been a windowed display 1024x576+64+64 and I have used

'mythfrontend -nw -geometry 1920x1080+1680+0' to put it on the TV

Adding ' -display=HPFed:0.0' to both these command lines does what I want.

The name is as shown in the nVidia X Screen information, which also gives dimensions of 3600x1080, ratio 10:3. Specifying ratios doesn't seem to make an easily understood difference to what I see.

My usual problem with -help screens is knowing what format the writer thought was obvious.

[Klaas de Waal]

The problem seems to be that the 16:10 monitor is considered to have a size of 160mmx90mm which then leads to an incorrect Display Rect result:

2020-01-07 21:35:15.658760 I  VideoWin: New display properties: 160mmx90mm Aspect 1.3333
...
2020-01-07 21:35:15.658824 I  VideoWin: Display Rect: 1159x720+60+0 Aspect: 1.96296

For the 1920x1080 16:9 monitor the dimensions are correct and the Display Rect is also correct:

2020-01-07 21:54:01.621708 I  VideoWin: New display properties: 480mmx270mm Aspect 1.3333
...
2020-01-07 21:54:01.621731 I  VideoWin: Display Rect: 1280x720+0+0 Aspect: 1.77778

The problem would be solved if the screen dimensions are reported correct. This does depend on correct values in the EDID and especially for older TV's these values might be wrong.

However, as far as I know, all screens with a resolution of full-HD (1920x1080) or higher do have square pixels. Also, it is unlikely to have a screen of 160mmx90mm so if this is reported it should not be taken too serious.

Note that also my 55-inch full-HD TV (Samsung, 2011) is reported to have a size of 160mmx90mm.

It looks to me that the way forward can be:

• Obtain the correct display dimensions
• Discard 160mmx90mm results as they indicate that the real values are not available
• For resolutions of full-HD or higher always use square pixels
• Add a warning message when the reported dimensions are corrected for square pixels

[Mark Kendall]

It looks to me that the way forward can be:

Obtain the correct display dimensions

If the EDID is wrong, there is no other way of automatically detecting the actual screen size. That is what the EDID is for.

Discard 160mmx90mm results as they indicate that the real values are not available

As mentioned previously, 160x90 is a common and useful result - it tells us all we need to know (i.e. the aspect ratio). We don't actually care about the size.

For resolutions of full-HD or higher always use square pixels

I'd personally guarantee that this won't be accurate in a number of scenarios.

The real issue here is whether this was working as expected before?

All it really needs is for the aspect ratio override setting to be respected - I think in refactoring I assumed it was only needed/used for 'Xinerama' (i.e. multi-screen) setups.

The other potential solution is to override the EDID for that display. I'll attach a modified EDID that indicates 160x100 which can then be used with something like:-

​https://unix.stackexchange.com/questions/295784/how-to-tell-intel-graphics-to-use-my-custom-edid-file

[Mark Kendall]

Samsung EDID modified to report a display size of 160x100mm

[Klaas de Waal]

Thanks for the EDID. Using a custom EDID will solve it for me and there are probably not that many 16:10 screens with an incorrect EDID.

About your question:

The real issue here is whether this was working as expected before?

Yes, it has always worked as expected except for a short period as described in ticket #13400.

For me the current behavior is a regression as it is not correct anymore for a display with square pixels and wrong dimensions in the EDID. I do however agree it is an improvement for screens with non-square pixels and a correct EDID.

[Mark Kendall]

Having thought it through - I'm pretty sure the old code got it 'correct' by accident in your case. I noticed recently that the calls in MythXDisplay::GetDisplayDimensions? do not return the correct values when multiple dislays are connected - which is why they are not used anymore (we now use XRANDR - which will only be using the EDID anyway).

Anyway, I've started re-visiting the display aspect ratio settings - which should clear things up a little. Just trying to work out the cleanest approach.

So in your case, you should just be able to override the aspect ratio to 16:10 (rather than auto) (or override the EDID).

[jpilk]

I just updated the old laptop, ubuntu bionic, to current master 627c03d. No extra screens, default display in a window was slightly narrower than the frame.

'mythbackend.real -v playback -display=LDVS1' appears to give a good fit.

[Klaas de Waal]

A setting like the "Virtual monitor aspect ratio" (which could then become the "Monitor aspect ratio") would be perfect. In my case I have two monitors with different aspect ratio's (although both with square pixels...) so I think it should be possible to override each monitor individually.

[Mark Kendall]

Replying to jpilk:

I just updated the old laptop, ubuntu bionic, to current master 627c03d. No extra screens, default display in a window was slightly narrower than the frame.

'mythbackend.real -v playback -display=LDVS1' appears to give a good fit.

John - if you have a problem, please open another ticket and clearly explain what behaviour you are seeing, steps to reproduce and the behaviour you expect to see - along with relevant logs etc. These comments are not helpful.

[Mark Kendall]

Klaas - can you test with latest master.

This should be working properly now - by which I mean you should override the display aspect ratio in Setup->Appearance->Theme/Screen? Settings->Screen aspect ratio

You can of course still override the EDID.

see a4aad255a7d

[Klaas de Waal]

Problem solved!! The display is correct, the video does now once again exactly fills the window. Note that this is with the "Screen aspect ratio" to "Auto" and without a user-defined EDID.

FIY, the output of "mythfrontend -v playback" is attached.

Thanks!

[Klaas de Waal]

Output of mythfrontend -v playback with today's master, the video aspect ratio now correct.

[Mark Kendall <mark.kendall@…>]

In aeb97c5d2e/mythtv:

MythVideoOutput?: Fix a regression with windowed aspect ratio

Refs #13548
Refs #13560

[Klaas de Waal]

With today's master, I do need to set the "Screen aspect ratio" to 16:10 in order to get a video that exactly fills the window. This is OK for me.

It would however IMHO be an improvement if the default setting would be correct for a display with square pixels. I have never seen a display with non-square pixels since the days of the standard-definition 16:9 plasma TV's.

According to the Wikipedia page ​https://en.wikipedia.org/wiki/Pixel_aspect_ratio

In modern digital imaging systems and high-definition televisions, especially those that comply with SMPTE standards and practices, only square pixels are used for broadcast and display.

[jpilk]

FWIW I have just tried this again with 11b8d0ae and 0d3bb8787d, commits from yesterday and today. Both gave correct geometry and placement in the window and on the TV with either 'auto' or '16:10', for both SD and HD testcards, as in #13560. Other aspect-ratio settings that I tried didn't correctly fill the window.

Both screens have square pixels, and the monitor (Dell 2009W VGA-0, Primary display) is 1680 x 1050, ie 16:10

[Mark Kendall]

Replying to Klaas de Waal:

With today's master, I do need to set the "Screen aspect ratio" to 16:10 in order to get a video that exactly fills the window. This is OK for me.

Sorry Klaas - doing a little catchup on tickets/emails:)

I didn't expect it expect it to work without overriding the aspect ratio when you previously said it was fixed. The fix should have forced you to override - but your comments and feedback from John pointed me to an oversight that was subsequently corrected in ​https://code.mythtv.org/trac/changeset/aeb97c5d2ebf3e097c65c783a6311338bf9c5f83/mythtv

If that makes sense.

It would however IMHO be an improvement if the default setting would be correct for a display with square pixels. I have never seen a display with non-square pixels since the days of the standard-definition 16:9 plasma TV's.

I'll give this a little thought. It's a fairly trivial fix if we went down that route - and it does make sense.

I am however wary of the type of display that reports separate display modes for 'desktop' vs 'video' usage. So for example my spare monitor is 1680x1050 native (16:10 aspect) but also has, for example, 1920x1080 display modes where the output is letterboxed (and overscanned).

I'll do a little testing to check.

[Mark Kendall]

Replying to jpilk:

FWIW I have just tried this again with 11b8d0ae and 0d3bb8787d, commits from yesterday and today. Both gave correct geometry and placement in the window and on the TV with either 'auto' or '16:10', for both SD and HD testcards, as in #13560. Other aspect-ratio settings that I tried didn't correctly fill the window.

John - to be clear - when you say 'didn't correctly fill the window' - presumably you weren't expecting them to?

[jpilk]

Right. It's good with auto or the setting appropriate to the monitor, which in this case has square pixels; not (as) good with other settings. Once upon a time that value seemed to make no difference.

Most logs that get pasted show problems. I'm not sure that this is yet finished, but if nothing gets broken in the meantime it might be a good idea to post one that has worked.

[Mark Kendall]

Replying to jpilk:

Right. It's good with auto or the setting appropriate to the monitor, which in this case has square pixels; not (as) good with other settings.

It's not as good with other settings because you are telling the code you have a different aspect ratio - it should look broken.

Once upon a time that value seemed to make no difference.

It was changed two weeks ago.

​https://github.com/MythTV/mythtv/commit/a4aad255a7d9259f6c35ac2e8aa955067170d0f8

[Stuart Auchterlonie]

Moving open tickets v31.0 -> v31.1

[Klaas de Waal]

Problem is fixed, ticket closed now.

[Mark Kendall <mark.kendall@…>]

In 33fa19e50/mythtv:

MythDisplay?: Assume 'square pixels' for default display aspect ratio
calculation

• the default (for new installations) now assumes display pixels are

square (i.e. have an aspect ratio of 1) - which means we can calculate
the display aspect ratio from the resolution (which was previously a
fallback).

• behaviour for existing installations will be unchanged
• square pixels are now the norm for the vast majority of displays and

using the screen resolution to calculate the aspect ratio avoids small
rounding errors from using the EDID and incorrect aspect ratios from
broken/misleading EDIDs.

• refs #13548