[mythtv] [mythtv-commits] mythtv branch master updated by peper03. v0.28-pre-2360-gf54d267
peper03 at yahoo.com
Tue Nov 4 09:53:47 UTC 2014
On 04/11/14 10:16, Warpme wrote:
> On 04/11/14 00:48, Mark Spieth wrote:
>> 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
>>> 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.
>> mythtv-dev mailing list
>> mythtv-dev at mythtv.org
>> MythTV Forums: https://forum.mythtv.org
> Just another data point.
> I also have A/V sync problems by this change. It is on some SD TV channels.
> Reverting it solves issue.
Ok, I've reverted the commit. Thanks for letting me know!
More information about the mythtv-dev