Opened 14 years ago

Closed 7 years ago

Last modified 6 years ago

#7408 closed Bug Report - General (fixed)

Recording playback scaling incorrect with xv

Reported by: Robin Hill <myth@…> Owned by: Peter Bennett
Priority: minor Milestone: unknown
Component: MythTV - Video Playback Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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

Attachments (4)

frontend.log (22.8 KB) - added by Robin Hill <myth@…> 14 years ago.
mythfrrontend log with "-v playback"
xv_scaling_trunk.log (33.2 KB) - added by Jonatan <mythtv@…> 13 years ago.
xv_scaling_w_patch.log (37.6 KB) - added by Jonatan <mythtv@…> 13 years ago.
xv_scaling.patch (956 bytes) - added by Jonatan <mythtv@…> 13 years ago.

Download all attachments as: .zip

Change History (27)

Changed 14 years ago by Robin Hill <myth@…>

Attachment: frontend.log added

mythfrrontend log with "-v playback"

comment:1 Changed 14 years ago by 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.

comment:2 Changed 14 years ago by stuartm

Status: newinfoneeded_new

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.

comment:3 Changed 14 years ago by stuartm

Resolution: invalid
Status: infoneeded_newclosed

7 weeks without requested information. Closing.

comment:4 Changed 14 years ago by Jonatan <mythtv@…>

Resolution: invalid
Status: closednew

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.

comment:5 Changed 14 years ago by stuartm

Milestone: unknown0.24
Owner: changed from Janne Grunau to markk
Status: newassigned

comment:6 Changed 14 years ago by markk

Status: assignedaccepted

comment:7 Changed 13 years ago by markk

Status: acceptedinfoneeded

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)

comment:8 Changed 13 years ago by 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

Changed 13 years ago by Jonatan <mythtv@…>

Attachment: xv_scaling_trunk.log added

Changed 13 years ago by Jonatan <mythtv@…>

Attachment: xv_scaling_w_patch.log added

Changed 13 years ago by Jonatan <mythtv@…>

Attachment: xv_scaling.patch added

comment:9 Changed 13 years ago by 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

comment:10 Changed 13 years ago by markk

Version: 0.22rc1Trunk Head

comment:11 Changed 13 years ago by markk

Resolution: Fixed
Status: infoneededclosed

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

comment:12 Changed 12 years ago by 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

comment:13 Changed 12 years ago by danielk

Owner: changed from markk to danielk

comment:14 Changed 12 years ago by danielk

Resolution: Fixed
Status: closednew

comment:15 Changed 12 years ago by danielk

Milestone: 0.24unknown

comment:16 Changed 12 years ago by stuartm

Type: defectBug Report - General

comment:17 Changed 7 years ago by Steven Ellis <support@…>

Looks like this might be similar to my problem

comment:18 Changed 7 years ago by Peter Bennett

Owner: changed from danielk to Peter Bennett
Status: newassigned

comment:19 Changed 7 years ago by Peter Bennett

Status: assignedaccepted

comment:20 Changed 7 years ago by Peter Bennett <pbennett@…>

Resolution: fixed
Status: acceptedclosed

In 7388b5a60c54d5e812a535bf5212295e512c5c3f/mythtv:

Fix bugs that occur when using a different video mode for playback.

Fixes these cases where the code does not cater for the video mode
changing between GUI and playback.

  • Playback using xv-blit and maybe others is shown in the wrong size and position.
  • Playback using OpenGL is displaced downward.
  • LiveTV using OpenGL is the wrong size.
  • Program Guide and other screens selected from within LiveTV when using OpenGL

are cut off on the right.

Fixes #7408
Fixes #11363
Fixes #13054

comment:21 Changed 7 years ago by Peter Bennett <pbennett@…>

In eef6a480b0eca5201eec785b0ce57f9a6f4b7fdd/mythtv:

Fix bugs that occur when using a different video mode for playback.

Fixes these cases where the code does not cater for the video mode
changing between GUI and playback.

  • Playback using xv-blit and maybe others is shown in the wrong size and position.
  • Playback using OpenGL is displaced downward.
  • LiveTV using OpenGL is the wrong size.
  • Program Guide and other screens selected from within LiveTV when using OpenGL

are cut off on the right.

Fixes #7408
Fixes #11363
Fixes #13054

(cherry picked from commit 7388b5a60c54d5e812a535bf5212295e512c5c3f)

comment:22 Changed 7 years ago by Steven Ellis <support@…>

Confirmed working with 0.28 fixes and xv-blit

Still have issues with VAAPI (#13054) and OpenGL (#11363)

comment:23 Changed 6 years ago by Peter Bennett

Owner: changed from Peter Bennett to Peter Bennett
Note: See TracTickets for help on using tickets.