I have changed the maximum playback speed to 10x. It's something I wanted to do for a while, but it could only be done after some changes in the way the player works that happened recently.

https://www.kinovea.org/screencaps/2026.1/2026.1-speed-slider.png

1x normal speed is still in the middle. I experimented with logarithmic scale but in the end I settled on a piecewise mapping with 0 to 100% on one side and 1x to 10x on the other side. When a capture frame rate is configured there is a more complex relationship so we get more pixels allocated to the slow motion side for fine tuning.

One thing I'm not sure about is whether this should show the resulting frame rate like in the snapshot? I'm not sure if it's relevant to the analysis or merely a technical detail. On the other hand the frame interval in milliseconds could also be an interesting data point, when studying frame by frame it's good to have a reminder of how much time passes between frames. Maybe have these two off by default but have an option to show them if wanted?

I wonder if some people would be interested in really high speed factors, like 100x or more, to study long term effects in a timelapse manner. I always remember this video about the swimming portion of a triathlon that was super sped up and you could see the slow drift of people due to the currents, something you would not realize at all while watching at normal speed.

For really high speed factor the resulting frame rate stops making sense. It would be more interesting to show the "spectator" frame interval, like if every frame covers 30 seconds of real time for example.

Added this a few days ago.
It will use whatever time format is currently configured.

https://www.kinovea.org/screencaps/2026.1/2026.1-copy-time.jpg

Yes, I just added this a few days ago.

It will be configured in the preferences, something like this:

https://www.kinovea.org/screencaps/2026.1/2026.1-jump-sizes.png

You set the size of the jump and the "unit" of the jump independently. This is just how I have it configured right now, but the default will probably be something like 0.5 seconds for small jump and 10% of the video for large jump.

For "Percent" unit it is snapping to the next/previous step. For seconds and milliseconds, it takes into account capture frame rate if you have configured it.

There is a little "toast" message showing the size of the jump on the side of the screen, and if you hit the shortcut repeatedly it accumulates the value. So you can quickly jump +2, +4, +6, +8 seconds for example and get feedback about what you are doing.

4

(6 replies, posted in General)

You should be able to do these in either order I think.

I tried to reproduce the problem but for the moment I can't, even if I put the corners in a part of the image that's very distorted by the lens.

I'm thinking that maybe there is an invisible object that is picking up the grab, and has priority over the grid. What if just before trying to grab the grid corner you do a right-click instead, what menu do you get?
Do you get the video background menu (long menu starting with "Mark current time as origin"), the grid menu (it has an "Options" menu with an entry "Show grid"), or another drawing's menu? If it looks like another drawing you can go in its "Configuration" and see which one it is. For the next version I added the name of the drawing at the top but for now you have to infer it.

If it looks like another drawing please make a copy of the KVA before trying to move it around and send it to me so I can more easily debug this.

5

(1 replies, posted in Bug reports)

Hi, thanks.

Yes it's a limitation of the current version but it will be fixed in the next version. I just checked, your file will work.

I'm reviewing the forum for old bugs.

Based on the original post having the files in the "KakaoTalk" folder and based on second user username being "taehyun" I think this is related to the bug that was specific to Korean locale, this bug has been reported to me many times by Korean users.

I think this should be fixed in the next version 2026.1. I don't have a Korean system myself to verify the fix though, so if anyone wants to help please reach out, thanks.

7

(1 replies, posted in Bug reports)

Yes, this will no longer be a thing in the next version.

Hi, the video exporter uses very conservative compression settings and creates huge files. It has been an issue for years but I have addressed this for the next version. There will be more options to configure it, codec, quality, compression level, and some presets.

9

(6 replies, posted in General)

That's strange. Must be a UI bug.

There is an area around the corner points that should detect the grab. Can you zoom in more and see if you can grab while zoomed?
What is the resolution of the image/video? Is it particularly big or small? Are you doing this while still in the Lens calibration mode or back in the general Analysis mode?

10

(6 replies, posted in General)

Hi, the video needs to be short enough that it triggers the "cached" mode. You can increase the memory allocated for this in Preferences > Playback > Memory. And make the video a few seconds long.

The documentation is currently here until it's merged into the main documentation: https://www.kinovea.org/en/forum/viewtopic.php?id=1977

Some people do it intentionally, setting the replay speed to 50% once and so having it automatically carry over was a feature request, to make a feedback loop that's always in slow motion. I could add an auto-reset option though. But first I want to try to improve the playback perfs.

Hi, yes if I remember correctly I deactivated the full caching mode on replay players to make sure it opens the video instantly instead of spending time caching it which can be disruptive if you want instant feedback. In the context of capture/replay loop people usually just replay the video a few times rather than do full analysis so it's a good tradeoff. I think it was also an issue for dual replay synchronization.

Regarding the auto-slow down I'm currently working on updating ffmpeg libraries and reviewing player performance so hopefully I can improve the behavior here. Right now it tries to not drop any frames and it slows down to maintain this goal. But for playback it's probably better to drop frames. I think I have the upgrade figured out at this point and starting to look into performance.

13

(2 replies, posted in General)

1. Lag: there are a few axes. Using an SSD, saving the recordings to a different drive than the Windows drive, changing the recording mode in the preferences.
2. Side by side comparisons are possible yes. For example, menu View > Two playback screens.
3. Currently the capture of video is not optimized for sharing. I'm working on this for the next version, among other things. Capture images should be fine, you can save as jpeg or png and share that. If you meant capturing the whole interface like a screencast then no, you would have to use something else on top.

For multiple cameras setup there is a possible workflow where you have one instance of Kinovea for recording and another instance of Kinovea for reviewing. This can better utilize the CPU cores. Even for just one camera and one instant replay that might be another way to improve responsiveness.

Sorry I don't have more time to expand these points in too much details right now but should have more time later in the summer. Unfortunately I didn't get around to fully update the manual lately, so it's half way done in a draft version, I'll get around that at some point as well.

I'm not entirely sure what you mean. Ideally if you can create a bug report in github and attach a screenshot that would help me understand and can be used to track progress.

Hi, I have started the work to update to the latest FFMpeg version. (It's likely not a problem in the library itself but in how Kinovea uses it, but the refactoring to adapt to the latest version should help fix these issues.)

If you could send me a private link to the file as an example it would help my tests (joan at kinovea dot org).

edit: oops, I just realized you already sent me the video! Thanks.