[mythtv] [mythtv-commits] mythtv branch master updated by peper03. v0.28-pre-2360-gf54d267

[Mark Spieth]

On 31/10/2014 8:07 AM, Git Repo Owner wrote:
> The branch, master has been updated on the
> mythtv repository by gitolite user peper03.
>         via  f54d2672f224ba24224c8edd12fb0318797b3425 (commit)
>        from  0bf91f1af368f3aff75d8f1af505c33b4f57052a (commit)
>
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
>
> - Log -----------------------------------------------------------------
> commit f54d2672f224ba24224c8edd12fb0318797b3425
> Author:    Richard Hulme <peper03 at mythtv.org> at Thu, 30 Oct 2014 22:04:57 +0100
> Committer: Richard Hulme <peper03 at mythtv.org> at Thu, 30 Oct 2014 22:07:06 +0100
> URL:       http://code.mythtv.org/cgit/mythtv/commit/?id=f54d2672f224ba24224c8edd12fb0318797b3425
>
> Limit audio buffer to 700ms.  This prevents the frontend locking up when trying to stop playing an audio-only stream (e.g. DVB radio).  Without this patch the buffer tends to fill to around the 1500ms, which is below the current 2000ms limit, and AvFormatDecoder never leaves GetFrame.
> Normally AvFormatDecoder::GetFrame is exited when a video frame is decoded.  In this case the audio buffer is usually no more than about 500ms full.
>
> Also, buffering less audio data means less lag is noticeable when altering the volume if software mixing is used.
>
Ive just updated to latest master so I can try out helens mcf patches 
and noticed a big issue.

This particular commit causes AV sync problems with high A/V timestamp 
distances in streams as the audio and video buffers are used to absorb 
these differences when aligning audio and video at display time, 
depending which is lagging in the stream.
It seems to affects HD and higher compression streams (e.g. mp4s) more.
It will also affect those which use digital audio out (6ch) and use 
surround synthesis as this incurs a large processing latency for which 
700ms is very inadequate. I have set this now to 3000ms in my build as 
even at 2000ms I'm still getting jerky/skippy playback for HD channels 
but have yet to test what is optimal. This may warrant a DB setting so 
that it can be tweaked to find what is best, though worst case is what 
we need to find out.

Audio only streams should be handled distinctly to limit the audio 
output buffering which is what mythmusic originally did.

YMMV
mark