Real Time Streaming Protocol (RTSP)

@minnix,

Check to see if you select RDP/UDP (or RDP/Unicast) on your Remote Method selection and use that. Note that my cams do not have access to the internet (have two network cards in same computer, with different IP addresses and cam network card has no gateway).

https://zoneminder.readthedocs.io/en/stable/userguide/definemonitor.html

Had the same problem on Blue Iris until I selected RDP/UDP and assigned a different port to the two I have (7100, 7200) and it’s been running 24/7 for several days (using the first V2 beta version). Note however, if I make a change via BI dialog for the camera, it looses the signal and I have to unplug/plug the AC on the cam.

Is UDP better for RTSP? I have a lot more visual artifacts appearing in my videos when I use UDP over TCP. If I was multicasting I get the benefit of UDP, but unicasting the overhead seems minimal and the quality appears much better (in my case anyway, I cant go more than about 10 seconds of video before compression error type pixellation / bleeding occurs).

TCP has a lot of overhead with a three-way handshake setup and teardown. UDP has no acknowledgment of data packets received and will drop packets received out of order, etc. TCP for live Video and VoIP can suffer from high latency and be choppy as it will wait for a missing or late packet. This can lead to more issues with the extra overhead in bandwidth use than the occasional dropped packets of UDP. TCP is good for routing and control like PTZ where you need confirmation of an action.
What RTSP does by specification is a combination of both.

RFC 2326
Reliability and Acknowledgements

Requests are acknowledged by the receiver unless they are sent to a multicast group. If there is no acknowledgement, the sender may resend the same message after a timeout of one round-trip time (RTT).
The round-trip time is estimated as in TCP (RFC 1123) [18], with an initial round-trip value of 500 ms. An implementation MAY cache the last RTT measurement as the initial value for future connections.

If a reliable transport protocol is used to carry RTSP, requests MUST NOT be retransmitted; the RTSP application MUST instead rely on the underlying transport to provide reliability.

If both the underlying reliable transport such as TCP and the RTSP application retransmit requests, it is possible that each packet loss results in two retransmissions. The receiver cannot typically take advantage of the application-layer retransmission since the transport stack will not deliver the application-layer retransmission before the first attempt has reached the receiver.

If the packet loss is caused by congestion, multiple retransmissions at different layers will exacerbate the congestion.

1 Like

Thanks. Looks like my problems were resolved by the commit I mentioned in the new version of Home Assistant though. I even bought and added another two Wyzecams and it’s all sitting up rather nicely now.

It hasn’t turned off on me again since that first night. Beta2 has been more stable than Beta1 (Beta1 has been pretty reliable for me as well).

I’m happy to help - just let me know what information you’re looking for.

Sorry - I’m not sure what link you’re looking for. Those firmware numbers are what I had installed on my 3 cameras.

2 of the cameras are running Beta2 and 1 of them is still on Beta1 (I need a ladder to get to that one so I’ll just wait until the final release of the RTSP firmware before updating that one).

When you say assigned a different port… Is this just within BI? I thought the RTSP feed was locked to 554? I do wonder if these cameras are somehow impacting themselves. Using the commonly discussed means to add these cameras to to BI, I see patterns where all my 4 V2 cameras drop at the same time with seems a bit coincidental. The drops got bad enough, I have just shut it all down until I get some answers as I was spending too much time trying to keep it all up and running.

true, but then doesnt it depend on what the purpose of the live video is?

if my purpose is to record motion events and have a reliable video that I can use to identify someone, then retransmission of errors that could otherwise result in visual artefacts might be preferable…?

if I want a live stream that is uninterrupted and always live, even if data is missing, then UDP would be better because it would never lag and just drop error packets.

i guess the question is, how much would a camera be able to lag on TCP before the software does some sort of correction / time synchronisation and just cuts a hole in the video?

and what could I tweak in my software to try and reduce the visual artefacts I am seeing while using UDP (since I would use that if it didnt look crap).

Once I got home yesterday I found that my computer was completely off as well and I never shut it completely down. I think i must have lost power briefly. I unplugged / re-plugged the wyze cams and they fired back up. I will keep an eye on this, but I think this is just a side effect of intermittent power blips.

Is there a log an user can pull when the RTSP disconnects requiring reboot? Was working fine for few days then no more. Reboot through App fixed it. When RTSP stops, app shows cameras just fine.

Had one V2 Cam + Older Firmware and another V2 Cam + Beta v2 firmware. Both went dead regardless of firmware.

Before I reboot to get RTSP going again, was wondering if there was log we can take a look or send to Wyze for investigation.

Thanks.

Series of stills, merged using ffmpeg - more granular control for me.

Yes, BI allows you to change the RDP/UDP port:

Thanks for the info. I am still seeing frequent drops, but this is trending in the right direction. I see some mentioning of issues on mesh networks and such, so that might be the culprit as well. Thanks again for the assist. I think we’re getting close to a stable feed…

I have been having very frequent drops until I disabled this setting on my Netgear Orbi router.

“Enable WMM (Wi-Fi multimedia) settings” << specifically for 2,4 GHz as that is what these cameras use.

I got here by researching various issues, but this article helped.
https://routerguide.net/airtime-fairness-on-or-off/

I still drop, but less frequent and the connection doesn’t drop all together. Still testing, but this is the first real headway I have made in weeks.

1 Like

@madtaurus would you mind sharing your configuration for iVideoN and tell us how the performance has been? I tried iVideoN on Linux but the stream seemed to freeze after about 20secs and doesn’t auto resume.

@blaze4fun what are your conclusions using Wyze RTSP with iSpy? Have you been successful and satisfied to this point?

@lxsharpxl How is this holding up for you and what NVR software are you using?

Configuration is pretty easy using iVideon. I simply just put in the RTSP URL as it is showing in the app, into the iVideon Server configuration.

Regarding performance, it is a bit of a mixed bag. I have had a few times where I’ve had to restart RTSP or restart the camera, in order to have iVideon be able to do any detection. During these times where it isn’t working, the wyze app is still giving notifications.

@madtaurus thanks for the feedback. What OS are you running iVideoN on? As mentioned, I’ve tried it in Linux and the feed won’t stay up for even a couple mins before freezing.

I’m on win10 pro. Running it on an i5-4670k non over clocked and 16gb ram. Os is on an SSD and the recordings are to a WD Green 4TB.