Mailing List Archive

"Extra Audio Buffering" setting
Hi Devs

There is a Frontend General Playback setting called "Extra audio
buffering" which mentions certain types of tuners that cause crackly
audio. Actually it enables setting DecodeExtraAudio which then maybe
sets a flag called lowbuffers in the demuxer (class AvFormatDecoder).
There is lots of complicated logic around whether or not that flag is
set and in some cases its value is saved and reset.

The lowbuffers flag is only tested once in the system and if set the
program buffers 100ms of video packets in AvFormatDecoder::GetFrame, so
that audio is not left behind.

Bug #13172 describes how playback becomes extremely jerky if you adjust
audio sync negatively more than a small amount. The solution is very
simple, just buffer more than 100ms in AvFormatDecoder::GetFrame. I
tested with 1000ms and then you can successfully set audio sync to
somewhere around -1200 before it becomes jerky. In the patch for the fix
I settled on a figure of 250 as a good default and added for a setting
called AudioReadAhead for the value.

I would also like to get rid of the complex logic and flag surrounding
the DecodeExtraAudio flag and replace that setting in frontend setup
with AudioReadAhead with a default value of 250. With a value of 250 or
1000 it works on everything I have tried. There is no adverse impact
that I can see, although it will take some extra memory for the
additional buffering. I do not know why there is all the extra logic
around whether or not to set the flag, it is safe and easy to set it all
the time.

I propose a setting that specifies number of milliseconds of audio
read-ahead with an explanation that says to increase this value if the
audio is jerky especially when adjusting audio sync negative.

Any comments?

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: "Extra Audio Buffering" setting [ In reply to ]
On Thu, Nov 9, 2017 at 2:20 PM Peter Bennett <pb.mythtv@gmail.com> wrote:

> Hi Devs
>
> There is a Frontend General Playback setting called "Extra audio
> buffering" which mentions certain types of tuners that cause crackly
> audio. Actually it enables setting DecodeExtraAudio which then maybe
> sets a flag called lowbuffers in the demuxer (class AvFormatDecoder).
> There is lots of complicated logic around whether or not that flag is
> set and in some cases its value is saved and reset.
>
> The lowbuffers flag is only tested once in the system and if set the
> program buffers 100ms of video packets in AvFormatDecoder::GetFrame, so
> that audio is not left behind.
>
> Bug #13172 describes how playback becomes extremely jerky if you adjust
> audio sync negatively more than a small amount. The solution is very
> simple, just buffer more than 100ms in AvFormatDecoder::GetFrame. I
> tested with 1000ms and then you can successfully set audio sync to
> somewhere around -1200 before it becomes jerky. In the patch for the fix
> I settled on a figure of 250 as a good default and added for a setting
> called AudioReadAhead for the value.
>
> I would also like to get rid of the complex logic and flag surrounding
> the DecodeExtraAudio flag and replace that setting in frontend setup
> with AudioReadAhead with a default value of 250. With a value of 250 or
> 1000 it works on everything I have tried. There is no adverse impact
> that I can see, although it will take some extra memory for the
> additional buffering. I do not know why there is all the extra logic
> around whether or not to set the flag, it is safe and easy to set it all
> the time.
>
> I propose a setting that specifies number of milliseconds of audio
> read-ahead with an explanation that says to increase this value if the
> audio is jerky especially when adjusting audio sync negative.
>
> Any comments?
>
> Peter
>

I have not looked at any of this code, but my guess is that it was to
handle frame-grabber cards, where Myth had to mux the audio and video
together itself. We pretty much don't support those anymore (using one in
this age is just asking for pain).

If you want to play it safe, create a branch and ask as many people as
possible to try it. I will.

However, if it is working well for you, even with your RPi units, then I
expect it to be fine.

John
Re: "Extra Audio Buffering" setting [ In reply to ]
On 10/11/17 08:26, John P Poet wrote:
> On Thu, Nov 9, 2017 at 2:20 PM Peter Bennett <pb.mythtv@gmail.com
> <mailto:pb.mythtv@gmail.com>> wrote:
>
> Hi Devs
>
> There is a Frontend General Playback setting called "Extra audio
> buffering" which mentions certain types of tuners that cause crackly
> audio. Actually it enables setting DecodeExtraAudio which then maybe
> sets a flag called lowbuffers in the demuxer (class AvFormatDecoder).
> There is lots of complicated logic around whether or not that flag is
> set and in some cases its value is saved and reset.
>
> The lowbuffers flag is only tested once in the system and if set the
> program buffers 100ms of video packets in
> AvFormatDecoder::GetFrame, so
> that audio is not left behind.
>
> Bug #13172 describes how playback becomes extremely jerky if you
> adjust
> audio sync negatively more than a small amount. The solution is very
> simple, just buffer more than 100ms in AvFormatDecoder::GetFrame. I
> tested with 1000ms and then you can successfully set audio sync to
> somewhere around -1200 before it becomes jerky. In the patch for
> the fix
> I settled on a figure of 250 as a good default and added for a setting
> called AudioReadAhead for the value.
>
> I would also like to get rid of the complex logic and flag surrounding
> the DecodeExtraAudio flag and replace that setting in frontend setup
> with AudioReadAhead with a default value of 250. With a value of
> 250 or
> 1000 it works on everything I have tried. There is no adverse impact
> that I can see, although it will take some extra memory for the
> additional buffering. I do not know why there is all the extra logic
> around whether or not to set the flag, it is safe and easy to set
> it all
> the time.
>
> I propose a setting that specifies number of milliseconds of audio
> read-ahead with an explanation that says to increase this value if the
> audio is jerky especially when adjusting audio sync negative.
>
> Any comments?
>
> Peter
>
>
> I have not looked at any of this code, but my guess is that it was to
> handle frame-grabber cards, where Myth had to mux the audio and video
> together itself.  We pretty much don't support those anymore (using
> one in this age is just asking for pain).
>
> If you want to play it safe, create a branch and ask as many people as
> possible to try it.  I will.
>
> However, if it is working well for you, even with your RPi units, then
> I expect it to be fine.
>
> John
>
Beware of and test with mythmusic and audio only streams when you change
this.

Note that audio is rendered as it is seen in the decoded stream whereas
video is not.
Audio only for mythmusic has as special shortcut that limits the buffer
to 500ms or less so that when you seek or change streams the response is
quick.

You are correct in that the audio buffer size directly relates to the
amount of -ve sync achievable. This is a design constraint.

Also some OTA streams have largely varying A to V time gaps on PTS and
the buffer is also required to absorb this. mkv's can also be quite
un-aligned Ive found.

If you enable some of the more fancy features in audio land such as
ch->6ch upsampling and AC3 reencoding, you will also chew up the buffer.
The upsampling is especially a buffer hog partially due to the LPF for
the subwoofer channel. I have noticed this is quite long when I
start/skip for audio to catch up (600+ms).

Changing the extra buffering to a number in settings is ok but you need
to add some help text.
That said, I have patches to change mine to 1.5 secs as default audio
buffer size because the existing is inadequate for some of my media.

As an aside, there is also a bug in passthru mode in that if the rate
does not match the standard AC3 rate, then you get no sound out of your
digital amp as the AC3/DTS stream is not framed correctly due to
differing bitrates on the SPIDF line. The workaround is to enable
timestretch as this reencodes correctly and then all sound is good. This
happens on most of our (AU) HD channels.

HTH
mark
Re: "Extra Audio Buffering" setting [ In reply to ]
On Fri, 10 Nov 2017 11:22:03 +1100, you wrote:

>
>On 10/11/17 08:26, John P Poet wrote:
>> On Thu, Nov 9, 2017 at 2:20 PM Peter Bennett <pb.mythtv@gmail.com
>> <mailto:pb.mythtv@gmail.com>> wrote:
>>
>> Hi Devs
>>
>> There is a Frontend General Playback setting called "Extra audio
>> buffering" which mentions certain types of tuners that cause crackly
>> audio. Actually it enables setting DecodeExtraAudio which then maybe
>> sets a flag called lowbuffers in the demuxer (class AvFormatDecoder).
>> There is lots of complicated logic around whether or not that flag is
>> set and in some cases its value is saved and reset.
>>
>> The lowbuffers flag is only tested once in the system and if set the
>> program buffers 100ms of video packets in
>> AvFormatDecoder::GetFrame, so
>> that audio is not left behind.
>>
>> Bug #13172 describes how playback becomes extremely jerky if you
>> adjust
>> audio sync negatively more than a small amount. The solution is very
>> simple, just buffer more than 100ms in AvFormatDecoder::GetFrame. I
>> tested with 1000ms and then you can successfully set audio sync to
>> somewhere around -1200 before it becomes jerky. In the patch for
>> the fix
>> I settled on a figure of 250 as a good default and added for a setting
>> called AudioReadAhead for the value.
>>
>> I would also like to get rid of the complex logic and flag surrounding
>> the DecodeExtraAudio flag and replace that setting in frontend setup
>> with AudioReadAhead with a default value of 250. With a value of
>> 250 or
>> 1000 it works on everything I have tried. There is no adverse impact
>> that I can see, although it will take some extra memory for the
>> additional buffering. I do not know why there is all the extra logic
>> around whether or not to set the flag, it is safe and easy to set
>> it all
>> the time.
>>
>> I propose a setting that specifies number of milliseconds of audio
>> read-ahead with an explanation that says to increase this value if the
>> audio is jerky especially when adjusting audio sync negative.
>>
>> Any comments?
>>
>> Peter
>>
>>
>> I have not looked at any of this code, but my guess is that it was to
>> handle frame-grabber cards, where Myth had to mux the audio and video
>> together itself.? We pretty much don't support those anymore (using
>> one in this age is just asking for pain).
>>
>> If you want to play it safe, create a branch and ask as many people as
>> possible to try it.? I will.
>>
>> However, if it is working well for you, even with your RPi units, then
>> I expect it to be fine.
>>
>> John
>>
>Beware of and test with mythmusic and audio only streams when you change
>this.
>
>Note that audio is rendered as it is seen in the decoded stream whereas
>video is not.
>Audio only for mythmusic has as special shortcut that limits the buffer
>to 500ms or less so that when you seek or change streams the response is
>quick.
>
>You are correct in that the audio buffer size directly relates to the
>amount of -ve sync achievable. This is a design constraint.
>
>Also some OTA streams have largely varying A to V time gaps on PTS and
>the buffer is also required to absorb this. mkv's can also be quite
>un-aligned Ive found.
>
>If you enable some of the more fancy features in audio land such as
>ch->6ch upsampling and AC3 reencoding, you will also chew up the buffer.
>The upsampling is especially a buffer hog partially due to the LPF for
>the subwoofer channel. I have noticed this is quite long when I
>start/skip for audio to catch up (600+ms).
>
>Changing the extra buffering to a number in settings is ok but you need
>to add some help text.
>That said, I have patches to change mine to 1.5 secs as default audio
>buffer size because the existing is inadequate for some of my media.
>
>As an aside, there is also a bug in passthru mode in that if the rate
>does not match the standard AC3 rate, then you get no sound out of your
>digital amp as the AC3/DTS stream is not framed correctly due to
>differing bitrates on the SPIDF line. The workaround is to enable
>timestretch as this reencodes correctly and then all sound is good. This
>happens on most of our (AU) HD channels.
>
>HTH
>mark

When playing downloaded video files, be aware that there is a nasty
bug in one of the most commonly used programs used to make these
files, Adobe Premiere. Whenever it creates slow motion in its files,
the audio/video interleaving seems to be disabled, at least for the
slow motion section. So you get all the video frames followed by all
the audio frames, with no interleaving. If the slow motion section is
small enough, the playback program's buffering can cope with this, but
MythTV seems to have a smaller buffer size than most Windows player
programs, and that means it will fail to play back these files when
the Windows software is OK. This causes MythTV to be blamed for the
problem, rather than Adobe. I have tried to convince the owner of one
web site that I subscribe to that it is an Adobe bug he should report
to them and get fixed, but as he did not have sufficient technical
knowledge I was unable to convince him and he just told me to use a
better program to play the files. My solution is to run his files
through ffmpeg with the right options to get them re-interleaved
correctly. But it would be good to work out what sort of buffer sizes
are commonly used in other software and make MythTV use at least that
much buffer, so it does not get blamed for problems like this.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: "Extra Audio Buffering" setting [ In reply to ]
On 11/11/2017 08:14 PM, Stephen Worthington wrote:
> When playing downloaded video files, be aware that there is a nasty
> bug in one of the most commonly used programs used to make these
> files, Adobe Premiere. Whenever it creates slow motion in its files,
> the audio/video interleaving seems to be disabled, at least for the
> slow motion section. So you get all the video frames followed by all
> the audio frames, with no interleaving. If the slow motion section is
> small enough, the playback program's buffering can cope with this, but
> MythTV seems to have a smaller buffer size than most Windows player
> programs, and that means it will fail to play back these files when
> the Windows software is OK. This causes MythTV to be blamed for the
> problem, rather than Adobe. I have tried to convince the owner of one
> web site that I subscribe to that it is an Adobe bug he should report
> to them and get fixed, but as he did not have sufficient technical
> knowledge I was unable to convince him and he just told me to use a
> better program to play the files. My solution is to run his files
> through ffmpeg with the right options to get them re-interleaved
> correctly. But it would be good to work out what sort of buffer sizes
> are commonly used in other software and make MythTV use at least that
> much buffer, so it does not get blamed for problems like this.

What is the visible effect of this in MythTV? When you say it fails to
play does that mean it completely fails or is it out of sync or uneven?
Can you provide an example or point me to one?

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: "Extra Audio Buffering" setting [ In reply to ]
On Sun, 2017-11-12 at 14:14 +1300, Stephen Worthington wrote:
> ---snip---
> When playing downloaded video files, be aware that there is a nasty
> bug in one of the most commonly used programs used to make these
> files, Adobe Premiere. Whenever it creates slow motion in its files,
> the audio/video interleaving seems to be disabled, at least for the
> slow motion section. So you get all the video frames followed by all
> the audio frames, with no interleaving. If the slow motion section
> is
> small enough, the playback program's buffering can cope with this,
> but
> MythTV seems to have a smaller buffer size than most Windows player
> programs, and that means it will fail to play back these files when
> the Windows software is OK. This causes MythTV to be blamed for the
> problem, rather than Adobe. I have tried to convince the owner of
> one
> web site that I subscribe to that it is an Adobe bug he should report
> to them and get fixed, but as he did not have sufficient technical
> knowledge I was unable to convince him and he just told me to use a
> better program to play the files. My solution is to run his files
> through ffmpeg with the right options to get them re-interleaved
> correctly. But it would be good to work out what sort of buffer
> sizes
> are commonly used in other software and make MythTV use at least that
> much buffer, so it does not get blamed for problems like this.

Do you have a pointer to such a file so that I can look at it? Thanks.

David

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: "Extra Audio Buffering" setting [ In reply to ]
On Sat, 11 Nov 2017 22:36:33 -0500, you wrote:

>
>
>On 11/11/2017 08:14 PM, Stephen Worthington wrote:
>> When playing downloaded video files, be aware that there is a nasty
>> bug in one of the most commonly used programs used to make these
>> files, Adobe Premiere. Whenever it creates slow motion in its files,
>> the audio/video interleaving seems to be disabled, at least for the
>> slow motion section. So you get all the video frames followed by all
>> the audio frames, with no interleaving. If the slow motion section is
>> small enough, the playback program's buffering can cope with this, but
>> MythTV seems to have a smaller buffer size than most Windows player
>> programs, and that means it will fail to play back these files when
>> the Windows software is OK. This causes MythTV to be blamed for the
>> problem, rather than Adobe. I have tried to convince the owner of one
>> web site that I subscribe to that it is an Adobe bug he should report
>> to them and get fixed, but as he did not have sufficient technical
>> knowledge I was unable to convince him and he just told me to use a
>> better program to play the files. My solution is to run his files
>> through ffmpeg with the right options to get them re-interleaved
>> correctly. But it would be good to work out what sort of buffer sizes
>> are commonly used in other software and make MythTV use at least that
>> much buffer, so it does not get blamed for problems like this.
>
>What is the visible effect of this in MythTV? When you say it fails to
>play does that mean it completely fails or is it out of sync or uneven?
>Can you provide an example or point me to one?
>
>Peter

It plays but pauses all the time in order to buffer more data. And
when the interleave gets too extreme, I think it just stops playing at
that point. Unfortunately, the examples I have are all copyright
downloads, so I can not share them. But if anyone has a copy of Adobe
Premiere, it should be easy to create one - just use the slow motion
option for part of the video.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: "Extra Audio Buffering" setting [ In reply to ]
On Sat, 11 Nov 2017 23:50:35 -0500
David Hampton <mythtv@dhampton.net> wrote:

>
> Do you have a pointer to such a file so that I can look at it?
> Thanks.
>

I believe https://code.mythtv.org/trac/ticket/12302 is another symptom
of the same issue. I've updated it with some old analysis.

If so, you should be able to easily reproduce it by playing some
Apple-generated content, ie. download some videos made by someone on an
iPhone. I believe there are lots available ;)

I had access to an iPhone 4 at the time; not sure what the latest
offerings are like.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: "Extra Audio Buffering" setting [ In reply to ]
On 11/11/2017 11:55 PM, Stephen Worthington wrote:
> It plays but pauses all the time in order to buffer more data. And
> when the interleave gets too extreme, I think it just stops playing at
> that point. Unfortunately, the examples I have are all copyright
> downloads, so I can not share them. But if anyone has a copy of Adobe
> Premiere, it should be easy to create one - just use the slow motion
> option for part of the video.
You can try my patch at https://code.mythtv.org/trac/ticket/13172
With that patch you can also set AudioReadAhead to any value you wish in
milliseconds. You should be able to tweak it so that your playback works.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: "Extra Audio Buffering" setting [ In reply to ]
On Sun, 12 Nov 2017 08:13:39 -0500, you wrote:

>
>
>On 11/11/2017 11:55 PM, Stephen Worthington wrote:
>> It plays but pauses all the time in order to buffer more data. And
>> when the interleave gets too extreme, I think it just stops playing at
>> that point. Unfortunately, the examples I have are all copyright
>> downloads, so I can not share them. But if anyone has a copy of Adobe
>> Premiere, it should be easy to create one - just use the slow motion
>> option for part of the video.
>You can try my patch at https://code.mythtv.org/trac/ticket/13172
>With that patch you can also set AudioReadAhead to any value you wish in
>milliseconds. You should be able to tweak it so that your playback works.
>
>Peter

I will try setting up a Master compile with the patch on my test
machine if I get the time tomorrow.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: "Extra Audio Buffering" setting [ In reply to ]
Le 12 nov. 2017 04:37, "Peter Bennett" <pb.mythtv@gmail.com> a écrit :



On 11/11/2017 08:14 PM, Stephen Worthington wrote:

> When playing downloaded video files, be aware that there is a nasty
> bug in one of the most commonly used programs used to make these
> files, Adobe Premiere. Whenever it creates slow motion in its files,
> the audio/video interleaving seems to be disabled, at least for the
> slow motion section. So you get all the video frames followed by all
> the audio frames, with no interleaving. If the slow motion section is
> small enough, the playback program's buffering can cope with this, but
>

The core issue is that mythtv player is very poorly designed here. It uses
a single ring buffer, demuxing data as it comes in. If the frame demuxed is
a video frame it will decode it, if it's audio then so be it.

If the container doesn't contain properly interleaved data, then it will
decode a lot of video and by that time the audio may underrun.

It should have two different streams, one for audio and one for video.

The entire architecture of the player sucks anyway, it's beyond
salvageable.


>
Re: "Extra Audio Buffering" setting [ In reply to ]
On 12/11/17 17:15, Jean-Yves Avenard wrote:
>
>
> Le 12 nov. 2017 04:37, "Peter Bennett" <pb.mythtv@gmail.com
> <mailto:pb.mythtv@gmail.com>> a écrit :
>
>
>
> On 11/11/2017 08:14 PM, Stephen Worthington wrote:
>
> When playing downloaded video files, be aware that there is a nasty
> bug in one of the most commonly used programs used to make these
> files, Adobe Premiere.  Whenever it creates slow motion in its
> files,
> the audio/video interleaving seems to be disabled, at least for the
> slow motion section.  So you get all the video frames followed
> by all
> the audio frames, with no interleaving.  If the slow motion
> section is
> small enough, the playback program's buffering can cope with
> this, but
>
>
> The core issue is that mythtv player is very poorly designed here. It
> uses a single ring buffer, demuxing data as it comes in. If the frame
> demuxed is a video frame it will decode it, if it's audio then so be it. 
>
> If the container doesn't contain properly interleaved data, then it will
> decode a lot of video and by that time the audio may underrun. 
>
> It should have two different streams, one for audio and one for video. 
>
> The entire architecture of the player sucks anyway, it's beyond
> salvageable. 
>
>

All the decoder side of things needs reworking for the newer ffmpeg api
anyway, so it's the right time to start rebuilding it.


Regards
Stuart

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org