Search options (Page 39 of 133)

Yeah backward playback (and even stepping) is surprisingly complicated. The issue is that most video codecs are optimized for forward playback and the content of a given image is an incremental update over the previous keyframe. So to display a past frame we usually need to go way back, an unknown amount of frames, to find that keyframe, and then decode forward until we find the target frame to show.

At the moment there are a few strategies in Kinovea to alleviate this: 1. Use a intra-frame codec only by default for anything saved by the program. This makes it easier to later step backward/forward as every frame is a keyframe. 2. Keep a small cache of images in memory while playing forward, frames both before and after the current point. This way we can at least go back a few images without seeking. This also helps with smoothing forward playback at normal speed. 3. When the working zone fits entirely in memory, all the frames are cached, this makes random access fast again. In fact if you do this you will see the menu Video > Reverse is active and you can switch the entire video to backward playback.

Yeah, before the nud it was really hard to set small values precisely, that's why the slider is logarithmic, I guess this is no longer really relevant now, so yes, it could use a linear slider instead. It could also be an option. The scenario for very small values is to match two cameras that have different capture latency.

I still think it should be in seconds though, internally everything is in frames but from a user point of view I don't think frames make sense for the general concept of delay, what is the scenario where you think about delay in frames? Also for the case of pre/post recording, like recording for x seconds before and after a trigger event, it's natural to have this in seconds.

Oh this is great!

I reproduced the problem and pushed a fix, let me know if it works for you.

The goal of this piece of code is to set the timer refresh rate for display, and the only thing we really want is to avoid it to be too high, for example if this is a high speed camera running at 500 fps we don't want the burden of refreshing the UI at that rate, it would compete for computer resources with the recording which actually *needs* to happen at 500 fps. So it needs to stay `min()`. In some cases though, the camera framerate can't be known in advance, this is the case for IP cameras (for now, until maybe ONVIF is implemented or something). So in that case we'll just ignore the (unknown at this point anyway) camera framerate altogether and use the configured display framerate or monitor framerate.

The `cameraGrabber.Framerate` is going to come from the camera modules (FrameGrabber.cs in Kinovea.Camera.HTTP for example).

`pipelineManager.Frequency` is only going to be valid after some frames have been received, so it shouldn't be used during connection.

Thanks!

No, this is for the next version.

Hi,
At the moment it is hard coded. And yes the bitrate settings are very aggressive to minimize any loss of information when saving, to best support the archival use-case (e.g: splitting a long session into smaller chunks). It's the first time I hear a player complain because the bitrate is too high though… What player is it?

I've kind of tried to stay away from opening this particular can of worms :-). Codec options can become complex fast, in terms of UI and this complexity will trickle down into the code. Maybe having just two options would work, one for archival and one for web/presentation export? Maybe it can even be selected automatically based on the option to paint the drawings on the images (for archival this should never be done).

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.