1 Topic by covelera

  • covelera
  • Member
  • Offline

The EZGuard IP camera from EZviz (HIKvision) generates MP4 video files that can always be read by Kinovea but most times have an incorrect duration (26:2x:xx.x).  The lack of a correct end time makes working with these files difficult.  There are some times when the import is fine.  I can't find any correlation to file creation size or date.  I can convert these files to MOV and they work fine.  Any ideas ?  The EZViz software does not generate 'standard' MP4 files since many media players cannot play them.

Kinovea 9.1 Beta
Win 10 64-bit (recently updated to build 2004)

2 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Hi,
Could you send a sample file that is exhibiting the problem at joan at kinovea dot org? (If it's larger than 5MB please host it on Google Drive or something because that mailbox has a small quota).
Thanks

3 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Thanks for the sample.
Unfortunately it does look like the problem is in the files themselves.
I get similar duration with other tools, the main metadata are wrong:

Duration: 26:29:35.34, start: 13378.435000, bitrate: 0 kb/s

I'm not sure what could cause this aside from a bug in the encoder in the camera. Does this camera work in "loop recording" mode like a dashcam, where it's constantly overwriting the same small file and it's only when it detects motion or you raise a special command that it splits the file to an indepedent one? I wonder if the duration could be the entire duration since the start of the loop recording process. Does it increase progressively after you restart the camera?

4 Reply by covelera

  • covelera
  • Member
  • Offline

I think you hit the nail on the head.  When I reset camera I get a 'reasonable' duration over multiple same day trials.  I will keep trying over the next several days until the duration issue crops up ...  It looks like all will work fine with a periodic camera reset. 

The camera is constantly on and starts recording when it detects motion.  It catches a few seconds before the motion is detected which means it must constantly be looping to a small file.  At the end of the recorded file Kinovea has a few empty frames (0.5-1.5 seconds) that are easy yo deal with.  Thanks for your insights and all the hard work on Kinovea.

5 Reply by covelera

  • covelera
  • Member
  • Offline

Just a quick update.  After a camera reset the video duration reads fine until after 6-7 hrs and then starts reporting durations in range 26:xx:xx.xx.  The videos still play but it is difficult to move around in video.  VLC video player reads durations ok.  In a future iteration of the software would it be possible to manually enter video duration?

6 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

By going through the frames of the video I can see the timestamps and when the video reaches the last frame I can compute the total number of frames and total time that are actually in the video. So in theory this should be enough to fix this kind of files automatically. I'm not sure what's the best way to go about it though.

It could initially leave things as they are and after the first loop, when it realizes the last frame doesn't match the duration, try to fix it. 

There could be a explicit "Fix duration" button in the Video > Configure timing dialog, that would perform the test and save the actual duration somewhere. This could then become an option in the main preferences to "always try to fix duration", but would be off by default because it will slow down opening the files in the normal case.

Other ideas are welcomed.

7 Reply by covelera

  • covelera
  • Member
  • Offline

These are both pretty elegant solutions.  I would be very happy with a normal first loop, followed by a warning if the duration is way out of wack .... and then a chance to manually enter a new duration. 

Your ideas are better.  I don't know how much of a problem this is for users.

8 Reply by covelera

  • covelera
  • Member
  • Offline

Slight update.  Periodic resetting of camera prevents non-sensible durations, but duration time is still 'off' by a few tenths of seconds.  This shows up as a few dead (nonexistant) frames at the end of the video.  You cannot trim off these frames (lessen true video frames and still have some dead frames).  I can still get a pretty good representation of video and track what is happening ... but it makes comparing videos (and annotations) difficult since the events I am tracking only lasts for about 2-3 seconds.  I guess the only real solutions are what you outlined in your june 20th reply.