Search options (Page 44 of 136)

Assuming you are using 0.8.27.

There are two main things that will impact tracking "stickiness": the size of the search boxes and the use of markers.

When you use the regular track tool by right clicking an object and doing Track Path, you'll see the two tracking boxes. These can be resized from the track tool configuration dialog. You want the inner box to be tight around the object you are tracking so it doesn't pick background. The outer box is the search region, size this one based on the speed of motion or framerate, that is how much displacement the object can undergo in one frame.

The tracking on other tools like angle also uses these boxes but they are hidden. You can configure them from Preferences > Drawing > Tracking. So what you can do is use a normal track tool to figure out appropriate box sizes and then use that here.

Using markers will greatly improve precision and reduce loosing the tracking. It's pretty much mandatory for tracking joint angles properly.

You don't need a codec, Kinovea uses an embedded codec library. What version of Kinovea are you using? Try with version 0.8.27 and see if it works. The newer GoPros use an encoding that didn't exist at the time of version 0.8.15.

Hi,

The most critical thing that will impact bandwidth is whether the camera is sending an MJPEG stream or full frames (any other stream format). For 1280x720@100, assuming RGB24 full frames, bandwidth shown in Kinovea should be something like (1280*720*3*100)/(1024*1024) = 263.67MB/s. This is how many bytes per second pass through the primary ring buffer, (not the same as the delay buffer, see diagram below).

So I'm assuming the 1920x1080@50fps giving 20MB/s was an MJPEG stream? (Assuming the framerate is respected by the camera, low light conditions will increase exposure time and decrease framerate automatically, other cameras let you select options that aren't supported and send low fps streams instead).

When using an MJPEG stream, the recording mode "Camera" will pass the MJPEG frames straight to the output, bypassing decompression/compression, so this is the fastest to record. Frames are decoded in a different thread for display.

When using an RGB stream, the frames are uncompressed for display/compositing and then recompressed for output, and this is taking some time. My understanding is that this is the current bottleneck.

I'm not sure about the truncation. I'll have to do my own experiments. Using 0-second delay vs using longer delay shouldn't really make a difference in terms of performance. The frames are sourced from the buffer in the same way. However there might be a laps of time where the buffer isn't full and there is no frame at the expected delay, in which case nothing will be output. Maybe this could explain the truncation and framerate difference?

Next version will have a mode for recording without compression whatsoever. This is only for the "Camera" recording mode at the moment. It increases performance for high bandwidth cameras that send RGB frames like USB 3.0 industrial cameras and possibly newer high end webcams. It takes a ton of space though.

I'm looking at options on how to improve the workflow. I think this self-training use-case is very interesting and Kinovea should support it. The difficult part is that bottlenecks vary depending people's machines, cameras, and over time as hardware and connection standards evolve.

Here is a diagram of the flow of frames during capture and recording [ edit: removed the link, this is very much obsolete now ] I did a while ago. Hopefully not too cryptic. In the diagram the "performance path" is when you select recording mode "Camera", and the WYSIWYG path is when you select "Display".

Regarding USB it also has to do with USB root hubs. The USB port the camera is plugged into should ultimately be on its own controller so it can have the current and bandwidth for itself instead of sharing it with the other camera.

Yeah there is a heuristic when loading a file when both screens are already filled. Maybe the menu View > Invert video positions could help, it will swap the screens around, but it's not mapped to a shortcut key at the moment, sorry.

Hi,
The same file fails to load from one drive and loads fine from another or are they different files?
Do you have unicode characters in the file name? Are the other drives network drives or local? Is the path to the file on the other drive very long, like more than 260 characters? Are you on a Mac with Windows emulation/dual boot or on a Virtual machine? What is your Windows version? Is it 32bit or 64bit? Do you see the thumbnails for the files when you navigate to the drive using the built-in explorer?

Could you get to menu Help > Open log folder and send me log.txt and log.txt.1 by mail at joan at kinovea dot org or see if you can locate any relevant error and paste them here?
Thanks

Please try with the beta version 0.8.27 from the download page. It should detect and rotate the video automatically or you can do it manually from menu Image > Image Rotation.