This should be there in 0.8.27. The sizes of the pattern window and search window are taken from the default tracking configuration set in preferences. It works much better with markers and typically it still requires some manual adjustment. The tracking performance and UX is not so good even in latest versions, I'm investigating various ideas to improve it.

all the videos that are recorded from the display are sped up to about 120% of realtime.

Hi, it is a limitation of the performance of recording delayed video in 0.8.27. The speed up is because the recording process missed some frames. It should be fixed in the next version.

We're using Kinovea in our gymnastics facility with a delay and the option to record from the display. It all works brilliantly, except for the fact that all the videos that are recorded from the display are sped up to about 120% of realtime.. is this a setting that I can change? It does so on three different stations, all using 0.8.27 with a Logitech C290 webcam.

Thanks!

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".

Hi,
if Kinovea is in replay mode, and the left window is loaded once with a video, I could not find any solution to "reload" it with another video. I can only address the right window using ctrl-o or Open/File to load another video. I don't want to use Drap and Drop (AutoIt-script).

Is there any solution or maybe a hidden hotkey?
Thanks

Reiner,
I posted my AutoIt Script here:https://golfsimulatorforum.com/forum/build-your-own/computer-systems/136645-automatic-swing-recording-and-slow-motion-playback-with-kinovea/page6
It was very tricky getting the playback to work in Kinovea.  Ctrl-O was my first try also.  More shortcut keys would definitely help.

After some investigating:
- As Reiner suggested, I do have USB 3.1 gen 1 on both computers I tested in Posts 16 and 21 above.  So the max transfer rate is 5Gbit/s or 625MB/s.
-When I monitor the USB port using Device Monitoring Studio, it tells me the camera is sending 20MB/s to Kinovea.  This is a single instance with 1 camera, 1 capture screen, 1280x720 100fps.
- When I monitor 2 ports with 1 camera each, Device Monitoring Studio also shows 20MB/s to each port.  This is with 2 instances, 1 capture screen each, 1280x720 100fps.  So the USB ports do not appear to be overloading the same root hub.  Also, each port has its own controller.
-A flash drive read/write test on the USB port shows 25MBps/10MBps.
-AMCAP recording software shows a frame size of 2700kbits/s.  At 64fps without compression, I think this would result in a calculated transfer rate of 22MB/s.  At 100fps, this would be 33MB/s.
-Kinovea reports a Bandwidth of 200MB/s and 99fps coming from a single camera running at 1280x720 100fps in either 1 or 2 Capture Screen modes.  At 1920x1080 50fps, bandwith is 18.9MB/s.  At 640x360 330fps, bandwidth is 350MB/s.
So my first question is, at 1280x720 100fps, is Bandwidth as reported in the header of the Capture Screen really 200MB/s?  Or is it 200Mb/s, or maybe 20MB/s?  How is Bandwidth defined here? I wonder why 1920x1080 50fps bandwidth is so much lower at 18.9MB/s?  {I'm not 100% confident in my calculations, so please let me know if something looks wrong.}

Next, to simplify things, I ran some manual recordings in Kinovea (No AutoIt script) using a stopwatch on my phone to determine when to press the start/stop button to get a 5 second clip.  The stopwatch is visible in the recordings to calculate the real framerate, transfer rate, and duration.  I then opened the clips in Kinovea to see the # of frames and duration.  With a single instance of Kinovea, 1 Capture Screen, and 1 camera at 1280x720 100fps, here are the numbers:
- Case 1: "Recording mode and delay, Camera: records the video stream coming straight from the camera"; File Size = 88.8MB, Duration = 4.59sec, Frames = 459, Stopwatch duration = 4.66sec, Calculated transfer rate = 19.1MB/s, Calculated frame rate = 98.5fps
- Case 2: "Recording mode and delay, Display: records what is currently displayed on the screen" and "Display framerate (fps)" set to 100 and "Delay slider" set to 0; File Size = 42.7MB, Duration = 1.37sec, Frames = 138, Stopwatch duration = 4.58sec, Calculated transfer rate = 9.3MB/s, Calculated frame rate = 30.1fps
- Case 3: "Recording mode and delay, Display: records what is currently displayed on the screen" and "Display framerate (fps)" set to 100 and "Delay slider" set to 4.5sec; File Size = 37.9MB, Duration = 1.21sec, Frames = 122, Stopwatch duration = 1.96sec, Calculated transfer rate = 19.3MB/s, Calculated frame rate = 62.2fps
- And finally Case 4, which is what I use with AutoIt: "Recording mode and delay, Display: records what is currently displayed on the screen" and "Display framerate (fps)" set to 64 and "Delay slider" set to 4.5sec; File Size = 43.9MB, Duration = 2.22sec, Frames = 143, Stopwatch duration = 2.22sec, Calculated transfer rate = 19.8MB/s, Calculated frame rate = 64.4fps
My observations from the numbers above are:
1) It seems to me that Kinovea 8.27 is able to receive 1280x720 at 100fps on my laptop in Live Mode, but not in Delay Mode.
2) It appears that, in Delay Mode with the slider moved, Kinovea truncates the video clip.  For example, in Case 4 above, the stopwatch shows that only 2.22sec of the 5sec clip that was recorded.
3) Also, with the slider moved to 4.5sec delay in Case 3, the recorded clip has a higher frame rate (62.2fps) and transfer rate (19.3MB/s) than with the slider set to 0 in Case 2 (30.1fps and 9.3MB/s).
My second question is, are these the expected behaviors of the Delay Mode capture pipeline (Buffer/Composite/Display) in Kinovea 8.27?  Is there something that I could change to get the full frame rate?  For example, change Kinovea settings, better laptop, just wait for v8.28, etc.

You can see the AutoIt script in action here: https://youtu.be/76bIdMv-GPY
Even at 64fps, it works very well for golf swing analysis.

Thanks again!

And one more - is it possible to NOT showing the centre of the circle? (marked as "+")

At the moment it's not possible to remove it, but you're right, it should be optional.

No, it's not possible. There is currently no plan to add this in the near future.

Good update, few useful features. To be honest, I prefered this little bit transparent text box (just for the sake of transparency). Is it possible to set the transparency?

Rectangle - simple, yet very necessary. I would like to see eclipse as well. It would be nice if those, along with circle, could be filled with colour - and setting the transparency of this colour would be needed then. This would be very useful to show spaces etc.

And one more - is it possible to NOT showing the centre of the circle? (marked as "+")

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.

Is there any solution or maybe a hidden hotkey?
Thanks