Hi there, Any other versions of Google Chrome and all version of other browsers are working. I have done my best to set up the intro to match the live stream. http://185.139.168.34:8000/yleisohjelma - intro is 256 kbits/s 48 kHz ISO-MPEG2 L3 - live is 256 kbits/s 48 kHz ISO-MPEG2 L3 http://185.139.168.34:8000/vara - live is 128 kBits/s 48 kHz, possible ISO-MPEG2 L3 - there is no intro Of cause there is a certain difference between a file and a stream. Yours, Oskar> On 18 Apr 2018, at 17.38, Leif Scriba <leif at scriba-bb.de> wrote: > > > Hello Oskar, > > No i didn’t face it with this exact version of Chrome but with different versions and other players/ Webbrowsers. > IMHO you should first try to set encoding of intro and stream identical. And try different players. > > Regards > Leif > > > Am 18.04.2018 um 13:53 schrieb Oskar Vilkevuori <oskar.vilkevuori at ovt.fi <mailto:oskar.vilkevuori at ovt.fi>>: > >> Hi Leif, >> >> Did You faced that with the exact same Chrome version? Since this version is the only one having this issue. I have had this kind of arrangement (intro + live stream) for decades. Technology changes but the idea is the same. I have tested a lot of hardware and combinations. >> >> I do have a fail over stream (with different specs) and that hasn’t been an issue at all. >> >> I do not know but I assume my problem is related with headers on the stream but I don’t have more right now. Thats why I’m writing here… >> >> Yours, >> >> Oskar >> >>> On 18 Apr 2018, at 12.26, Leif Scriba <leif at scriba-bb.de <mailto:leif at scriba-bb.de>> wrote: >>> >>> Hello Oskar, >>> >>> I had a similar problem. The fix was to produce an intro file with same Bitrate, sampling rate (khz), channels and so on as the stream. >>> Most players get confused when one of this parameters changes in between. >>> >>> Cheers >>> Leif >>> >>> >>> >>> Am 18.04.2018 um 10:13 schrieb Oskar Vilkevuori <oskar.vilkevuori at ovt.fi <mailto:oskar.vilkevuori at ovt.fi>>: >>> >>>> Hi there, >>>> >>>> I ran to dead end when Google released a new version for Chrome. I have tried to search with google and I haven’t found anything. >>>> >>>> There seems to be a problem when a stream has an intro element. It only plays the the intro and does not allow the stream to be played. >>>> http://185.139.186.34:8000 <http://185.139.186.34:8000/>/yleisohjelma >>>> >>>> And if there is no intro then it will play like: >>>> >>>> http://185.139.186.34:8000/vara <http://185.139.186.34:8000/vara> >>>> >>>> Is it something wrong on my config? Is this somehow related with http headers? Or Access Control Allow Origin? >>>> >>>> Looking forward, >>>> >>>> Yours, >>>> >>>> Oskar Vilkevuori >>>> Radio Dei >>>> _______________________________________________ >>>> Icecast mailing list >>>> Icecast at xiph.org <mailto:Icecast at xiph.org> >>>> http://lists.xiph.org/mailman/listinfo/icecast <http://lists.xiph.org/mailman/listinfo/icecast> >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org <mailto:Icecast at xiph.org> >>> http://lists.xiph.org/mailman/listinfo/icecast <http://lists.xiph.org/mailman/listinfo/icecast> >> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org <mailto:Icecast at xiph.org> >> http://lists.xiph.org/mailman/listinfo/icecast <http://lists.xiph.org/mailman/listinfo/icecast> > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20180418/f7145bd5/attachment.html>
There should be no issue with the varying bit rate. For an MP3 stream, you can change bit rates mid-stream all you want as long as you keep the sample rate and channel counts the same. If you check chrome://media-internals, you'll see that you're getting a PIPELINE_ERROR_DECODE. Since Chrome v64, it has been a lot more picky about the streams it accepts. I suspect that Icecast is simply dumping the buffer for the file out to the client, and then needle-dropping into the middle of the live MP3 stream without re-syncing to a frame boundary first. (Someone more familiar with the Icecast internals could probably answer that in detail.) I suspect that Chrome isn't happy about this, doesn't bother to re-sync to the stream itself, and throws this error. I would recommend dropping your intro. In-stream intros tend to have bad side effects anyway, when clients get disconnected and have to reconnect. This re-connection often happens seamlessly, but cannot be so seamless if your intro gets sent for every GET request. Brad Isbell brad at musatcha.com http://www.musatcha.com On Wed, Apr 18, 2018 at 8:06 AM, Oskar Vilkevuori <oskar.vilkevuori at ovt.fi> wrote:> Hi there, > > Any other versions of Google Chrome and all version of other browsers are > working. > > I have done my best to set up the intro to match the live stream. > > http://185.139.168.34:8000/yleisohjelma > - intro is 256 kbits/s 48 kHz ISO-MPEG2 L3 > - live is 256 kbits/s 48 kHz ISO-MPEG2 L3 > > http://185.139.168.34:8000/vara > - live is 128 kBits/s 48 kHz, possible ISO-MPEG2 L3 > - there is no intro > > Of cause there is a certain difference between a file and a stream. > > Yours, > > Oskar > > > On 18 Apr 2018, at 17.38, Leif Scriba <leif at scriba-bb.de> wrote: > > > Hello Oskar, > > No i didn’t face it with this exact version of Chrome but with different > versions and other players/ Webbrowsers. > IMHO you should first try to set encoding of intro and stream identical. > And try different players. > > Regards > Leif > > > Am 18.04.2018 um 13:53 schrieb Oskar Vilkevuori <oskar.vilkevuori at ovt.fi>: > > Hi Leif, > > Did You faced that with the exact same Chrome version? Since this version > is the only one having this issue. I have had this kind of arrangement > (intro + live stream) for decades. Technology changes but the idea is the > same. I have tested a lot of hardware and combinations. > > I do have a fail over stream (with different specs) and that hasn’t been > an issue at all. > > I do not know but I assume my problem is related with headers on the > stream but I don’t have more right now. Thats why I’m writing here… > > Yours, > > Oskar > > On 18 Apr 2018, at 12.26, Leif Scriba <leif at scriba-bb.de> wrote: > > Hello Oskar, > > I had a similar problem. The fix was to produce an intro file with same > Bitrate, sampling rate (khz), channels and so on as the stream. > Most players get confused when one of this parameters changes in between. > > Cheers > Leif > > > > Am 18.04.2018 um 10:13 schrieb Oskar Vilkevuori <oskar.vilkevuori at ovt.fi>: > > Hi there, > > I ran to dead end when Google released a new version for Chrome. I have > tried to search with google and I haven’t found anything. > > There seems to be a problem when a stream has an intro element. It only > plays the the intro and does not allow the stream to be played. > > http://185.139.186.34:8000/yleisohjelma > > And if there is no intro then it will play like: > > http://185.139.186.34:8000/vara > > Is it something wrong on my config? Is this somehow related with http > headers? Or Access Control Allow Origin? > > Looking forward, > > Yours, > > Oskar Vilkevuori > Radio Dei > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20180418/09901911/attachment-0001.html>
Good morning, On Wed, 2018-04-18 at 22:17 -0700, Brad Isbell wrote:> There should be no issue with the varying bit rate. For an MP3 > stream, you > can change bit rates mid-stream all you want as long as you keep the > sample > rate and channel counts the same.This is true for many codecs. However we have seen some really bad implementations for MP3 that required all encoder parameters to be time-invariant. I don't want to say that it's the problem. Just want to say it's worth to have a look at this as well.> If you check chrome://media-internals, you'll see that you're getting > a PIPELINE_ERROR_DECODE. Since Chrome v64, it has been a lot more > picky > about the streams it accepts.> I suspect that Icecast is simply dumping the buffer for the file out > to the > client, and then needle-dropping into the middle of the live MP3 > stream > without re-syncing to a frame boundary first. (Someone more familiar > with > the Icecast internals could probably answer that in detail.)For all supported codecs Icecast2 does proper re-syncing and all other necessary steps for a correct transition. However as MP3 is not a supported codec Icecast2 uses the 'generic' handler. Which basically does what you said above.> I suspect that Chrome isn't happy about this, doesn't bother to > re-sync to the stream itself, and throws this error.Then it would be Chrome's bug. The syncwords exist for a reason: to make broken streams recoverable. Bit flipping errors aren't uncommon. And MP3 can handle them. There is no real excuse why not to handle them. More true if it worked in older versions of the same software. But this is just a guess at this point. Generally speaking: Players improved over the last decade. Even MP3 players.> > On Wed, Apr 18, 2018 at 8:06 AM, Oskar Vilkevuori > <oskar.vilkevuori at ovt.fi> > wrote: > > > I have done my best to set up the intro to match the live stream. > > > > http://185.139.168.34:8000/yleisohjelma > > - intro is 256 kbits/s 48 kHz ISO-MPEG2 L3 > > - live is 256 kbits/s 48 kHz ISO-MPEG2 L3 > > > > http://185.139.168.34:8000/vara > > - live is 128 kBits/s 48 kHz, possible ISO-MPEG2 L3 > > - there is no introWith best regards, -- Philipp Schafft (CEO/Geschäftsführer) Telephon: +49.3535 490 17 92 Löwenfelsen UG (haftungsbeschränkt) Registration number: Bickinger Straße 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.xiph.org/pipermail/icecast/attachments/20180419/ed1d9bd9/attachment.sig>