[mythtv-users] Getting lots of jitter with version 0.24

[Neil Salstrom]

On Wed, Nov 24, 2010 at 11:50 AM, Neil Salstrom <salstrom at gmail.com> wrote:

> Ok, I know pretty much nothing about any of this but I've spent a bit
> of time looking over the patch verses mythplayer.cpp.  The section of
> mythplayer.cpp that is addressed by Hunk #6 states:
>
>        // if we get here, we're actually going to do video output
>        osdLock.lock();
>        videoOutput->PrepareFrame(buffer, ps, osd);
>        osdLock.unlock();
>        VERBOSE(VB_PLAYBACK|VB_TIMESTAMP, QString("AVSync waitforframe %1 %2")
>                .arg(avsync_adjustment).arg(m_double_framerate));
>        videosync->WaitForFrame(frameDelay + avsync_adjustment + repeat_delay);
>        VERBOSE(VB_PLAYBACK|VB_TIMESTAMP, "AVSync show");
>        videoOutput->Show(ps);
>
> The patch states:
>
> @@ -1712,10 +1777,11 @@ void MythPlayer::AVSync(VideoFrame *buffer,
> bool limit_delay)
>         // if we get here, we're actually going to do video output
>         videoOutput->PrepareFrame(buffer, ps, osd);
>
> -        VERBOSE(VB_PLAYBACK|VB_TIMESTAMP, QString("AVSync waitforframe %1 %2")
> +        VERBOSE(VB_PLAYBACK|VB_TIMESTAMP, LOC + QString("AVSync
> waitforframe %1 %2")
>                 .arg(avsync_adjustment).arg(m_double_framerate));
> -        videosync->WaitForFrame(frameDelay + avsync_adjustment + repeat_delay);
> -        VERBOSE(VB_PLAYBACK|VB_TIMESTAMP, "AVSync show");
> +        vsync_delay_clock = videosync->WaitForFrame(frameDelay +
> avsync_adjustment + repeat_delay);
> +        currentaudiotime = AVSyncGetAudiotime();
> +        VERBOSE(VB_PLAYBACK|VB_TIMESTAMP, LOC + "AVSync show");
>         videoOutput->Show(ps);
>
> Does this mean I need to adjust the first few lines of the patch to read:
>
> @@ -1712,10 +1777,11 @@ void MythPlayer::AVSync(VideoFrame *buffer,
> bool limit_delay)
>         // if we get here, we're actually going to do video output
>         osdLock.lock();
>         videoOutput->PrepareFrame(buffer, ps, osd);
>
> The only thing that I can find is the fact the code has the addition
> of the osdLock.lock(); line when the patch does not.  Is that what
> causes it to fail?
>
> Thanks,
>
> Neil
>

Ok, that didn't work.  I've concluded that I have no idea what I'm doing.