Issues with delay timing

Hi,
In addition to the configured framerate and the display framerate, there is also the actual, received framerate. It's possible that Kinovea is not receiving frames at the correct speed for whatever reason (low light, network conditions, camera is lying, etc.). There should be a "Signal" field in the infobar that shows up after a while. This shows the framerate received.

The way recording with delay works has completely changed in the next version, so we'll see if that fixes your particular problem. It will now always save at the camera configured framerate, display framerate is not used anymore.

It's possible the issue is that the stream received is at 30 but Kinovea wasn't able to record it fast enough to disk unless your force it down to 21. Or it's possible the stream received is at 21 in the first place. The "Signal" value should give the answer to that. Another way I use is to pause the stream and navigate in the recent frames with the delay slider to see if the stopwatch matches what the delay says.

Based on your description it looks like the actual received framerate is 21, even before attempting to record to disk. Unless the camera is lying this should be fixable by other ways (most probably adding more light to avoid triggering auto-framerate by way of auto-exposure).

For this case of the camera not sending what it's configured to, currently the best way to fix it is at playback time, by going to menu video > configure timing and fixing the framerate there. In the future I'll also see to add an option to be able to save the "received framerate" in the video, but ideally this option would be per-camera and saved in the preferences per-camera, as the goal is to fix cameras that are lying about their framerate. So as the release of the next version is coming soon, I pushed this to the roadmap for the next one.

Hi Joan,
I just noticed that you have updated the build environment to something feasible. Thank you very much for that. I immediately tried the latest Kinovea version from github!
The recording results from the delayed video stream are indeed much better. I now get the expected 30 fps recording. However, unfortunately the display framerate is very low (1 fps). From the logfile I get

CaptureScreen - Nominal camera framerate: 0 fps, Monitor framerate: 59 fps, Custom display framerate: 30 fps, Final display framerate: 1 fps.

The cameraGrabber.Framerate == 0 for some reason, I haven't found where that info comes from.
If I change the code in Kinovea.ScreenManager.CaptureScreen.Connect2() (line 609-611) it works for IP camera's, but I don't know enough about the details to say this is an actual fix:

double slowFramerate = Math.Min(displayFramerate, monitorFramerate);
double framerate = cameraGrabber.Framerate;
if (framerate == 0)
    framerate = pipelineManager.Frequency;
if (framerate != 0)
    slowFramerate = Math.Min(slowFramerate, framerate);
// slowFramerate = Math.Min(slowFramerate, cameraGrabber.Framerate);
slowFramerate = Math.Max(slowFramerate, 1);

Thank you for the update. It works perfect for me now!

In 0.8.25 I proposed a fix to update the delay when changing delay with the hotkeys. This doesn't work anymore (seems to be due to the nud), setting the delay in the slider is also very buggy because of this.
The old fix should be removed. I'm working on a new fix (using sldrDelay.Force(value) works for the hotkeys, but not for the nud).

In my opinion the nud should have a fixed maximum (now calculated from framerate, so changing over time?), and maybe everything should be in frames instead of seconds for the nud?

Next to that, I would suggest to change the slider for the delay to a linear slider.

I agree that seconds is a more natural setting for delay. Lets try to make that work.

I hadn't considered the usecase 'capture latency' (or synchronisation) for the delay. This would indeed be better with a logarithmic scale (or maybe this is fixed by using the nud?).

I think I narrowed the problem down to a loop in updating values:

SldrDelay_ValueChanged
--> calls: presenter.View_DelayChanged
--> calls: DelayChanged
--> calls: view.UpdateDelay (with delay in seconds recalculated from pipeline frequency)
--> calls: UpdateDelayLabel
--> changes: nudDelay.Value , so calls: NudDelay_ValueChanged
--> changes: sldrDelay.Value , so calls: SldrDelay_ValueChanged (with delay recalculated from a different framerate)