We’re using Wowza on Win64 to re-stream an Axis IP camera issuing a 1Mbps H.264 live stream.
This all worked perfectly for 7 days until some very random and variable latency crept into the path from camera to server (via cable modem and mostly over Comcast backbone).
Tried adding the jitter buffer RTP properties (https://www.wowza.com/docs/how-to-turn-on-an-rtp-jitter-buffer-and-packet-loss-logging-rtp-and-mpeg-ts) but no effect. Increased rtpDePacketizerPacketSorterBufferTime to 3000ms … no effect. No packet loss recorded either.
Can …BufferTime be increased indefinitely and if so, are there corresponding changes required to tune …FlushTime ?
Do you think this is a viable strategy to overcome/hide extremely variable input stream latency or are there better methods?
Client-side Flash buffering is currently at 6s.
Many thanks,
David.
I assume this causes the clients to disconnect ? or some other issue ?
What you describe is quite difficult to overcome as if the latency does go up to 3000ms, so a 3 second delay, and it happens multiple times then any buffer setting server or client side will eventually be used up and the same issue will arise.
Shamrock
David,
It sounds like bitrate vs bandwidth issue. Try reducing bitrate by half for a test. If that makes a significant and obvious improvement, then you have to reduce your streams to a more optimal bitrate, or look into multi-bitrate streaming.
Richard
David,
If reducing bandwidth made an improvement, the problem could be limited upstream bandwidth for the encoder.
Also, for testing it would be better to use the Wowza example LiveVideoStreaming player (in the examples folder where Wowza is installed)
Richard
We’re using Flowplayer on the client side and it either spins the buffering wheel animation or keeps pausing the video for up to a few seconds.
Even though we have confirmation from Comcast and tracert evidence of extremely variable upstream delays, I am still baffled why every time I connect directly to the camera with the Axis IE plug-in, I get very good quality video playing H.264 using RTP over RTSP. None of the pauses or glitches. Connecting from a greater average latency location than the Wowza server too… relative to the camera. The suspect Comcast infrastructure is shared on both routes.
Also suspected the “next generation TCP/IP stack” on Win Server 2008 might be intolerant of such variable source stream latency but have been unable to prove this despite numerous tweaks to TCP parameters and the underlying NIC.
David.
Thanks for the suggestion Richard. I have tried the half-bitrate test before with no effect. Just tried it again… still no effect. Tried one quarter (250Kbps) and there were fewer pauses on the client end but still some. The server “bytes received/sec” graph (perfmon) was still very choppy.
There are two very distinct patterns for that incoming data plot and even at this much lower bit rate, the choppy pattern was still evident.
Here’s an example (@ 1Mbps) of the transition from a “good” data pattern to a “bad” one (RX bytes/sec in green, TX bytes/sec in red) on our Wowza server:
http://portfever.com/posts/20110126_PerfMon_2.jpg
You can clearly see how smooth a good incoming stream looks. I think the slight upward notches are the keyframe at 8sec intervals (GOV 200, 25fps).
David.
Limited (and extremely variable) upstream bandwidth for the encoder is our best assessment of the core issue. Comcast are working on a “noise issue” as I write this comment. I was just looking for possible short-term methods to hide or reduce the choppiness. Doesn’t look like there are any, other than drastic and unacceptable reductions in bit-rate.
I installed your LiveVideoStreaming player and in this instance, it behaves exactly the same as Flowplayer when run side-by-side. Pauses in the same spots.
David.
