Current Setup
We have achieved exceptionally low latency using the above method. Picture-to-picture (encoding source to display in flash player) is < 128ms on average. We have a quad core (Dell) capture server running windows 7 Pro & FMLE 3.x. We encode 25fps using VP6 at 400Kbps (no audio). We are running Wowza Media Server 2 Developer 2.1.1 build24490 on our external web-server.
The Flash Client we’ve build uses NetStream.bufferLength=0 and on a good ADSL connection we average about 22 (out of 24) fps – which is great for what we need! 
Need for Repeaters
As the demand on our Wowza server has grown we need to start using live repeaters. I’ve followed the official documentation on setting up a live repeaters.
With the original Wowza server as the repeater-origin and a new Wowza as the repeater-edge, the system works but clients connected to the edge only manage 4fps (still using bufferLength=0)!
If we turn up bufferLength (to say, 0.001) then the video player plays smoothly, however, as is the way with flash, the buffer length creeps past the 4Seconds mark, which is no use to us.
Does anyone know a way to tune the performance of live repeaters??? – I assume a buffer needs to be added somewhere but we can’t really add it to the flash player due to the way it creeps.
Any ideas?
Josh
We buffer 8 seconds of video in the server bit it really isn’t used to smooth out playback it is better to do the buffering in the player. The lowlatency repeater type is setup to forward packets from the origin to the edge more quickly at the expensive of higher cpu usage.
Charlie
They are not really related.
Flush interval is really affecting the internal workings of Wowza in the way it transfers incoming packets from the ingestion buffers to the stream list that is made available to viewers of the stream. It controls how often this transfer occurs. There is a bit of buffering going on here to increase performance of the server (avoid concurrency issues). If we flushed frame by frame then we would lock the stream list and make it unavailable to the listeners. By grouping the flushed into chunks we avoid this. If the groups are too large it increases latency.
The ReceiveBufferSize and SendBufferSize control the size of bytes of the socket buffers in the OS. The theory is that if these buffers are too large then it will also introduce latency since more bytes will be held by the OS before they are sent to Wowza. So smaller sized buffers are best for lower latency streaming. This probably increases the CPU load on a per-socket basis. That is why we suggest larger buffers for higher latency streaming (to decrease CPU load).
Charlie
What is the relation between ReceiveBufferSize and SendBufferSize in VHost.xml and flushInterval in Streams.xml (in low-latency context).
flushInterval is the interval in milliseconds in which packets are transfered from incoming buffers (ReceiveBuffer?) to the client buffers (SendBuffer?)
Does it matter to what value ReceiveBufferSize and SendBufferSize are set, as long they can hold enough data to fill x ms ( flushInterval ) of video? (depending of max bitrate used)
Or in other words, is it useful (as stated in an older thread) to define a dedicated VHost entry with small buffers for low latency use?
I don’t think the liverepeater is designed for low-latency streaming.
Richard
Are you using the liverepeater-edge-lowlatency StreamType on the edge server? There are not other other settings.
On the client-side, Flash loads about 60 frames of h.264 video before it starts playing, unless you use bufferLength = 0, as I think you understand. You just have to balance all these things out.
Richard
Hi Richard,
Thankyou for your reply.
What is the liverepeater-edge-lowlatency stream type for then?
Is there any way of adding a (for example) 100msec buffer at the repeater edge so it can more statefully deliver packets to the clients?
Josh
Hi Charlie,
Can you tell me how you achieved this?
Cheers
Josh
