advice on lowering latency with gstreamer

[Art_Vanderhoff]

I am hoping someone can give some advice on lowering the latency of a

through put.

I have a stream coming from a RTSP camera and re-streaming it with a wowza2

server.

If I pick up the feed directly with wowza2 and re-stream it gives approx. 1.7

sec latency.

I would like to use gstreamer to add some overlay, however the best I can

get using the below is 3 seconds.

camera into wowza

-> camera direct into VLC with 50ms rtsp-cahce = <200ms

-> camera -> conf/live-lowlatency -> VLC with 50ms rtsp-cahce = 1.7sec

-> camera -> conf/live-lowlatency -> examples/simplevideostreaming.swf with buffer(0) = 3 sec (expected given 60fps limit?)

camera into gstreamer or VLC into wowza

-> camera -> gstreamer -> conf/live-lowlatency -> VLC with 50ms rtsp-cahce = 3 sec

-> camera -> gstreamer -> conf/live-lowlatency -> examples/simplevideostreaming.swf with buffer(0) = 4 sec

Also if I use VLC as the source doing the same camera it is about the same latency

I have tried to establish where the latency is coming from with no luck so

far.

Any help you cpould give is appreciated,

Thx

Art

Inbound stream 640x352 25fps H264 (part-10)

Debian AMD64 squeezy

gst-launch-0.10 version 0.10.35

GStreamer 0.10.35

Wowza 2

live-lowlatency

<StreamType>live-lowlatency</StreamType 
also tried
<StreamType>rtp-live-lowlatency</StreamType>
with same result
other settings
<LiveStreamPacketizers>cupertinostreamingpacketizer, smoothstreamingpacketizer</LiveStreamPacketizers>
<Properties>
				<Property>
				<Name>sortPackets</Name>
					<Value>true</Value>
					<Type>Boolean</Type>
				</Property>
				<Property>
					<Name>sortBufferSize</Name>
					<Value>500</Value>
					<Type>Integer</Type>
				</Property>
				<Property>
					<Name>flushInterval</Name>
					<Value>25</Value>
					<Type>Integer</Type>
				</Property>
</Properties>
<HTTPStreamers>cupertinostreaming,smoothstreaming</HTTPStreamers>	

gst-launch gstrtpbin name=rtpbin uridecodebin
uri="rtsp://192.168.20.40/channel1"  buffer-duration=1 buffer-size=1 
name=decode decode.  ! queue !  ffmpegcolorspace ! videoscale ! queue !
capsfilter 
caps="video/x-raw-yuv,width=640,height=352,framerate=(fraction)25/1" !
x264enc bitrate=500 cabac=false pass=qual quantizer=27 subme=4 threads=0
bframes=0 dct8x8=false vbv-buf-capacity=100 ! queue ! rtph264pay ! queue !
udpsink host=0.0.0.0 port=50000

----SDP----

note that profile-level-id is depreciated and does not print out in verbose mode - could this be a problem?

v=0
o=- 1208520720 2590316915 IN IP4 127.0.0.1
s=MYPIPE
i=N/A
c=IN IP4 0.0.0.0
t=0 0
m=video 50000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 media=video; clock-rate=90000; encoding-name=H264;
sprop-parameter-sets=Z01AFtkAoD2wEQAAAwABdzWUAA8WLkg=,aMvFyA==
a=control:trackID=1

[Richard_Lanham]

1.7 seconds is pretty good. If you are going to add an overlay, that will add latency of course. Are you using the LiveStreamPacketizers? If not, make that empty to save a little overhead, tho not sure that will translate to lower latency. Have you seen this article:

https://www.wowza.com/docs/how-to-set-up-low-latency-applications-in-wowza-streaming-engine-for-rtmp-streaming

Richard

[Charlie_Good]

If we don’t have sprop-parameter-sets we can get it from first key frame if contain SPS and PPS information. We can extract profile-level-id in the same manner. If

sprop-parameter-sets information exists I believe we can extract profile-level-id from this information.

Charlie

[Charlie_Good]

We do not log the profile-level-id info. This will most likely not reduce latency.

Follow the instructions in the article Richard provided above. It is the best way to reduce latency. Also, be sure to encode streams without B-frames. You should be able to drive latency down to less than a second.

Charlie

[Richard_Lanham]

Arti,

Take a look at this example:

https://www.wowza.com/docs/how-to-use-imediastreamactionnotify2-to-monitor-live-streams-modulestreamwatchdog

Richard

[Randall_Auriemma]

“how to monitor when the first packet leaves the source encoder”

You could use a packet sniffer. In Linux there’s tcpdump which can be scripted. Or Wireshark if you prefer a GUI.

[Art_Vanderhoff]

Hi Richard,

Agreed 1.7 would be fine, that is for the camera direct, the problem I have is another 1.5 secs being added just by going through gstreamer or vlc.

Could this be due to wowza needing some header info not contained in the sdp or other files?

I noted that in another thread that wowza requies sprop-parameter-sets or has to look find it itself, is this the same for profile-level-id?

thx

Art

[Art_Vanderhoff]

Thx for taking the time to reply Charlie,

so do you think if I could find that profile-level-id and add it to the sdp it would decrease the start up latency or is it a quick thing for wowza to process.

If so is there any way to log/export this information from wowza. I could then prcess the log and add it to the sdp, stop and restart the stream.

I am still stumped as to what could cause this amount of latency through the pipeline. I assume that wowza is processing and through putting quite quickly and the actual decode/encode in gstreamer is also sub 300ms. That leaves the negotiated hand off between the two.

Any thoughts or wacky suggestions on things I could look for?

Could the 64bit architecture be affecting this in some way?

Thanks to both of your for your advice.

[Art_Vanderhoff]

Thx Charlie,

We have followed that guide and still the problem persists. We are trying to analyse if the internal pipes in the encoders are causing any buffering delays.

Can anyone suggest any tools on how to monitor when the first packet leaves the source encoder and when wowza would rcv it? Ideally we should also archive these packets for inspection to ensure all header info and the correct formation of the first key frame.

Thx Arti