Live RSTP to SmoothStreaming Session termination

Hi,

Using Wowza4, we have dynamic publishing points for a Live stream that are available via SmoothStreaming to clients. Everything is working except the stream termination.

Once the RTSP session ends, the SmoothStreaming session is also shutdown. Unfortunately this means that the clients will be cut-off and will not view the entire stream. SmoothStreaming has a buffer (aprox. 5~8sec) that is completely discarded in this scenario.

I believe this was not the behavior on previous Wowza version.

Looking at the logs, we can see that as soon as the RTSP session ends, the SmoothStream becomes unavailable and returns 404 to the clients:

HTTPStreamerAdapterSmoothStreamer.onISMVData: LiveStreamPacketizer not found

Is there any way around this issue? Can we somehow force the SmoothStreaming to continue available until the buffer empties and bot be unavailable as soon as the RTSP session ends?

Thank you very much for any possible assistance on this.

Regards,

Sérgio Dinis.

Sérgio,

Take a look at ModuleLoopUntilLive which you can configure to show a loop when the live stream goes down, and show the live stream again when it is started. It is dependent on a proper IMediaStreamActionNotify.Publish() and IMediaStreamActionNotify.UnPublish() events.

Richard

Sérgio,

I do think this is a solution for you. If you need to modify it, the source is include in the collection download.

Richard

Sérgio,

Loop until llive solution will help because you are wrapping the live stream in a server-side stream which is what the clients playback. When the live stream unpublishes, the server-side stream loops a file. If you know when you want to end the stream, you might create a separate playlist in the schedule smil to start on the same stream at that time and not repeat. This playlist will take over the server-side stream as the source, then play the file (it could be for 1 second) then stop. That would end the stream.

Richard

Hi Richard,

I’ve gone through the module and it’s sources, and our problem is a bit different from what the example expects.

Our RTSP clients connect to wowza and publishes a stream with a random name.

Our problem is that when the RTSP client disconnects, the HTTP clients immediately start timing out, we are looking for a way to prevent those timeouts, by gracefully ending the live stream, or by keeping it responsive until the HTTP clients are notified that the stream ended.

I was wondering If there is a way to keep the HTTP streamer alive for some more time OR to reduce the time it takes to timeout the chunks on the HTTP side.

Thanks,

Hi,

Is there any source code that can guide me on how to make the stream switch programatically once the RTSP stream ends?

I basically just what to have an extra 5~10seconds of HTTP SmoothStream after the RTSP live stream finishes.

Thank you in advance,

Sérgio Dinis.

Hi all,

I’ve just noticed this change on current WME 4.0.4:

“Increased live stream packetizer stream timeout default from 12 seconds to 40 seconds to ensure stream is available for HTTP streaming after source stream disconnects”

I though it could help me with this issue but after testing the new version, the conclusion was that the behavior is still the same: once the RTP is finished, the SmoothStreaming chunks are immediately unavailable.

In the following link, I’ve uploaded:

  1. the Application.xml

  2. Wowza log file for a sample live stream (starting and terminating)

  3. a network capture that shows the requests and the timeout/404 returned immediately after the RTP stream is closed.

Dropbox Wowza 4.0.4 Test

Looking at 14:07:03, when the input stream closes, the next HTTP SmoothStreaming request times out after 30s and returns a 404.

If I manage to setup the LoopUntilLive module, would I be able to prevent this behavior? If so, how can I control the end of the LiveSmoothStreaming stream? I mean, I still want it to close, but not immediately after the RTP, at least continue responding for a few seconds more (which it should have video for in cache).

Thanks,

Sérgio Dinis.