No Delay RTSP streaming

[centralalarms 0]

I am trying to get a zero delay RSTP stream from Dahua ip cameras and NVRs and haven't been able to figure it out. I am on a local LAN and the video is realtime 30fps 1080p, but there is a 1-2 second delay between real world action and RTSP video. The video use the web service or PSS is without delay and terrific, but for my use I need the RTSP stream. I am testing in VLC.

 

Does anyone here have any ideas or done this before?

 

Also is there a way to tap in to the 37777 stream, as it seems to be without delay.

[TheUberOverLord 0]

I am trying to get a zero delay RSTP stream from Dahua ip cameras and NVRs and haven't been able to figure it out. I am on a local LAN and the video is realtime 30fps 1080p, but there is a 1-2 second delay between real world action and RTSP video. The video use the web service or PSS is without delay and terrific, but for my use I need the RTSP stream. I am testing in VLC.

 

Does anyone here have any ideas or done this before?

 

Also is there a way to tap in to the 37777 stream, as it seems to be without delay.

Yes, here is the issue most likely.

 

Generally RTSP will try using UDP first. In many cases that will fail and then after failing RTSP will fall back to using TCP instead. To avoid this and any delay associated with it and use TCP from the start. Without first trying UDP. Try these:

 

ffmpeg -rtsp_transport tcp -i "Your RTSP URL in between these double quotes"

 

VLC Add this parameter to the VLC RTSP VLC command line:

 

--rtsp-tcp

 

Some say you can also use ?tcp with the Dahua RTSP URL as well that will force the camera itself to use TCP or via a NVR.

 

Not sure I buy into this. But it maybe worth trying.

 

Issue is, that you need to check several of these below. Not just one. Because they all suggest doing it a little differently in the RTSP URL and I can't find any official Dahua example RTSP URL with a ?tcp or &tcp in it:

 

https://www.google.com/?gws_rd=ssl#q=dahua+rtsp+?tcp&spell=1

 

Maybe one or more uses of ?tcp or &tcp in the RTSP URL really does and can work with Dahua IP Camera in the RTSP URL?

 

Don

Edited March 14, 2015 by Guest

[centralalarms 0]

@TheUberOverLord I am impressed. Thanks!

 

I will test this tomorrow and update the thread.

[centralalarms 0]

Another thing, I heard that the Ambarella DSP vs TI DSP handle RTSP differently. A distributor in the US told me that the ambarella dsp offer three streams, where the third stream is geared for rtsp use in access control and other 3rd party systems. Those streams are optimized for realtime, may be they are tcp forced from the start.

[TheUberOverLord 0]

Another thing, I heard that the Ambarella DSP vs TI DSP handle RTSP differently. A distributor in the US told me that the ambarella dsp offer three streams, where the third stream is geared for rtsp use in access control and other 3rd party systems. Those streams are optimized for realtime, may be they are tcp forced from the start.

You are very welcome.

 

Most IP Camera brands and models that use Browsers with plugins and offer mobile device apps. Use a proprietary video/audio stream format that is not published for those interfaces. The issue is that proprietary format is not using RTSP and to access it. Most likely you would need to create/write a program to do so.

 

Because of the above. One can't compare the RTSP delay with any proprietary video/audio format not having a delay. Since it's comparing apples to oranges.

 

But what I mentioned in my prior post, for sure does happen and not just with Dahua IP Cameras but many different IP Camera brands and models when using RTSP.

 

This is why many Media Players like ffmpeg, VLC and others have command line parameters to force TCP to skip this try UDP first then try TCP after failing UDP delay. Which is not IP Camera brand/model specific and applies to RTSP in general for those Media Players.

 

Don

[centralalarms 0]

The --rtsp-tcp in vlc and ?tcp in the url made no difference.

 

How do I run this command? ffmpeg -rtsp_transport tcp -i "Your RTSP URL in between these double quotes"

is it for linux or also possible to run it with the windows version?

[dvarapala 0]

FWIW, on a LAN it probably matters little which transport (TCP/UDP) you use. You probably have a gigabit of bandwidth, and full-duplex links between each camera and the switch hence no collisions or packet loss. What's undoubtedly causing the delay you're seeing is the CODEC. CODECs like H.264 minimize network bandwidth by doing lots of processing, and each stage of that processing requires buffering, which adds noticeable latency.

 

This is why I always prefer MJPEG streams over H.264 when the camera gives me a choice. Bandwidth is not an issue on my dedicated gigabit LAN, and the latency with MJPEG is minimal. On my Hikvision cameras, which don't offer an MJPEG option at 1080P resolution, There is a noticeable delay of 2-3 seconds between the Hiks and my MJPEG cameras.

 

If the latency bothers you, try switching your cameras to MJPEG mode.

[MaxIcon 0]

That should help, but may be problematic on Dahuas. Last time I tested a Dahua on MJPEG, the video looked like Warhol filmed it on acid. They may have fixed that by now!

[dvarapala 0]

Last time I tested a Dahua on MJPEG, the video looked like Warhol filmed it on acid. They may have fixed that by now!

 

If not, the OP can always buy an Axis.

[centralalarms 0]

The delay on dahua cameras using mjpeg or h264 is the same, or even worse in mjpeg mode when using rtsp.

 

Can you confirm there is no delay with axis cameras? I guess they also have a http video stream?

[mobbarley 0]

The delay on dahua cameras using mjpeg or h264 is the same, or even worse in mjpeg mode when using rtsp.

 

Can you confirm there is no delay with axis cameras? I guess they also have a http video stream?

 

 

delay is approx 150ms-250ms with most axis products

[centralalarms 0]

The delay on dahua cameras using mjpeg or h264 is the same, or even worse in mjpeg mode when using rtsp.

 

Can you confirm there is no delay with axis cameras? I guess they also have a http video stream?

 

 

delay is approx 150ms-250ms with most axis products

 

Can you clarify whether the stream is over http or rtsp?

[40th Floor 0]

Toshiba ikwb15 is ready in 20 ms from start at client to server and back to client. Blows everything else away.

 

The critera is not well defined. Delay as seen on the screen versus real life (like waving your hand), or/and delay before something appears on screen (like waving your hand, but nothing appears until the second hand wave, or third, or), or what. The first can be from the serving (camera) but much more likely is at the receiving (viewing) side. The second could be the either, or, both. Disable authentication. Don't use ssl.

 

The first case (wave hand versus see hand wave time difference) is the only real problem. Good luck with that. I'd say RTSP it not a significant contributor to delay (case #1 delay). The decoding process (typically designed from non-realtime streams, like movies) is by far the worst. Some streams decode forward, too, and you have to wait to decode those before you display what you may have already received.

 

Anyway, ikwb15, 0.02 secs and it's there. It uses an Axis ASIC. From 10 years ago. Made by TopView. Quality stuff. Except for the dome. But then all domes are junk.