Dahua NVRs motion record with scheduled record skips frames
- Thread starter oh6hfx
- Start date
nayr
IPCT Contributor
sigh, no my screenshot is a NVR.. the NVR is whats trying to set the time on your cameas.. I have an option to prevent this from happening, chris apparently does not.. what do you have on your NVR @tigerwillow1
Omygosh, a textbook example of talking past each other. My NVR has the IPC Time Sync setting and it's set for 24 hours, which is probably the default since I didn't know what "IPC" means. After thinking on it for a while I'm guessing it means "IP camera", and I'm assuming the interval is how often the nvr resets the time of all the cameras. At 24 hours it should be irrelevant for the time changes I'm seeing, but I'll shut it off as another random thing to try.
Good news, bad news. I shut off "IPC time sync" in the nvr and the 1-minute changes on an IVS event have stopped. Doesn't change a thing for the skipped frames issue. Just a seemingly unrelated bug that's an annoyance but not a real problem for me. Chris FYI my nvr is from Andy in China.
Did you ask Andy if he could shed any light on this issue? Nellys helped some on the issue, It almost seems when large objects like a truck or when the NVR has to record a lot of scene changes(lots of activity) it gets worse with more or longer duration skips of time. If I have a semi dark parking garage with 1 person walking past the camera, i get very little or no missed time. I wonder if the processor in these systems are under powered and just not keeping pace with the change in events. In the daytime it does seem worse when the scene is brighter and more activity and the 3 other cameras are also recording too. This could be one possible explanation why everyone is having different hit and miss issues. Just a thought.
I finally set up a .dav player and gathered more incriminating info on the nvr.
Experiment 1: With event already recorded, use the "Download by time" feature of the nvr to write before and after the event trigger to a .dav file. This pulls in frames from the end of the "regular" file and the start of the "ivs" file.
Result: Playback from the nvr web interface or direct interface skips 10 or 11 frames. Playback from the .dav file skips 3 or 4 frames.
Experiment 2: While recording on the nvr, also view the camera on SmartPSS. Use the "Local record" feature of SmartPSS to create a .dav file on the computer, then create an event trigger.
Result: nvr playback skips frames (8 on first trigger, 4 on second trigger), the .dav file from SmartPSS has zero skipped frames.
Conclusions: Looks like it's close to 100% this is an nvr problem, with some frames lost when recording and a few more lost when playing back. There's still a small chance it could be some weird interaction caused by the camera. I don't have another type Dahua camera to further chase this angle. I hope it's not an overloaded CPU issue because I'm running only 4 cameras on a 16 channel nvr. Opening a dialog with Andy is a good idea. There was another post about new Dahua firmware. I peeked at what's available for the US version 5216 and it has the same build date as what's currently on my 5216, so I'm "assuming" I'm up-to-date.
Thanks to nayr convincing me to spend more money I might order a HFW5421E-Z next month and be able to test with a different camera. I'm starting to feel like I've done all I can for now to isolate this.
Experiment 1: With event already recorded, use the "Download by time" feature of the nvr to write before and after the event trigger to a .dav file. This pulls in frames from the end of the "regular" file and the start of the "ivs" file.
Result: Playback from the nvr web interface or direct interface skips 10 or 11 frames. Playback from the .dav file skips 3 or 4 frames.
Experiment 2: While recording on the nvr, also view the camera on SmartPSS. Use the "Local record" feature of SmartPSS to create a .dav file on the computer, then create an event trigger.
Result: nvr playback skips frames (8 on first trigger, 4 on second trigger), the .dav file from SmartPSS has zero skipped frames.
Conclusions: Looks like it's close to 100% this is an nvr problem, with some frames lost when recording and a few more lost when playing back. There's still a small chance it could be some weird interaction caused by the camera. I don't have another type Dahua camera to further chase this angle. I hope it's not an overloaded CPU issue because I'm running only 4 cameras on a 16 channel nvr. Opening a dialog with Andy is a good idea. There was another post about new Dahua firmware. I peeked at what's available for the US version 5216 and it has the same build date as what's currently on my 5216, so I'm "assuming" I'm up-to-date.
Thanks to nayr convincing me to spend more money I might order a HFW5421E-Z next month and be able to test with a different camera. I'm starting to feel like I've done all I can for now to isolate this.
hmjgriffon
Known around here
Fastb
Known around here
I concluded that the NVR closes the recording file, and opens a new file for the alarm event. Closing and opening files creates some overhead, ie: compress the file, store, open a new file.
Check the time stamps in the file list in "Playback" screen.
Here's the thread from an investigation a while ago;
Dahua NVRs motion record with scheduled record skips frames
Hope that helps.
Fastb
Check the time stamps in the file list in "Playback" screen.
Here's the thread from an investigation a while ago;
Dahua NVRs motion record with scheduled record skips frames
Hope that helps.
Fastb
Same issues here with a 5208 4K (BD 02-01-2016), appears to be worse on tablets. Smart PSS much better and haven't noticed any missing frames on NVR.
nayr
IPCT Contributor
I think i might know whats going on here, when I exported an H265 clip the other day spanning an alarm triggers I had to convert the export with Handbrake since nothing would export the h265 DAV to anything standard.. In SmartPSS when the doorbell was pressed it looked like a second of video was lost, but after exporting and converting it.. there was no lost video, BUT I got tearing right at the point when the alarm went off:
Notice the tearing the second the doorbell is pressed. (~13s)
Whats happening is when an alert is triggered is its instantly closing out the file its writing too and instantly starts a new file, well that new file does not start with an iFrame like most new files because it can happen whenever in the stream.. I dont think the players are showing anything at all until the iFrame comes in and blank out for a few moments.. In SmartPSS that second of tearing was not displayed at all.. It looked like it was dropping frames from the client.
However if I play the original DAV I exported in SmartPlayer, spanning the events.. it plays from start to finish with no dropped frames and no tearing.. so no data is lost, its just a client limitation that it cant start showing a video until the first iFrame comes in... Lowering the iframe interval to match FPS will probably help a bit, by default its 2x the framerate.
Notice the tearing the second the doorbell is pressed. (~13s)
Whats happening is when an alert is triggered is its instantly closing out the file its writing too and instantly starts a new file, well that new file does not start with an iFrame like most new files because it can happen whenever in the stream.. I dont think the players are showing anything at all until the iFrame comes in and blank out for a few moments.. In SmartPSS that second of tearing was not displayed at all.. It looked like it was dropping frames from the client.
However if I play the original DAV I exported in SmartPlayer, spanning the events.. it plays from start to finish with no dropped frames and no tearing.. so no data is lost, its just a client limitation that it cant start showing a video until the first iFrame comes in... Lowering the iframe interval to match FPS will probably help a bit, by default its 2x the framerate.
Last edited:
Did you export the DAV from the NVR or SmartPSS? I found that when I exported from the NVR using a time interval that spans both files, I still lose a few frames. Exporting from SmartPSS local recording I didn't lose any. From your previous posts I'm assuming this is a new-to-you problem with the 5216, and it was ok in the 4216. (Actually I'd guess it would be related to the "S2" designation, and not 4216 vs. 5216). Whatever the case, it should be fixable in the firmware.
nayr
IPCT Contributor
I exported w/SmartPSS.. and I'm still running the 4216, the 5216 is in the mail, might be here monday.
Deali
Young grasshopper
It is a strange behavior. It looks like on the motion record it is not pre-recording (the 4 seconds).
But at least on both records combined i am loosing no video. Just a short flicker when it switches to the md.
Best would be to just set a flag and keep on recording.
But at least on both records combined i am loosing no video. Just a short flicker when it switches to the md.
Best would be to just set a flag and keep on recording.
nayr
IPCT Contributor
the pre-recording only comes into play if your not recording continuously.. Ive got one camera that is recording on IVS only (CatCam), and I can start a few seconds on the timeline before the flag is indicated (it looks like nothing is recorded before the event on timeline, but it is).. If recording continuously there is no need for pre-record.
I agree though, if they just kept on going with the file it had and flagged something in metadata this wouldent be an issue.. but if you open up the file listing of recordings you'll see that each event gets its own file.. If you merge em into a single file, it can use the iframe from the previous file.. but if you just pull out that one file all by its self, you may have to wait for the next iframe to be sent before it starts playing.
If recording on IVS/Motion only I suspect it keeps the last iframe in that pre-record buffer, so when it starts saving to the file it already starts off with a reference frame.. If you set pre-record to 0s, then the same issue might be seen where its waiting for the first iframe to start rendering video..
While its rather inconvenient, im still able to get a video file w/no lost data if I export a merged single file from SmartPSS before the event is triggered.. or if I playback directly on NVR via OSDUI.. so its not really a critical problem since a work around exists.
I agree though, if they just kept on going with the file it had and flagged something in metadata this wouldent be an issue.. but if you open up the file listing of recordings you'll see that each event gets its own file.. If you merge em into a single file, it can use the iframe from the previous file.. but if you just pull out that one file all by its self, you may have to wait for the next iframe to be sent before it starts playing.
If recording on IVS/Motion only I suspect it keeps the last iframe in that pre-record buffer, so when it starts saving to the file it already starts off with a reference frame.. If you set pre-record to 0s, then the same issue might be seen where its waiting for the first iframe to start rendering video..
While its rather inconvenient, im still able to get a video file w/no lost data if I export a merged single file from SmartPSS before the event is triggered.. or if I playback directly on NVR via OSDUI.. so its not really a critical problem since a work around exists.
Last edited:
Deali
Young grasshopper
In my case it looks like the record file has the motion part in it before it is shut down. On the external fileviewer the two files are matched perfect. Maybe in the GUI it cant syncronize so well or other timing issues.
On SmartPSS V1.14.0 it is better then on SmartPSS 2.0! It will skip the double amont of video in 2.0.
Would be nice if Dahua woul rethink the issue.
On SmartPSS V1.14.0 it is better then on SmartPSS 2.0! It will skip the double amont of video in 2.0.
Would be nice if Dahua woul rethink the issue.
nayr
IPCT Contributor
I think its a difference in the network streaming the clients use, when its playing the file directly it can open the next file and just dump it into the video buffer with no interruption.. When its streaming over a network, it introduces a delay thats far too noticeable.
In the API code you can stream each file the NVR has recorded via RTSP, and if your writing code to play through all those files simultaneously its going to tear down one stream and build a new TCP connection each time an event is triggered.. You could try to preload the next stream in buffer and do it all in memory, but that adds load to the NVR and display system and I suspect it wont scale all that well with alot of cameras.. That loading of the next file via RTSP sure isint helping anything, its taking time to make the connection and then its not using the data from the previous stream because its already closed all that out and now has to wait for an iFrame.
In the API code you can stream each file the NVR has recorded via RTSP, and if your writing code to play through all those files simultaneously its going to tear down one stream and build a new TCP connection each time an event is triggered.. You could try to preload the next stream in buffer and do it all in memory, but that adds load to the NVR and display system and I suspect it wont scale all that well with alot of cameras.. That loading of the next file via RTSP sure isint helping anything, its taking time to make the connection and then its not using the data from the previous stream because its already closed all that out and now has to wait for an iFrame.
Deali
Young grasshopper
If i use the Player both files are on local disk. GUI and SmartPSS have to get the data from NVR-Disk. As other people mentioned, if the play it on the NVR it is also fine. That is also local disk to the NVR.