Opened 15 years ago

Closed 15 years ago

#2267 closed patch (fixed)

Correct Display Frame Rate Detection in Mac OS X

Reported by: awk@… Owned by: Nigel
Priority: minor Milestone: unknown
Component: mythtv Version:
Severity: medium Keywords:
Cc: Ticket locked: no


Specifically - the returned rate should probably default to 60 not 150 if there is no detected rate. No detected rate typically means an LCD panel display so 60Hz seems more appropriate.

The attached patch also includes a few code cleanups and the fixing of a few warnings in the original code.

Attachments (1)

videoout_quartz.cpp.diff (2.0 KB) - added by awk@… 15 years ago.
patch to videoout_quartz.cpp

Download all attachments as: .zip

Change History (6)

Changed 15 years ago by awk@…

Attachment: videoout_quartz.cpp.diff added

patch to videoout_quartz.cpp

comment:1 Changed 15 years ago by Nigel

Owner: changed from Isaac Richards to Nigel
Status: newassigned

I put the rate at 150Hz because it is divisible by 25 and 30 (or 50 and 60), so it would minimise busy waits the player would be doing to get the video and audio in sync. Happy to make it 60Hz if that is what laptop LCDs really use, but I thought that varied by manufacturer, chipset, et c.
Most of the other changes are already in there (I assume the patch was against 0.19-fixes?), but I am curious about the 1000000/data->refreshRate. Looking at videoout_*.cpp, they do indeed seem to return 1e6/rate, so I will apply that, and the code to zero theCodec.
Guys, when did "Rate" start meaning "Vertical Refresh Cycle in microseconds"?

comment:2 Changed 15 years ago by awk@…

Hmmm... I've seen 60 in other places particular when dealing with a panel which is connected via VGA rather than DVI. I had thought that you'd picked 150 because there's a divide by 4 in some of the code that calls this (which would give you 60) and so you though that code needed the higher rate so that the divide gave you 'the number you first thought of'.

In fact thinking back on what was going on - the 1000000/data->refreshRate is actually probably the more important part of the patch (though I didn't comment on it).

What I've been trying to fix (successfully I think) was some bad sync and timing behaviour in my OS X Plextor support. The CoreAudio? changes in bug #2265 are more significant for that though.

comment:3 Changed 15 years ago by Nigel

(In [10978]) Correct Mac code so GetRefreshRate?() returns a refresh cycle period, and not the frequency I thought it was meant to when I wrote it. See #2267 Also added a comment about this misnomer in the base class's header.

comment:4 Changed 15 years ago by Nigel

(In [10979]) 1) Comment on my choice of 150Hz for displays we can't get the refresh rate of. 2) Clear theCodec differently. Assigning it to NULL, isn't right

because it isn't a pointer, but doing a memset(...,0,...) on it is a waste, because an ImageSequence? is only a long.

See #2267

comment:5 Changed 15 years ago by Nigel

Resolution: fixed
Status: assignedclosed

Any external monitor (VGA/DVI) seems to get a real refresh rate - it is only internal monitors (e.g. on laptops or iMacs) that seem to miss having this CG property. I haven't done any animation tests yet to see what the rate really is, but if anyone gets some hard facts, this can be re-opened.

Note: See TracTickets for help on using tickets.