Subscriber Discussion

What Made This Video So Jumpy?

JH
Jay Hobdy
•Dec 20, 2017
IPVMU Certified

Went to retrieve footage for a client that had Dahua recorders and Dahua cameras. Cameras come back over a Ubiquiti wireless network. I did not scan but they looked like the Nano Locos.

 

Using Smart PSS and playing video, this footage just jumped from the SUV at the gate to the cars outside the gate. Using the scissors, I cut the time and saved as an MP4 and original file, and got the following.

 

 

Went into Load and saw this.

 

I have to assume the 64Mb/s is the maximum bandwidth?

 

At this point, our job was to retrieve the footage. I have already advised them of these issues, but I doubt they will fix.

 

We did not install.

 

You should see the "tag" camera.

 

The good thing is they got a camera system for the property. They can check that off the list.....

Avatar
Ethan Ace
•Dec 20, 2017

That video is missing frames. What you see when it turns green is P-frames lacking a reference I-frame (which is normally not possible when there are no errors). Here's an example I grabbed at our office of this issue, looks pretty close to what you got except it's grey:

As for the time jump, I'm guessing that when the NVR exported it, it squashed all the frames it had into order and ignored the gaps. So if it's 10 FPS it crammed 10 frames into the second of video, whether that frame belonged there or not. 

What caused the dropped frames is anyone's guess without more information but I'd be completely unsurprised if it were the wireless.

(2)
(1)
UD
Undisclosed Distributor #4
•Dec 21, 2017
In reply to Ethan Ace

If possible reduce the size between two different I frames. This should decrease the "green/gray" time but increase the bps. 

JH
Jay Hobdy
•Dec 20, 2017
IPVMU Certified

The weird thing is that video is not green here. That only came up on YouTube.

 

 

UI
Undisclosed Integrator #1
•Dec 20, 2017

What transport protocol is being used?  From the video it looks like typical UDP packet loss. Tearing and pixelization are good indicators of that.  TCP packet loss will usually show the video pausing and then restarting.  I have also seen the camera itself be the cause of this type of video issue.  A firmware update fixed that particular issue so that may be the easiest for you to start with.  

If firmware doesn't fix it, best course is to take a packet capture with Wireshark at the NVR.  If you have dropped packets there move closer to the camera until you have a clean capture.  That should help identify where the problem is and isn't. 

Ethan is probably on to something with the wireless.   

(1)
U
Undisclosed #3
•Dec 20, 2017
IPVMU Certified
In reply to Undisclosed Integrator #1

 ...TCP packet loss will usually show the video pausing and then restarting. 

like it does at 0:07?

UI
Undisclosed Integrator #1
•Dec 20, 2017
In reply to Undisclosed #3

The key is the tearing and pixelization.  It doesn't look like it pauses to me. It looks more like the video looses a frame like Ethan said.  If it was TCP it would have recovered the frame before restarted since TCP is a connection based protocol whereas UDP will just drop packets with no mechanism to resend them.  

 

A Wireshark capture could determine what protocol is used.  Regardless it looks like packet loss likely across the wireless. 

 

 

Avatar
Sean Nelson
•Dec 20, 2017
Nelly's Security

Yeah sometimes the compression gets all wonky by the time it reaches youtube.

AT any rate, as far as frame loss. Have you tried to export the video right from the NVR itself with a USB stick?

UM
Undisclosed Manufacturer #2
•Dec 20, 2017

I previously worked for Fluidmesh, so I've seen a lot of wireless installs.  I would start troubleshooting your wireless.  How strong is your connection?  What else is in your spectrum?  What is the true throughput of the link?  This looks like a wireless problem to me. 

 

Then again, this is a bargain basement install from end to end, it may be really hard to nail down.

U
Undisclosed #3
•Dec 20, 2017
IPVMU Certified

Whats up with the OSD right from the beginning?

Also, I assume the timestamp was burned into the video by the camera; if so it would be interesting to see what the nvr’s timestamp would show...

Avatar
Luis Carmona
•Dec 20, 2017
Geutebruck USA • IPVMU Certified

I'd speculate the camera and/or DVR had trouble switching frame-rates if it had motion activated variable frame-rate or resolution.

I'd also suspect the wireless as wireless is always suspect. Doing a continuous PING test for an extended period of time, using the built in site survey for frequency overlap and noise and the built in speed test to see what the upper limit of the throughput was.

CR
Chad Rohde
•Dec 21, 2017
In reply to Luis Carmona

I agree with Luis. Problem starts at the Dahau 4 second pre-record mark and only lasted a few seconds. No video loss after that. This same issue has been discussed on other forums.

The built in Ubiquiti tools are decent, but you have to remember you are only testing the wireless link with those. Ethernet connection problems aren't as common compared to wireless, but they definitely happen. Check for errors in logs. Run the ping test from NVR to camera while the Ubiquiti runs the wireless bandwidth test. And if possible ping with big packets at least 1500 bytes. If you don't drop any packets doing this, it's not a network issue unless there is some intermittent wireless interference. Hard to track things like wireless gate openers......

If there was some choppy video later in the clip I would definitely blame network issues. With the limited amount of info on setup, the first things I would check is if the moisture that was present that day was causing issues for bad Ethernet connections or cable defects. The moisture could also be a problem if the wireless link is shooting through some thick foliage like I see behind the street. I'm sure it's 5 ghz which already doesn't perform well going through trees, so if you have a marginal signal in dry weather, it will usually get worse once the leaves get wet. And if this was a poor install I guess there is a possibility of them aligning the antennas shooting across street and each time a bigger vehicle passes it blocks signal. Doubtful, but I have seen way worse.

(1)
U
Undisclosed #3
•Dec 21, 2017
IPVMU Certified
In reply to Chad Rohde

 Problem starts at the Dahau 4 second pre-record mark and only lasted a few seconds. 

Uh, no.  Over a minute elapses on the osd clock in just 5 seconds of export time:

CR
Chad Rohde
•Dec 22, 2017
In reply to Undisclosed #3

I didn't even look at that for 2 reasons.

1. Youtube has the title covering that up in full screen.

2. I didn't think that much time went by.

So I checked out the video again. Of course the title is till covering most of it, but I see what you are saying. 

And at first I was gonna say the OSD clock is messed up and playing tricks on you. Because I thought the 1st SUV going through gate was the same vehicle waiting at intersection with trailer. Which means 10 seconds to open gate, 10 seconds held open, and 10 seconds to close it. So 30 seconds max.

But then I noticed that wasn't the SUV by the intersection and it could have been more than 30 seconds to get 3 vehicles and a trailer through the gate.

Sorry for my original lack of attention to detail. But to my defense that video jumping from the SUV to the Truck on the green screen matches up almost perfect.

I'm still sticking with a NVR or camera being the problem and not the network. Is this an ongoing problem or just this one time?

UI
Undisclosed Integrator #1
•Dec 20, 2017

64Mb/s may be your maximum bandwidth, but what is your maximum throughput?  I would use iperf to get a good throughput reading. This will tell you how much bandwidth you can really push through your wireless link.     

CR
Chad Rohde
•Dec 21, 2017
In reply to Undisclosed Integrator #1

If they are Nano Locos, I'm pretty sure they are only 10/100 ethernet. So 100 is max even though they could possibly connect at a higher wireless data rate. 

Without knowing the wireless stats, I would guess 50 mbps or less actual throughput. Anything more than that usually isn't consistent for those radios in outdoor environments.

(2)
New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions