Recording playback scaling incorrect with xv

[Robin Hill <myth@…>]

I run the GUI at 960x540 (which is the highest resolution I've found a working modeline for my TV for), then switch to 720x576 for watching recordings (PAL TV, so there's no scaling). This worked fine with 0.21 but I now only get part of the picture - it's been scaled up (probably to 960 pixels), then the right-hand side is cut off.

I found an old post reporting the same (or a similar) issue (​http://www.mailinglistarchive.com/mythtv-users@mythtv.org/msg99689.html) but that didn't seem to reach any resolution (he switched to VDPAU which didn't have the same issue). He also didn't see the issue with LiveTV, whereas I get the same problem with both LiveTV and recordings.

I've tried digging into the details but I can't make sense of it - a lot of the code seems to be working with the Display dimensions vs Video dimensions for scaling, but the Display dimensions are never altered from their initial settings. Should these not change when xrandr alters the display? I've tried resetting them there but it doesn't seem to help - it's still picking up the wrong dimension at later points.

MythTV Version : 22563
MythTV Branch : branches/release-0-22-fixes
Network Protocol : 50
Library API : 0.22.20091008-1
QT Version : 4.5.2
Options compiled in:

linux release using_oss using_alsa using_backend using_dvb using_frontend using_iptv using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_live using_mheg

[Robin Hill <myth@…>]

mythfrrontend log with "-v playback"

[Robin Hill <myth@…>]

A workaround has been pointed out to me - commenting out the entire contents of the VideoOutputXv::WindowResized? method results in correct resizing.

[stuartm]

We need to know if this problem is resolved in 0.23 or trunk. I suspect that it should be fine in trunk since the video rendering has undergone a lot of changes.

[stuartm]

7 weeks without requested information. Closing.

[Jonatan <mythtv@…>]

The setGeometry() calls in tv_play.cpp generates a resize events that arrive after VideoOutput::ResizeForVideo?() has been called, overriding the display dimension/aspect ratio that ResizeForVideo?() has set.

Correct or not, but a call to ResizeForVideo?() in VideoOutputXv::WindowResized?() just before MoveResize?() seems to do the trick.

[markk]

Can someone please confirm whether they are seeing this with an up to date trunk install. Testing with r26455 doesn't display the issue with XVideo. (but I do see something similar with OpenGL playback)

[Jonatan <mythtv@…>]

I am still seeing this with r26598. See log excerpts with -v playback below and attached logs. I added a log like "QEvent::Resize(<width>, <height>)" of any resize events received in tv_play.cpp.

I am using Qt 4.6.2 if it has any relevance.

As you mention, OpenGL playback also has a similar problem but with a different display rect it seems.

The display resolution has changed to 720x576 prior to the point where the excerpts were taken.

Trunk behavior:

2010-10-02 14:20:14.373 TV: StartPlayer(0, WatchingPreRecorded, main) -- end ok
2010-10-02 14:20:14.374 SendReceiveStringList(MESSAGE,COMMFLAG_REQUEST 5135_2010-10-02T04:57:00) called from UI thread              
2010-10-02 14:20:14.380 TV: Changing from None to WatchingPreRecorded
2010-10-02 14:20:14.391 QEvent::Resize(1920, 1080)
2010-10-02 14:20:14.391 Display Rect  left: 242, top: 0, width: 1436, height: 1080, aspect: 2.37731
2010-10-02 14:20:14.391 Video Rect    left: 0, top: 0, width: 720, height: 576, aspect: 1.77778

Behavior with fix mentioned in comment comment:4, and attached patch:

2010-10-02 14:15:47.451 TV: StartPlayer(0, WatchingPreRecorded, main) -- end ok
2010-10-02 14:15:47.451 SendReceiveStringList(MESSAGE,COMMFLAG_REQUEST 5135_2010-10-02T04:57:00) called from UI thread
2010-10-02 14:15:47.455 TV: Changing from None to WatchingPreRecorded
2010-10-02 14:15:47.470 QEvent::Resize(1920, 1080)
2010-10-02 14:15:47.470 Trying to match best refresh rate 25.000Hz
2010-10-02 14:15:47.470 Trying 720x576 50.000 Hz
2010-10-02 14:15:47.471 Dynamic TwinView rate found, set 50Hz as XRandR 99
2010-10-02 14:15:47.471 SwitchToVideo: Video size 720 x 576:
   Switched to displaying resolution 720 x 576, 481mm x 270mm
2010-10-02 14:15:47.506 Snapping height to avoid scaling: height: 576, top: 0
2010-10-02 14:15:47.506 Snapping width to avoid scaling: width: 720, left: 0
2010-10-02 14:15:47.506 Display Rect  left: 0, top: 0, width: 720, height: 576, aspect: 1.77778
2010-10-02 14:15:47.506 Video Rect    left: 0, top: 0, width: 720, height: 576, aspect: 1.77778
2010-10-02 14:15:47.506 Snapping height to avoid scaling: height: 576, top: 0
2010-10-02 14:15:47.506 Snapping width to avoid scaling: width: 720, left: 0
2010-10-02 14:15:47.506 Display Rect  left: 0, top: 0, width: 720, height: 576, aspect: 1.77778
2010-10-02 14:15:47.506 Video Rect    left: 0, top: 0, width: 720, height: 576, aspect: 1.77778

[anonymous]

Jonatan

Can you confirm whether simply deleting the code in VideoOutputXv::WindowResized? fixes the problem. At this stage I would much rather simply remove that functionality - it has only been implemented in VideoOutputXv? and I don't wont to introduce regressions at this stage in the release cycle.

thanks

[markk]

(In [26686]) Disable the window resizing in VideoOutputXv?. Closes #7408

[Github]

Fixes #9233. Refs #7408. Re-enables WindowResized?().

We traded a one small bug for two others just prior to 0.24.

Branch: master Changeset: 47d7c773e98ef2945667ddf9119d4be446e07bf8