Experimental version - 0.8.27 (Page 2) — General

16 Reply by Waheeden 2019-02-23 03:02:22

Waheeden
Member
Offline

Joan,
1) Processor: AMD Ryzen 5 2500U - 4 cores, 8 logical processors:
a) 2 Instances, 1 camera each, idling (not recording): 4 at 0%, 1 at 25%, 2 at 50%
b) 2 Instances, 1 camera each, recording: 4 at 0%, 1 at 25%, 1 at 50% with spikes, 2 at 100%
c) 1 Instance, 2 cameras, idle: 6 at 0%, 2 at 50%
d) 1 Instance, 2 cameras, recording: 6 at 0%, 1 at 25% with spikes, 1 at 100%

I think you are right - It looks like the 2 Instance mode gets twice as much processing power, which may be what lets it double the frame rate. Is there any opportunity to use additional threads/cores?

2) The xml file I was referring to is the Capture History in App Data. I think both instances of Kinovea are trying to write to it at the same time. I uploaded the xml file and the error text in bug tracker #421.

The AutoIt script hits record for Instance 1 (Face On - FO) and then record for Instance 2 (Down the Line - DL) with no wait time in-between to keep the two recordings as synced as possible. It also ends the recordings almost simultaneously.

The error seems to have gone away after I added a 0.05s delay between clicks. I also uploaded the Capture History after adding the delay. The file entries after adding the delay only show the Instance 2 (DL) recordings, whereas the earlier file entries without the delay show recordings from Instance 1 (FO) and/or Instance 2 (DL). Some of this is due to the 1 Instance, 2 Capture Screen setup runs also.

I installed a second version of Kinovea in its own directory so that the two instances would not share files, but it appears that they both are still using the same C:\User\App Data\Capture History\Date.xml file.

Thanks again!

17 Reply by joan 2019-02-23 10:15:01

joan
Admin
Offline

Thanks for the investigation!

I installed a second version of Kinovea in its own directory so that the two instances would not share files, but it appears that they both are still using the same C:\User\App Data\Capture History\Date.xml file.

You need to use the .zip version for this. It's not installed but just extracted to wherever you want, and it will contain its own AppData subdirectory where everything should go.

18 Reply by Faultyclubs 2019-02-23 20:49:58

Faultyclubs
Member
Offline

Faultyclubs wrote:

joan wrote:
I imagine what you really would like is that when the audio from the golf club triggers the recording it still includes the few prior seconds of the swing, at the camera max framerate.
Yes, is this possible please?

If Kinovea is updated with audio trigger and a pre-recording buffer to be usable for golf (we can always hope!), there will immediately be other feature requests to make it work for typical use cases. So I include them here to avoid surprises.

1) Audio Trigger as mentioned above. User settable sensitivity.
2) Pre-recording buffer as mentioned above. User settable duration and delay
3) Portrait mode recording (in addition to the normal landscape mode). Both in the capture and playback screens. Needs to be persistent so we don't have to constantly change it.
4) Option to automatically play back the captured recording with a user defined playback start delay. User defined slow motion with looping.
5) Audio trigger capture priority. This means if the playback loop is running and a new hit occurs Kinovea should automatically switch back to capturing.
6) Support for two simultaneous cameras, both for capture and playback in the same automated loop described above. Golf is normally recorded with at least two cameras, a "down the line" (DTL) and a "face on" (FO) camera.
It would be OK if the two capture screen and two playback screen toggled back and forth since we don't need to see the capture screens when we are looking at the playback screens.

NOTE: While golf recording is typically done at the maximum camera frame rate, it is not ALWAYS done at the maximum. Indoor recording does not always have enough light to support the maximum rate. Also the maximum camera rate may not be at a suitable resolution. So recording should support all modes up to and including the maximum frame rate.

Much of golf swing recording is done at the range or in the simulator without a coach (ie solo). So automation is important. The above also works well with a coach who will typically let the automation run only stopping playback occasionally to provide detailed illustration and analysis.

Hope this helps.

19 Reply by Waheeden 2019-02-23 21:59:35

Waheeden
Member
Offline

Joan, extracting zip file for the 2nd instance of Kinovea worked great. The AutoIt script ran in 2 instance mode without any errors. Thanks for your help!

20 Reply by joan 2019-03-11 17:58:25

joan
Admin
Offline

@Faultyclubs: Thank you very much for the extensive feature list, it's much appreciated. Even if not all features can make it, it's important to keep them in mind to avoid design decisions that would make them much harder to implement in the future.

21 Reply by Waheeden 2019-04-08 23:32:38

Waheeden
Member
Offline

Hi Joan, this is an update on post #16 above about the golf swing dual camera delayed video capture script. I ran the same script on a Microsoft Surface Studio 2 with Core i7 2.9GHz processor. I thought the faster processor might give more frames per second than the HP Envy with AMD Ryzen 5 2.0GHz, but it didn't. Both computers maxed out at 64fps using 1 OV4689 camera per instance of Kinovea. The i7 displayed the same processor utilization as the AMD 5 in cases a through d above. Hopefully that will help pinpoint the bottleneck.

Another update, since multiple instances of Kinovea are now possible, I replaced VLC with a third instance of Kinovea to perform automated playback. This way we can go right into Kinovea's analysis features after every swing without having to manually open any files. It works very well.
Thanks again - Kinovea is so helpful!

22 Reply by Reiner 2019-04-09 22:01:32

Reiner
Member
Offline

Hi,
I think, the maximum acquisition rate is rather less related to the processor but to the USB-Interface. Using a relatively new motherboard having USB 3.1 release 2, you can use 2 cameras with 120fps without dropped frames. It's a i5 9600k processor loaded at about 70% evenly distributed to all 6 cores, if 2 kinovea and some other stuff (Skytrak etc.) are running.

23 Reply by Reiner 2019-04-09 22:07:04

Reiner
Member
Offline

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

24 Reply by joan 2019-04-09 23:00:38

joan
Admin
Offline

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.

25 Reply by Reiner 2019-04-10 11:15:59

Reiner
Member
Offline

Hi Joan,
thanx a lot. It's a good idea to switch the windows. i will try it.

26 Reply by laskowskimaciej 2019-04-14 11:52:14 (edited by laskowskimaciej 2019-04-14 12:06:37)

laskowskimaciej
Member
Offline

Hi Joan

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 "+")

27 Reply by crnkoj 2019-04-18 20:58:15

crnkoj
Member
Offline

Hey is it possible to use more than 2 cameras at once for simultaneous recording, couldnt really find the option anywhere.
Would like to have 3 (both sides and back/front) or 4 (both sides, back and front) for Gait and Bicycle analysis.
Thanks

28 Reply by joan 2019-04-20 19:26:00

joan
Admin
Offline

laskowskimaciej wrote:

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.

crnkoj wrote:

Hey is it possible to use more than 2 cameras at once for simultaneous recording, couldnt really find the option anywhere.

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

29 Reply by Waheeden 2019-04-29 04:42:52

Waheeden
Member
Offline

Hi Joan,
I have a few more questions/comments about bandwidth bottlenecks and resulting frames/sec in Kinovea 8.27.

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.