TOP-201 Tiny IP Cam RTSP Connection Issues

[LittleScoobyMaster]

I've had this camera for many months now and it works great with the built in live stream from the web page. It even works really good with CMS. Never drops a frame with those two methods.

Whenever I connect with other pieces of software, I always get rtsp timeouts and connection drops. I've tried Geovision's GV-NVR, Onvif Device Manager, VLC Media Player. Same issue with all of them. Stream looks great for a minute or two, then disconnects every minute or two for as long as I view the streams. The disconnects last from a few seconds to a full minute.

The Top-201 forum on this sight mentions a few things to try.

The three main items I've tried were the following:

1. Use a different default RTSP port. I tried using port 555 instead of the default 554. Same issue.
2. Latest Firmware. Same Issue.
3. Adjusting the frame rates, bit rates, constant versus vbr, etc. Same Issue

I've read that UDP can be more forgiving for RTSP IP camera streams as the data doesn't always get resent for error correcting or something similar to that.

Anyone know how to change this camera to use UDP instead of TCP?

I've read on other RTSP sights that sometimes, the client software can send a keep-alive heartbeat back to the camera or the camera can send one to the client software, don't recall which. Anyway, if the camera or the client software doesn't receive a heartbeat, it's my understanding that perhaps a connection drop may be the result.

Is there a way to do that with this camera? Check the heartbeat, change the setting, make it not required, etc.

Also, if you view the camera stats using Onvif Device Manager, and you select Profiles, and then Video Encoder Configuration, you can see an option called 'Session Timeout: PT10S'. Does this setting have anything to do with the RTSP connection, and does it mean 10 second timeout, or can this setting be changed from anywhere? thanks

 

[nayr]

you got it backwards, TCP is more forgiving.. UDP is not.. the web browser will default to TCP by default, most other stuff like VLC will default to UDP by default.

setup a firewall rule to block udp traffic on the rtsp port, that usually forces all clients to fallback to TCP.

never heard of a heartbeat on a stream, the client knows if its getting data or not.. that seems silly.. iframe perhaps?

usually if you are having problems with UDP traffic its a sign of a network issue, switching to TCP just hides the underlying issue.. but it does not get rid of it.

 

[LittleScoobyMaster]

you got it backwards, TCP is more forgiving.. UDP is not.. the web browser will default to TCP by default, most other stuff like VLC will default to UDP by default.

setup a firewall rule to block udp traffic on the rtsp port, that usually forces all clients to fallback to TCP.

never heard of a heartbeat on a stream, the client knows if its getting data or not.. that seems silly.. iframe perhaps?

usually if you are having problems with UDP traffic its a sign of a network issue, switching to TCP just hides the underlying issue.. but it does not get rid of it.

Thanks.

I was seeing the UDP item from this link. Some users started getting solid connections when switching to UDP.

http://www.bensoftware.com/forum/discussion/641/camera-loses-connection-and-reconnecting-every-minute/p1

It's a different cam and such but some people seemed to really think UDP could help.

"Unfortunately UDP is an inherently unreliable protocol, as it does not guarantee delivery of the data packets. It's designed for live video streaming, where dropping packets is preferable to delaying the video stream. If there is any temporary network problem or bandwidth restriction (e.g. another device is using a lot of network bandwidth), then some UDP packets could be dropped, which results in the green images you are seeing."

That's what I'm hoping to do, drop the frames without severing the connection. I'm hoping to get video artifacts versus connection drops of long periods of time. UDP is supposed to provide that. Like it ignores connections and just keeps sending the data willy nilly and with artifacts. Because of my less than rock solid connection, that would seem preferable.

I do have some issues with network connections because I'm using a sad ethernet powerline adapter kit. And I'm looking to just ignore connection drops somehow. I think VLC defaults to different items based on the version from what I have seen. Although, the only reason I'm using VLC is for testing. If I can get VLC or Onvif Device manager to get a solid rtsp stream, I figure it could give me insight in how to get it solid via Geovision GV-NVR.

With my other cameras, on the same ethernet powerline connection, they never have an issue. They just ignore any connection issues. Most I get would be a quick camera frame stop for 1 second or so, not a full disconnect lasting up to a minute like what I get with the Top-201.

I've tried every iframe setting allowable (2 through 12) with the Top-201 previously. No luck with that setting.

This is on the local lan, not using the firewall, straight to the main network switch (albeit going through ethernet powerline adapters). Not using the internet at all. But I could rig it that way for testing perhaps.

Similar powerline adapter
http://www.amazon.com/TP-LINK-TL-PA4010KIT-Powerline-Adapter-Starter/dp/B00AWRUICG

I haven't tried connecting directly to the Top-201 yet because its a real pain in the *** hardware location where I have it and I can't run a cable there without a bunch of inconvenience, and if I even bump the hardware, it will knock another camera out of view and it's held up with, well, it's like a house made of cards if you can visualize that (one wrong breath and 2 cameras have to be re-adjusted, shadow masks updated, etc, etc.), but since the other cameras work with the same powerline connection, I'm really hoping to get the Top-201 working as well. I know I should rule out powerline, but I've had no issues with powerline adapters and about 6 different IP cams, only the Top-201 gives me the trouble so far, and only with 3rd party software.

Oh, and there is another switch on one of the powerline adapters as well, the powerline adapater connects to the AC, and then through the switch so it can service 3 IP cams at once.

I've eliminated the switch for testing purposes but it didn't change anything so I put it back even though I know extra switches can cause latency. But, like before, the other cams handle this hodge-podgery nicely. Hoping TOP-201 can as well. But yeah, I do need to work on the hodge--podgery items.

Also, this TOP-201 works stellar over this very same hodge-podgery....if I use the built in web page for live view, or CMS. So, if those 2 items can do it, I'm hoping that GV-NVR can do it as well. The stream I get with the other 2 methods is near perfect even with the craziness going on.

 

[nayr]

when you get that full disconnect lasting up to a min, can you see the stream uninterrupted on the webUI? thats the symptoms of a camera locking up and triggering a watchdog reboot.. open a continuous ping to the camera and see if you document any packet loss.

tcp will actually hold onto a bad connection longer, it will just increase the latency.. whereas udp will fall apart and disconnect sooner.. too many dropped packets looks like a dropped connection and there is no timeout on udp... you have to go a long time w/out data before TCP kills the connection, typically like 15mins if the other side just disappears without getting a socket close.

a shit load of video issues go away with switching from UDP to TCP when you have network issues, it dont work the other way arround.. UDP only works for video on an ideal network.. its not tolerant of any faults.. but it is lower latency than TCP so its preferred for video by most clients.

 

[LittleScoobyMaster]

when you get that full disconnect lasting up to a min, can you see the stream uninterrupted on the webUI? thats the symptoms of a camera locking up and triggering a watchdog reboot.. open a continuous ping to the camera and see if you document any packet loss.

tcp will actually hold onto a bad connection longer, it will just increase the latency.. whereas udp will fall apart and disconnect sooner.. too many dropped packets looks like a dropped connection and there is no timeout on udp... you have to go a long time w/out data before TCP kills the connection, typically like 15mins if the other side just disappears without getting a socket close.

a shit load of video issues go away with switching from UDP to TCP when you have network issues, it dont work the other way arround.. UDP only works for video on an ideal network.. its not tolerant of any faults.. but it is lower latency than TCP so its preferred for video by most clients.

1. Use a different default RTSP port. I tried using port 555 instead of the default 554. No Change
2. Latest Firmware. No Change
3. Adjusting the frame rates, bit rates, constant versus vbr, etc. No Change
4. Iframe settings (2 through 12). No Change


When the full 1 minute disconnect occurs, the stream is perfectly fine on the Top-201 webUI, no frames drop. During the 1 minute rtsp drop, ping times remain consistent between 2ms and 9ms, TTL=64. Ping never drops during the rtsp outage. (no ping timeouts).

Does the TOP-201 allow you to change from TCP to UDP or vice versa? Couldn't find that setting on the WebUI.