Opened 14 years ago

Closed 12 years ago

#3523 closed defect (fixed)

Aspect change does not work under MacOSX

Reported by: anonymous Owned by: danielk
Priority: minor Milestone: 0.22
Component: mythtv Version: head
Severity: low Keywords: aspect mac osx
Cc: Ticket locked: no


I am running MythFrontend_OSX_Intel_0.20-fixes_20070526.dmg on my Mac Mini and apple tv. The bug is present on both systems.

When hitting the 'W' key ( for changing the aspect ratio ) The overlay's aspect (the menu and text ) changes while the video still remains 4:3 ( when having 4:3 input ). I took a log thats attached to this ticket. There you can see that the following remains the same all the time:

2007-05-29 19:33:47.576 Viewport is 1280 x 720 2007-05-29 19:33:47.576 Image is 720 x 576 2007-05-29 19:33:47.576 Scaling to 1.06666 of width 2007-05-29 19:33:47.576 Scaling to 1.25 x 1.25 of original 2007-05-29 19:33:47.576 Centering with 160, 0

( This section is present multiple times in the log, corresponding to me pressing 'W' ).

I believe this to be wrong, but since I have no knowledge about the myth internals whatsoever, it would be nice if one of you pro's could look into it.

If you need other types of logs or a realtime debug session with me, don't hesitate to contact me.

Thanks in advance, Marcus

Attachments (1)

mythaspect.log (39.5 KB) - added by maddi@… 14 years ago.
Log of a mythtv session

Download all attachments as: .zip

Change History (15)

Changed 14 years ago by maddi@…

Attachment: mythaspect.log added

Log of a mythtv session

comment:1 in reply to:  description Changed 14 years ago by anonymous

Oh, i forgot to say that this happens in live tv and 'recorded programs' watching

comment:2 Changed 14 years ago by danielk

Owner: changed from Isaac Richards to Nigel

comment:3 Changed 14 years ago by danielk

(In [14070]) Refs #2287. Refs #3523. Various minor fixes to VideoOutputQuartz?.

  • Changes QuartzData? from a struct to a class, so we can properly initialize all it's variables without an init function.
  • Sets data pointer to NULL after deleting the class for easier debugging.
  • Calls SetVideoRender?() in the ctor and CreateQuartzBuffers?(), the latter is needed in case there is no quartz video profile, otherwise the VideoOutputBase::Init() call may reset the renderer.
  • Sets display_dim and display_aspect properly. This is a prerequisite to addressing #3523,
  • Removes incorrect code in VideoOutputQuartz::GetAllowedRenderers?() for enabling DVDV rendering.
  • Tidys up some VERBOSE macros.

comment:4 Changed 14 years ago by danielk

Owner: changed from Nigel to danielk
Severity: mediumlow
Version: 0.20-fixeshead

I've confirmed this bug as well as other bugs in handling the aspect ratio; such as no support for screens with non-square pixels. However fixing these problems in a maintainable way will require changes in the VideoOutput? base class because of the views implemented in the OSX VideoOutput? with multiple view bounds don't map well to the single set of bounds supported by the VideoOutput? class.

comment:5 Changed 14 years ago by bo.h.cph@…

With tv channels that send some shows in 4:3 and others in anamorphic 16:9, being able to change between the two during playback is a sort of a "must have" feature - at least if you hate looking at too wide or too narrow faces :-)

I thought about experimenting with a workaround, simulating what is happening when you change between 4:3 and 16:9 in the recording settings. Any ideas are welcome.

comment:6 Changed 13 years ago by evilbarney@…

I'm also experiencing this same bug on my mac mini running 20.2. Any stauts update on this? I agree this is a "must have" fix- my wife does not want to watch any of the 4:3 recordings on our 16:9 that won't fill the screen. The tv fill feature is useless, and the aspect changes in myth just resize the playback, all still inside the 4:3 window.

Anywork around would be appreciated.


comment:7 Changed 13 years ago by Stuart Auchterlonie

Milestone: unknown0.22

Nor do the fill/zoom modes. However this isn't going to get done in time for 0.21.

comment:8 Changed 13 years ago by JR.myth@…

Same here, on a Mac mini and an iMac, both using HD resolutions. I appreciate that the severity is low in the global picture, but for us who are using Macs as their only frontend(s), the severity is much higher (at least for me, it means I can't watch most recordings at the moment).

When I was using 0.21 SVN, I was able to compensate by using manual zoom. That got annoying over time, so I decided to switch to 0.22 SVN, hoping it would be better there, but the manual zoom behaviour changed there - zooming will scale the picture way too big.

Finding myself in the unusual situation of having time to spend on this, I'd like to help. Is there something I could do (testing, programming, ...)?


comment:9 Changed 13 years ago by danielk

(In [18069]) Refs #3523. Splits window framing information out of VideoOutput? class into a seperate class using patch from Jens Rehaag as a starting point.

The purpose of this change is to make fixing the Aspect ratio adjustment under OSX possible, since it's video output class employs multiple video output windows which each require their own framing adjustments.

comment:10 Changed 13 years ago by danielk

Resolution: invalid
Status: newclosed

Closing as feature request without patch, no one appears to have been working on this for at least two months.

comment:11 Changed 13 years ago by Nigel

(In [18887]) Use a QRect to store output dimensions, copy into it when clients calls base classes' MoveResize?(). Roughly fixes Aspect/Zoom/Fill? problems for main window- see #3523 - but there are now problems in other output views. Will experiment with them after I have merged this on top of VID-fixes branch (esp. [18069]).

comment:12 Changed 13 years ago by Nigel

(In [18960]) Merges r18886:18959 from trunk. Only lightly tested, but does fix a crash with the floating window, and the aspect/fill/zoom issue. See #3523

comment:13 Changed 12 years ago by Nigel

Resolution: invalid
Status: closednew

comment:14 Changed 12 years ago by Nigel

Resolution: fixed
Status: newclosed

I haven't heard any complaints about my fixes, so will assume they fixed it for everyone

Note: See TracTickets for help on using tickets.