[mythtv-users] MacOSX frontend & 1080i

[Andrew Kimpton]

Todd Ignasiak wrote:
> On 3/13/07, Andrew Kimpton <awk at awkward.org> wrote:
>   
>> Quoting Todd Ignasiak <ignasiak at gmail.com>:
>>
>>     
>>> On 3/13/07, Andrew Gallatin <gallatin at cs.duke.edu> wrote:
>>>       
>>> Also, I doubt the LCD is being run at 150Hz, where does Myth show
>>> that?   I think LCDs are set to 60Hz by default, although it's hard to
>>> tell for sure.   I installed SwitchResX control panel & output the DDC
>>> data for the display, and it showed it was running 1440x900 @ 60Hz.
>>>       
>> It's a very long time since I looked at it - but there is code in
>> Myth's videoout 'portions' which attempts to get the refresh rate for
>> the display but when that fails (there is no refresh rate for a
>> digitally connected LCD Panel) defaults to 60Hz. If I recall there is
>> a second place where this reported value is then multiplied by a
>> constant (I thought 4 - but that doesn't make sense given the reported
>> value of 150Hz).
>>
>> Some of this may be different if you're using the CoreVideo output
>> mechanism which I wrote some months ago but I don't think was ever
>> committed - is it possible that Andrew G & Todd are not running the
>> same videout device (CoreVideo vs. 'standard'). The reported refresh
>> rates may be different between these two approaches (see para. 1 above).
>>     
>
> Hi Andrew,
>
>
> Also -- I am using the AC3 passthrough, based on your patch, and that
> works great.  DD5.1 audio from broadcast HD, and DVDs via the internal
> player.
>
>   
Todd - when you performed your comparitive analysis with Andrew G's 
results were you using the AC3 pass through or a stereo analog connection ?

The two different audio output mechanisms have different clocking 
methods for the audio and it may well be that there's a bug in the 
analog implementation and that's what's causing Andrew G's issues.

Basically the video frame presentation rate is driven from the current 
audio play position - if audio advances 'too fast' in relation to video 
then video has to drop a frame or more to 'catch up'. Equally if audio 
is 'behind' then video has to display the same frame twice in order to 
let audio catch up.

There is an alternative approach to keeping things in sync involving 
sample rate converting the audio on playback to an effective sample rate 
that is not 44.1 (or 48 etc.) but more closely matches the relationship 
between video frame display rate and audio hardware clock rate (ie 
something a little less or a little more - and it can change over time). 
There's some evidence in the Myth code that this has at least been 
considered - but it can't be applied to any encoded audio format (like 
AC3 or DTS) since there's no access to the raw underlying samples - if 
you're going to support those types of audio encoding you have to 'slew' 
the video to match the audio.

Andrew 8-)