1

(1 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.

I reproduced it quite easily and testing a fix. It's a regression related to the tracking now running in parallel.

There are a few more things to fix. In terms of user interaction, we can't easily "stop tracking" on the grid itself. And the idea for making measurements with a moving camera was to go through the "Camera motion estimation" procedure instead, then the grid will automatically stick to the object throughout the video, but right now this doesn't play nicely with the coordinate system and measurements.

Thanks. I will try to reproduce it.

6

(1 replies, posted in Bug reports)

It looks like the file path has characters invalid for file names (something like <, >, :, ", /, \, |, ?, *). it should be caught before saving and show a dialog but it must be missing it.

7

(1 replies, posted in General)

I'm curious where that information is coming from. Kinovea has never supported RTSP, only MJPEG.

8

(3 replies, posted in General)

The distortion grid has been replaced with the Lens calibration menus under Tools. Especially the Lens calibration mode has a more complete calibration workflow now. It needs to be run on a short checkerboard calibration video. Check here.

The color profile button has been removed because of some changes in the way the drawings properties work. Now when we change properties like color on a drawing they are immediately saved as the new default, and the next drawing of this type will use these properties. This is more natural than having to manually save it every time. If you have a specific workflow that is broken by this change let me know so we can see if it's something that can be worked around or taken into account.

Could you share one of these videos that cause the problem please? If it's small you can send it at the following: joan at kinovea dot org. If it's more than 5 MB please send it via a file transfer website like swisstransfer or put it on google drive or similar and share the link by email.

That is very strange.
What do you mean by "a continuous blue line next to the red indicator", what red indicator?

11

(1 replies, posted in General)

For now I would say just set the playback speed to 50% (use up/down arrow keys to land on exact percentages), if it's possible for your use case. And if you are sure the videos were captured at 30 fps you can set that in the time calibration dialog so the timestamps, time intervals, speed measurements, etc. take it into account. Time calibration doesn't touch the internal video frame rate used for playback.

Sometimes the file format container and the video codec disagree maybe it's one of those cases. Unless the video is interlaced in that case you would see artifacts and you would need to do Image > Deinterlace.

Not familiar with continuous x-ray images, is it imaging someone/something in motion or is it the tool that is moving and scanning at different depths/locations? Where is the 30 fps information coming from? Is it 30 or 29.97?

12

(1 replies, posted in General)

rodrigoncalves_ wrote:

the application closes automatically.

Hi,
First of all sorry for this, it sounds like a bad bug. Do you have any exception logs in the log folder, these are files starting with "Unhandled Crash" in the file name. If so please send them to me at joan at kinovea dot org. Thank you.

It's not necessarily a simple feature to implement because the magnifier tool is unlike any other tool due to how it behaves and also functionally the magnified area can take up a lot of space in the viewport so it would make it difficult to use (at least until the magnified area can be moved outside the original image area).

Maybe a different approach would be something like the Kinogram mode where the viewport is split in multiple tiles and you can manually pan around inside each tile, and there is a zoom level for all the tiles.

Oh, I forgot to update the little file that tells what's the latest version. It should be fixed now, you can try again.

Or you can get it from here: https://kinovea.org/download/

Is it a normal angle object or is it an "angle-to-vertical" or "angle-to-horizontal" object?
There was a bug with the latter that was fixed in 2025.2.