Search options (Page 33 of 131)

Yeah, in one of the logs there is for example this:

Frame #100. Conversion/Encoding: ~1.010 ms. Write: ~1.890 ms.
Frame #200. Conversion/Encoding: ~0.790 ms. Write: ~1.750 ms.
Frame #300. Conversion/Encoding: ~1.480 ms. Write: ~1.680 ms.
Frame #400. Conversion/Encoding: ~1.580 ms. Write: ~1.960 ms.
Frame #500. Conversion/Encoding: ~0.850 ms. Write: ~1.590 ms.
Frame #600. Conversion/Encoding: ~1.430 ms. Write: ~39.580 ms.
Frame #700. Conversion/Encoding: ~0.830 ms. Write: ~1.730 ms.
Frame #800. Conversion/Encoding: ~0.920 ms. Write: ~1.730 ms.
Frame #900. Conversion/Encoding: ~0.830 ms. Write: ~85.980 ms.
Frame #1000. Conversion/Encoding: ~1.030 ms. Write: ~7.390 ms.

The last number is the average write time in milliseconds over 100 frames. But the most likely where it's 39 or 85 is that there is a single frame that was blocked for several seconds for some reason. I've seen the same pattern when I put the target directory on the system drive.

Thanks. And the drop counter in the info bar stays at 0 or it increases?

To summarize, the problem is that the display for the live camera (delayed) freezes for a moment, although the corresponding recorded file doesn't show a jump between frames. Is this correct?

One thing that can cause lower performance is when the target folder for recording files is on the same drive as Windows, as the system is regularly writing into its own files sometimes it competes for drive access. When I do this on my machine the live image freezes every 10 seconds or so and the drop counter increases. As soon as I move the target to another drive it works. (Both drives are SSD).

I published a new version and changed the links in the original post. This update addresses a few important points, mainly 1. the crash at launch when installed over version 0.9.1 and 2. the inability to increase the memory buffer in the player.

Please continue to report any problem here.
Thanks!

It's interesting to compare the behavior with version 0.8.15 which used a different way to get the timestamps. In that version the duration is computed wrong and the video goes all the way but then it loops back before the stated duration and the playhead continues and never loops back. It also completely breaks the working zone selector.

Thanks for the sample.
It is one of those files where the first frame of the video has a negative timestamp, this throws off some calculations… Can you share what camera or process has generated the file?
It's probably fixable but needs care to not break other things in the process.

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.

If you are sure you won't save the sequence, the simplest way to do instant feedback is to use the delay function. For example you can set the delay to 5 seconds.

I'm trying to reproduce the problem. Could you send a screenshot at joan at kinovea dot org? In particular what is the camera image size, whether the camera view is filling the capture screen, and same for the playback side.