Reducing live rebroadcast delay- can't get less than 15-20 secs

Wowza Streaming Engine
1

I have read through several forum posts and articles trying to reduce the live delay for my particular set up, but I can’t seem to get the delay below 15-20 seconds, even when streaming from the origin instead of the edge server.

Here’s my setup and some of the things I’ve tried:

DVR Edge/Origin pair

Source video from Flash Media Live Encoder

RTMP to origin

H.264 encoding for video

MP3 encoding for audio

Key frame interval twiddled from 4 sec all the way down to 1 sec with little effect on live delay

HTTP from origin

Strobe media playback -based module for playing with buffers turned down to minimum recommendations (based on multiples of key frame interval)

In conf/dvrorigin/Application:

Twiddled with Streams/Properties/Property/flushinterval values

Twiddled with the following properties in LiveStreamPacketizer:

sanjoseChunkDurationTarget

sanjoseMaxChunkCount

sanjosePlaylistChunkCount

sanjoseRepeaterChunkCount

Twiddled with the following properties in HTTPStreamer:

sanjoseChunkDurationTarget

sanjoseMaxChunkCount

sanjosePlaylistChunkCount

sanjoseRepeaterChunkCount

Prior to purchasing Wowza for its superior documentation, built-in DVR capabilities, and more advanced server-side API, we were evaluating Flash Media Server and were impressed with its ability to rebroadcast incoming RTMP streams to outgoing RTMP players with only about a 1-2 second delay. This was just simple live to live (without DVR recording enabled), but regardless, that level of performance is now expected and more importantly is actually an operational requirement for our customer.

So, is there anything else I can do besides everything I’ve already tried to reduce this delay or is it going to always be about 15-20 sec for RTMP -> server -> HTTP? Is this because Wowza only supports HTTP out at the moment instead of RTMP and if so, when will that be addressed?

I hate to say it, but management has directed me to go back to Flash Media Server if I can’t reduce this delay. After all the time I’ve already spent on this and our current tight schedule, I am afraid of spending a lot of time switching to back to Flash Media Server only to discover that the delay with that software is about the same once live rebroadcast (w/ DVR controls) & archival broadcast (w/ DVR controls) are enabled there as well.

Any help would be greatly appreciated.

Thanks!

2

These are the things you have to work with. Did you try 2 second key frame frequency and sanjoseChunkDurationTarget “2000”.

Richard

3

rtmp and http streaming are two different things. rtmp is great for low latency streaming as you have discovered. You won’t get the same latency using http streaming. http streaming by its nature requires 3 chunks of audio and video to be available before playback starts.

Wowza nDVR only streams via HTTP streaming.

nDVR creates chunks based on the keyframe frequency. So if the incoming stream has 2 second keyframes, DVR will create chunks of 2 seconds each. The sanJoseChunkDurationTarget property (and others you are playing with) do not come into play.

So what you want to do is to adjust your incoming stream to have small video keyframe intervals. 2 seconds is probably a good target.

In your log file, you can see the DVR chunk duration for the first 10 chunks that are saved. Looks for lines that look like this:

INFO server comment - LiveStreamDvrRecorder.endChunk[app/definst/myStream]: Add chunk: ind:1 a/v/k: packets: 87/30/0 durations: 2020/2000/-1

INFO server comment - LiveStreamDvrRecorder.endChunk[app/definst/myStream]: Add chunk: ind:2 a/v/k: packets: 87/30/0 durations: 2021/2000/-1

INFO server comment - LiveStreamDvrRecorder.endChunk[app/definst/myStream]: Add chunk: ind:3 a/v/k: packets: 84/30/0 durations: 1950/2000/-1

Scott