Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 5 years ago

Last modified 2 years ago

#7408 new Bug Report - General

Recording playback scaling incorrect with xv

Reported by: Robin Hill <myth@…> Owned by: danielk
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@…> 5 years ago.
mythfrrontend log with "-v playback"
xv_scaling_trunk.log (33.2 KB) - added by Jonatan <mythtv@…> 4 years ago.
xv_scaling_w_patch.log (37.6 KB) - added by Jonatan <mythtv@…> 4 years ago.
xv_scaling.patch (956 bytes) - added by Jonatan <mythtv@…> 4 years ago.

Download all attachments as: .zip

Change History (20)

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

mythfrrontend log with "-v playback"

comment:1 Changed 4 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 4 years ago by stuartm

  • Status changed from new to infoneeded_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 4 years ago by stuartm

  • Resolution set to invalid
  • Status changed from infoneeded_new to closed

7 weeks without requested information. Closing.

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

  • Resolution invalid deleted
  • Status changed from closed to new

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 4 years ago by stuartm

  • Milestone changed from unknown to 0.24
  • Owner changed from janne to markk
  • Status changed from new to assigned

comment:6 Changed 4 years ago by markk

  • Status changed from assigned to accepted

comment:7 Changed 4 years ago by markk

  • Status changed from accepted to infoneeded

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 4 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 4 years ago by Jonatan <mythtv@…>

Changed 4 years ago by Jonatan <mythtv@…>

Changed 4 years ago by Jonatan <mythtv@…>

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

  • Version changed from 0.22rc1 to Trunk Head

comment:11 Changed 4 years ago by markk

  • Resolution set to Fixed
  • Status changed from infoneeded to closed

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

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

  • Owner changed from markk to danielk

comment:14 Changed 2 years ago by danielk

  • Resolution Fixed deleted
  • Status changed from closed to new

comment:15 Changed 2 years ago by danielk

  • Milestone changed from 0.24 to unknown

comment:16 Changed 2 years ago by stuartm

  • Type changed from defect to Bug Report - General

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.