View previous topic :: View next topic |
Author |
Message |
bencoder
Joined: 23 Jan 2010 Posts: 4
|
Posted: Mon Jan 25, 2010 1:04 am Post subject: headers not sent on change to or from fallback |
|
|
I may be wrong here and perhaps there is some other explanation, but it would seem that headers are not sent when someone changes from the fallback to live or from the live to the fallback.
I.E. If listeners are listening to the live stream and the source disconnects, they go back to the fallback, which currently may be at a different sample rate/resolution(if video). The listeners therefore get mangled audio or a frozen video until the next track/video in the playlist comes on. The same appears to happen when moving from the fallback to a live source, the headers don't get sent to those listening clients who get shifted.
Can anyone confirm this behaviour? |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Mon Jan 25, 2010 1:58 am Post subject: |
|
|
correct, there are no headers sent over fallback because no player knows how to process http style headers midstream, not that the headers would actually provide any reliable information in regard to the content. Do not expect players to handle changes to the content format (eg samplerate/channels) or the codec midstream, although some do handle the former. This is why it is required to make sure the fallback content is the same format as the originating stream.
karl. |
|
Back to top |
|
|
bencoder
Joined: 23 Jan 2010 Posts: 4
|
Posted: Mon Jan 25, 2010 8:45 am Post subject: |
|
|
Ok, perhaps I got the terminology wrong, what I meant was that it doesn't send the header/metadata for the file that it's currently playing, like it does when it changes track or when a new connection joins in the middle of a track.
It may not be recommended, but changes in bitrate or resolution do work with some players and it is those I am targetting. I'm not sure I understand why moving from one mountpoint to a fallback (where stream metadata is not sent) should be any different than moving from one track in a stream to the next (where the metadata is sent) or when you connect in the middle of a track (where metadata is also sent) |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Mon Jan 25, 2010 2:36 pm Post subject: |
|
|
If you are talking for non-ogg streams, then if you don't send metadata when you switch mountpoints then corruption occurs on the stream . Remember ID3 has nothing to do with shoutcast metadata inserts and those inserts actually break the codec specification so the player has to remove them from the stream before decoding.
None of this is related to changes in samplerate/channels etc and that is possible with icecast, just not advised because of listeners software limitations.
karl. |
|
Back to top |
|
|
bencoder
Joined: 23 Jan 2010 Posts: 4
|
Posted: Mon Jan 25, 2010 9:08 pm Post subject: |
|
|
karlH wrote: |
If you are talking for non-ogg streams |
I'm using ogg streams. It doesn't matter too much, I have found a solution for now of just including a very short clip before the first item in the playlist, so the short clip never plays but when the first item starts it sends the data and the client adjusts resolution. |
|
Back to top |
|
|
|