Skipped Frames on MD/IVS/Alerts while recording to on-camera SD card

[Mike Mo]

@aristobrat @nayr @EMPIRETECANDY

I know this has been discussed on the thread regarding the NVR.

I just received my cameras the other day, I was doing some bench testing.

I set up two cameras (IPC-HW5231e-z5) as LPR, I set up intrusion zones on one camera, and ordinary motion detection on the other camera.

The cameras were set to record to just local storage on the SD card. No NVR hooked up. Settings were record continuously, and also record on event, and store snapshot. The recording was strictly done on the camera's SD card. I used Samsung Evo select 128gb cards.

When I logged directly into the camera or use SmartPSS to review the recorded video, I get the same frame drop out/ stutter that other report on their NVR recordings.

Sorry having a hard time converting the DAV file. Tried Smartplayer on my Mac, but the avi it exported is not readable. Fileconvert doesn't work on my mac (using macos sierra).

Essentially, there is a stutter and then the car suddenly appears half way through the scene. This happens pretty much on every event that is detected. The only time when it doesn't occur is when the event is triggered way in advance by some high beam lights so that by the time the car makes it into the scene, the stutter had already occurred by the high beam lights triggering the event.

So while the camera works great to capture the license plates. The IVS or even just plain motion detection is a huge problem.

I'll try and get some other examples, and will work out how to post them later.

 

[aristobrat]

Ah, sorry to hear. Was hoping the cameras did it a different way.

 

[weigle2]

It looks like the dropped frames, is really a problem more with the camera itself. Not so much, the NVR. The NVR is just recording what the camera sends it.

 

[aristobrat]

AFAIK, at least with H.264/H.264, cameras only send iFrames (frames with complete pictures) every so many frames.

The frames sent between the iFrames only contain partial pictures...

That's normal, so I don't think this is a camera issue.

Sounds like Dahua has programmed their systems to start recordings with whatever the current frame sent by the camera is. If that happens to NOT be an iFrame (which is almost always the case with my NVR), that leads to a recording that is going to playback glitchy.

I'd think that they'd be able to keep the previous 60 or so frames in a buffer, and be able to back up to the last iFrame sent when they start a recording.

Or how about just don't create separate recordings for IVS/Motion Detection events? Just keep track of the times when the camera said these events started, and show these times as markers on the timeline. AFAIK, that's what Blue Iris does. Motion Detection events are just basically "bookmarks", not separate files.

 

[aristobrat]

@Crazykiller came up with a cool workaround:
#326

He has his cameras set to record continuously, and for IVS/MD events, to take a snapshot. If you use SmartPSS to look at the snapshots, you can click the Video button, and it will move you right to your video timeline where the IVS/MD event occurred. That sounds kind of cool.

 

[Mike Mo]

@Crazykiller came up with a cool workaround:
#326

He has his cameras set to record continuously, and for IVS/MD events, to take a snapshot. If you use SmartPSS to look at the snapshots, you can click the Video button, and it will move you right to your video timeline where the IVS/MD event occurred. That sounds kind of cool.

Yes, that was the next thing I was going to try.

 

[Mike Mo]

I also may try and see what happens if I just record events alone and not continuously and events simultaneously on the same device. I want to see if the issue is in starting a new file while one is already active or whether the issue is in the recording of the event itself.

 

[aristobrat]

I also may try and see what happens if I just record events alone and not continuously and events simultaneously on the same device. I want to see if the issue is in starting a new file while one is already active or whether the issue is in the recording of the event itself.

I'm trying that on one of my cameras too. I set the pre-record to 10 seconds, so hopefully even if the problem persists, it happens early enough in the video, before the action part starts. This might turn out to be a workaround also, but since IVS and MD sometimes misses stuff, I'd still prefer Dahua fix this so that continuous + IVS/MD recordings both can be done.

 

[Crazykiller]

I also may try and see what happens if I just record events alone and not continuously and events simultaneously on the same device. I want to see if the issue is in starting a new file while one is already active or whether the issue is in the recording of the event itself.

Well, I'm waiting for my 5231's to be dispatched. I thought it might be the SD card or maybe the consumer model camera (HFW1320S-W). I've got same issues before I had my NVR and was MD recording to SD card. If I turn on snapshots to SD in addition I have some glitches in the recordings on the SD.

 

[Mike Mo]

I'm trying that on one of my cameras too. I set the pre-record to 10 seconds, so hopefully even if the problem persists, it happens early enough in the video, before the action part starts. This might be a workaround also, but since IVS and MD sometimes misses stuff, I'd still prefer Dahua fix this so that continuous + IVS/MD recordings both can be done.

I agree would be great to get a fix on this.

I am not sure why they Dahua can't just time stamp and color code the timeline of the continuous recordings when motion/IVS/alarm events occur, rather than creating a whole new file. That would seem to solve the dual recording problem. I guess that is how the snapshot workaround kind of works.

Obviously, if the issue persists when only recording events and not continuous and events then that is a different story.

 

[c hris527]

It looks like the dropped frames, is really a problem more with the camera itself. Not so much, the NVR. The NVR is just recording what the camera sends it.

That is a good theory, we have a lot of BI users here that use Dahua Cameras and do not have the issue.

 

[Mike Mo]

That is a good theory, we have a lot of BI users here that use Dahua Cameras and do not have the issue.

Or the reuse the same deficient code when recording directly to the camera or the nvr.

 

[aristobrat]

That is a good theory, we have a lot of BI users here that use Dahua Cameras and do not have the issue.

The BI help file (below) specifically mentions this issue and how to avoid it. Wish Dahua would read it. lol

Dahua is starting recordings before the arrival of a key-frame (iFrame)... on both its NVR and cameras, which makes me think this would be a big issue for them to fix.

Also, recording must begin at the arrival of a key-frame (complete image). If your camera sends these only infrequently, you may miss the beginning of some motion-activated recordings unless you also use the pre-trigger video buffer.

 

[mp3lll]

can you show video of the issue?

 

[c hris527]

The BI help file (below) specifically mentions this issue and how to avoid it. Wish Dahua would read it. lol

Dahua is starting recordings before the arrival of a key-frame (iFrame)... on both its NVR and cameras, which makes me think this would be a big issue for them to fix.

Yea It seems most of the threads here were started by NVR owners, I do not remember a BI thread on this but I bet it exists. Fenderman would know for sure if there was big issues with BI and the Dahua cams. I do wish the features would work but its not a gamechanger for me. Like I have stated in other posts, I moved on to IVS when needed or just motion without 24/7 in certain areas. The quality and management features for multiple sites work well, yea when there is a issue it might be a pain to search but the video is all there and using the graduated scale on the timeline can make quick work of zeroing in on what you need. Just yesterday, I had to track 2 nutjob lady's that entered a building and helped themselves to the receptionists belongings. The building has 16 cams and the front door is the only one that has IVS. Knowing the time they came in, it was quick work to track them, get there plate # and figure out they were most likely mentally not stable.Before they entered the building, they walked around the outside of the building and collected 1/2 smoked cigarette butts and put them in a baggie. The kicker is they drove a 2016 BMW. All this was done with one phone call and about 1/2 hour from my laptop remoting in.

 

[tigerwillow1]

It looks like the dropped frames, is really a problem more with the camera itself. Not so much, the NVR. The NVR is just recording what the camera sends it.

The frames are dropped on external event triggers, too. (When an external event is configured to record on one or more channels, those recordings have dropped frames). Nothing whatsoever to do with the camera. The camera isn't in the event loop.

 

[aristobrat]

I'm running both BI and the Dahua NVR. I have no issues with BI starting recordings incorrectly like Dahua does on both its NVRs and cameras.

I just thought it was interesting that BI specifically mentioned the importance about starting recordings with a full frame. BI does that. Dahua doesn't.

I'm glad you're able to workaround the issue. The way I use my system, it's not as easy.

 

[aristobrat]

can you show video of the issue?

 

[c hris527]

How does it look when you view it through your NVR directly?

 

[aristobrat]

The same. And it looks the same if I try to select those same time periods and download to my computer.