Results 1 to 7 of 7

Thread: HLS availability when stream falters

  1. #1
    Join Date
    May 2013
    Posts
    18

    Default HLS availability when stream falters

    We have been using Wowza primarily to transcode and mux from RTMP to HLS. We've noticed for a while that when stopping the encoder, the stream will be cut off in the player. This seems to happen because the player will be so many .ts files behind "live" and there may be 3 or 4 left in the chunklist when the encoder disconnects, but when the encoder disconnects and Wowza starts cleaning up, it immediately destroys the packetizers. This means that the chunklist and all of the available .ts files in the current sliding window evaporate from under the player, before it has actually fetched all of the stream.

    Recently we have noticed a (I think) related phenomenon. Sometimes due to network issues, the encoder might not be able to get any data to Wowza for a significant amount of time, say 20 seconds. There is never an unPublish event in the log, so it appears that the session is maintained during this period (another indicator is that when data is again received, it gets appended to the same .mp4 file when using live-record). However, after something like 15 seconds the log shows "Destroy live stream packetizer: cupertinostreamingpacketizer" for every transcoded stream. It seems like this also causes the current chunklist and .ts files to evaporate, so that when data is again received, it's like the .m3u8 is started from scratch. This causes significant issues with our player, as we would expect that the player would be able to keep getting data (remember it's probably 40 seconds or so behind) until it gets to where the encoder quit sending. In a lot of cases, if the network issue is temporary, the encoder may have caught back up by then - so this seems like a needless interruption.

    So, for our needs the packetizer should never be destroyed if the stream it's packetizing still exists. It would also be nice if we could control how long it persists even after the stream is unPublished, to allow players to finish playing the available data.

    My question is, is there a way to alter the timeout for the Cupertino packetizer?

  2. #2
    Join Date
    Sep 2011
    Posts
    1,934

    Default

    Hi,
    If the encoder disconnects, the chunks are cleared from the playlist and the clients are disconnected because the stream no longer exists.
    Please see the Cupertino packetization article for altering packetization but this will not resolve the issue which appears to be the source or bandwidth between the source and Wowza.

    The above article is generally used for reducing the latency for Apple HLS streams.

    Jason

  3. #3
    Join Date
    May 2013
    Posts
    18

    Default

    Thanks for the reply. It certainly makes sense for the chunks to be cleared when the encoder disconnects and the stream no longer exists. Hence I wasn't that optimistic about being able to delay this after unPublish. However, our primary concern is the playlist being cleared when the encoder *hasn't* disconnected, but has simply not sent any data for some time.

    When this happens there is not an unPublish event, the streams themselves are not destroyed, the transcoder sessions don't end, and the RTMP connection between the encoder and Wowza is not disconnected. And yet, the packetizers get destroyed. This is what we're hoping to avoid. Is there anything that can be done to mitigate this?

  4. #4
    Join Date
    Sep 2011
    Posts
    1,934

    Default

    Hi,
    You could try editing the HTTPStreamer.xml to change the validSessionTimeout to a higher value for cupertino, that may help.
    <Property>
    	<Name>validSessionTimeout</Name>
    	<Value>50000</Value>
    	<Type>Integer</Type>
    </Property>
    Let me know if this helps you.

    Regards,
    Jason

  5. #5
    Join Date
    May 2013
    Posts
    18

    Default

    OK, thanks for the suggestion. I will up that value and see if it affects the behavior we're seeing. It's currently set at 25000 though, so to me that implies it shouldn't be timing out before 25 seconds. There are several timing related properties defined in the same configuration, is there documentation anywhere describing their use?

  6. #6
    Join Date
    Jun 2011
    Posts
    1,037

    Default

    Hi,
    The configuration guide provided with Wowza Media Server, WowzaMediaServer_ConfigurationReference.pdf (page 10), provides descriptions for some of these properties.
    Here's a quick link to the online version.

    Regards,
    Daren

  7. #7
    Join Date
    May 2013
    Posts
    18

    Default

    It does not appear to describe any of the properties to which I'm referring. The only mention of them is that there is an array for them: "Properties are additional configuration properties."

    I apologize if there is additional information I am overlooking, but as far as I can tell the following properties in the default HTTPStreamers.xml seem to have some potential as timeout configuration, but are not described formally anywhere:

    • newSessionTimeout
    • validSessionTimeout
    • requestTimeout
    • tcpTimeToLive
    • tcpKeepAliveTimeout

Similar Threads

  1. Re: Availability spelling mistake
    By matador in forum General Forum
    Replies: 1
    Last Post: 09-19-2012, 03:20 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •