Hi Everybody.
I’m trying to get the latency down on my RTP -> flash stream. In the player I set NetStream.setBufferTime(0), and am using rtp-live-lowlatency on the Wowza side. It plays fine at first, then after a few minutes it starts this really strange stuttering. I would expect if this was a bandwidth issue it would just freeze and restart, but it is like the frames become out of sequence. The picture rapidly jumps back and fourth in time, no more than a second or so. Also, when I open another browser window and view the same stream concurrently, it looks fine in the new window, while still going crazy in the original one. This tells me that the video is getting into Wowza from my encoder fine. The problem randomly clears up and gets worse again.
Anyone have any ideas?
Running with zero buffer can cause these types of problems. What is the source of the video. Does it included B-frames? I would suggest you only do this if the video is H.264 baseline and nothing higher.
Charlie
This is the problem with the Flash player and H.264. I have not found a way around it. It is either no buffer and not great frame rate or a little buffer and 2-3 second delay.
See if this patch helps. It does include a config fix for rtp-live-lowlatency:
WowzaMediaServerPro1.7.0-patch6.zip
Charlie
It is much more of a player issue. The only other thing to try is to edit [install-dir]/conf/Streams.xml and change the definition for the live-lowlatency stream type. Change the flushInterval to a number like 25. This might help a little but that is the best we can do.
Charlie
A lot is going to depend on the encoder. Best setting are streams/streamtype set to live-lowlatency and in your player code set the netstream.buffertime to zero. The buffer time setting of zero is not always best for smooth playback.
Charlie
I am not sure what you are asking. I think it all matters. The live-lowlatency stream type gives you the lowest latency server side (about 30-60ms). The 60 frames per second I think helps as well. Then the Flash player will play the frames immediately if the NetStream.setBufferTime is set to zero.
Charlie
I believe the test was run on a local network. So that might also contribute to the better results.
Charlie
This sounds right. I would try lower numbers since you want wowza to send the video frame by frame.
Charlie
I believe they were running at 60 fps and NetStream.bufferTime set to zero with the stream type set to live-lowlatency.
Charlie
It is a known issue with the Flash player. Any NetStream.setBufferTime greater then zero will result in 2-3 seconds of latency. I believe the 400ms was achieved with NetStream.setBufferTime to zero, live-lowlatency stream type and a frame rate of 60 frames per second.
Charlie
One more thing to try. Edit conf/Streams.xml and change the definition for the live-lowlatency stream type. Change the flushInterval property to 15. That should push up the frame rate when the NetStream.setBufferTime is set to zero. This will increase the CPU needed for each stream. So you will not get as much out of a given server but it should help drive the frame rate up.
Charlie
I read this news -
http://news.techex.co.uk/news/industry-news/4-haivision-and-wowza-team-to-deliver-worlds-fastest-flash-hd-h264-live-content-delivery
where it claims that end-to-end delay can come to 400ms. I am wondering about the player settings that are involved to achieve this. If it works that way, then it would be amazing.
Thanks for you reply. I do understand that a lot is going to depend upon the encoder but I cant imagine the encoder taking more than 300-400ms of latency on a good computer (or let’s just assume that encoder is working that way - FMLE on a quadcore can do a decent job).
But as you said, client side buffer of zero is not recommended and is not smooth (which means it’s basically not usable). Once you set any sort of buffer, I believe Flash Player by implementation buffers 64 frames (no idea why) to play H264 content - which often means 2-3 seconds of delay at the client itself.
I was just curious how 400ms of end-to-end delay was claimed - is it just a special setup or I am curious if there is anything else on the client/server (leaving out the encoder) that we can do to make it better. It would add a tremendous value if the latency is brought down to anything comparable to these claimed levels (less than a second) - no doubts there
Any takers for this question ?
libx264 is doing the encoding. No b-frames, but it isn’t quite baseline, because it is doing CABAC.
I’ve found that when I increase NetStream.setBufferTime to anything above 0, the latency increases by at least a few seconds.
I’ve installed the patch and am streaming… So far, So good. I’ll let you know how it goes.
The stream I have been working with is 750Kbps @ 30 fps
Nope. Still having artifacts. Darn. I can send you a movie of it if you would like to see.
I have the same issue.
When I set netStream.bufferTime=0 in the player I get 0.8s latency
but with about 14 fps.
If the netStream.bufferTime=0.1 (or above) the latency is about 3-4s
and frame rate is 25fps.
I use rtp-live-lowlatency stream type and an RTSP stream as a live source,
H.264 encoding, 25fps with 2CIF resolution.
I tried Wowza 1.7.2 and Advanced 2 (Prview 6). Both have the same issue.
I wonder if this is a general issue or a specific to my encoding or RTSP source?
So I am very interested how they achieved 400ms latency with H.264 ?
What does it mean?
that this doesn’t happen with the stream type live-lowlatency ?
or does it help to have 60fps, which are then dropped to about 35 fps, which is still good enough ?
I am talking about the frame rate drop (to ~14fps) when using rtp-live-lowlatency and bufferime=0 on H.264 25fps stream to achieve 1s latency. If bufferTime is >0 then frame rate in the player is normal (25fps), but the latency is >3s.
So then I wonder if Haivision doesn’t experience the same problem as I doo with frame rate drop on bufferTime=0 (which they obviosly should use).
Then you say (Charlie) that Haivision uses 60fps and live-lowlatency stream type to achieve 0.4s latency (without stuttering I guess).
So then I wonder what helps to prevent stuttering. Either live-lowlatency stream type instead of rtp-live-lowlatency or the 60fps stream?