31 (edited by joan 2019-10-11 21:15:05)

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

32

Hi Joan,

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!

33

wardjoosten wrote:

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.

34

Joan, every single issue we discussed in this discussion topic has been resolved in version 9.1. Amazing!

35

Does this version (0.8.27) support limb tracking like the latest versions do? I am looking to track the angles of a cyclist's leg during pedals, thanks.

36

There is no "limb tacking" in any version, only pattern tracking. For an angle it will track the three points independently.

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.