Hi!
Currently the server buffers about 3 seconds of video. If there is an interruption longer than 3 seconds, it switches to the next item in the playlist. However, sometimes the network may need 10 seconds long window because only within 10 seconds it can manage to transfer all the data (in average). Is there a setting in Wowza to manually specify the buffer time for live applications?
Thanks!
Atmapuri
Atmapuri,
If you are using the loop until live addon, or something like that, switches occur in IMediaStreamActionNotify.onPublish() and IMediaStreamActionNotify.onUnPublish(). The interruption you describe probably triggers IMediaStreamActionNotify.onUnPublish()
Richard
What is the requirement for your application? Normally folks are not looking to add latency, unless there is a delay requirement perhaps? You can add a sortBuffer, which would add latency.
Richard
The closest thing to this is the Wowza nDVR addon, but a better approach to ensuring a good playback experience is ABR streaming.
Richard
Dear Richard, somehow my question did not come through as intended. In the application settings it is possible to specify “Low Latency stream (ideal for chat applications)”. Is there an option to explicitly specify the amount of desired latency in seconds? The current default Wowza setting feels possibly too short for our purpose.
We frequently send video over low quality network connections, with big variations in network speed. A longer latency allows longer section of the live video to be stored on the server. This in turn allows for the clients to receive video smoothly without interruptions even though network speed from the encoder to the server may only achieve the minimum required speed within a 10 second intervals. (and with windows of 2-3 seconds almost completely without data and with next window of 2-3 seconds with double speed of what is required. So if the clients watch with 6 seconds delay they get too see uninterrupted smooth video if buffering is set to 6 seconds. If server buffers only 3 seconds, then the video breaks every 3 seconds. ).
Dear Richard, both solutions you suggest affect only the client side. That is the problems on the connection between the server and the client (the audience). They do not affect the encoder side. That is the problems on the connection between the sender of the live video and the Wowza server. I am interested in the solution for the second. Typically this is solved by allowing the user to configure a video buffer of specified size on the media server for the incoming video.
Thanks Roger. Somehow I have expected that both the sorting buffer and the delay buffer are already part of the servers normal processing. Is it possible to share information about what amount of delay can we count on with the Wowza server as is? How much buffering reserve is there on the connection from the live encoder to the wowza server by default? This info would allow us to measure the network and decide on what we need to use additionally.
Hi,
The following AddOn package make do what you want.
https://www.wowza.com/downloads/forums/publishwithdelay/PublishWithDelay.zip
It creates a second delayed stream that the players subscribe to. The addon has a simple module that is used to start & stop the delayed streams using a flash app.
The problem with trying to buffer the original source stream is that the players will normally try to connect and start at the live end of the buffer instead of the beginning. By using the delay package, the original source will be read as it comes in but will only be made available after the delay period has expired. It works on the stream timecodes so if the encoder is slow to send data (up to the delay time), it shouldn’t affect the playback.
The sort buffer probably wouldn’t work in your case as it buffers based on the system time that the packets arrive at the server. If they arrive late then they will be held in the sort buffer and will be sent out to the player late. This buffer is used in cases where the encoder sends video & audio packets that are out of order.
Roger.