1 Reply by Waheeden

(17 replies, posted in Cameras and hardware)

Here's a OV2710 and OV4689 comparison clip running in Kinovea 9.1:

https://youtu.be/1OFAEtGBfSI

OV2710 (170deg lens 640x480 120fps) vs OV4689 (180deg lens 1280x720 120fps - running fixed frame rate firmware that I got from the Kayeton sales rep)

I purchased two KYT-U400-01FEM cameras on AliExpress.  They were described as:
"High Speed 330fps 120fps 720p 60fps 1080p Fisheye Wide View Angle 180degree UVC OTG USB Camera with Case"

Cameras are about 5ft from the ball.  The 180deg lens is only necessary with the long shaft of the driver.  For 3W and shorter clubs, the 170deg lens can capture the full swing.

Each camera records in its own instance of Kinovea 9.1.  Both cameras deliver a true frame rate of 99fps (as verified with the running clock in the foreground, and the frame counter in the replay window: 247 frames / 2.5 seconds = 99fps). Watch in HD to see this info.

Go to forum: Cameras and hardware

2 Reply by Waheeden

(33 replies, posted in General)

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

Go to forum: General

3 Reply by Waheeden

(36 replies, posted in General)

Joan, Kinovea 9.1 is amazing! All of the issues in 8.27 are resolved and it does everything the old AutoIt script we used before did, but better. The automation runs flawlessly, the embedded microphone trigger and delay is such a nice improvement, OV4689 cameras deliver a true 100fps at 1280x720, etc.

I'll post a sample clip of OV4689 vs OV2710 in the OV4689 topic since the OV4689s work for me, but apparently not everyone.

Thanks again!

Go to forum: General

4 Reply by Waheeden

(33 replies, posted in General)

Reiner wrote:

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.

Go to forum: General

5 Reply by Waheeden

(33 replies, posted in General)

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.

Thanks again!

Go to forum: General

6 Reply by Waheeden

(33 replies, posted in General)

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!

Go to forum: General

7 Reply by Waheeden

(33 replies, posted in General)

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!

Go to forum: General

8 Reply by Waheeden

(33 replies, posted in General)

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!

Go to forum: General

9 Reply by Waheeden

(33 replies, posted in General)

joan wrote:

Hi,

It is the expected behavior for now. It's a trade off. When recording what is displayed on screen the images go through the delay buffer, painting pipeline (drawings and compositing) and generally undergo more conversions.

The two main use cases considered are live feedback and high speed capture. In order to support both as best as possible they are treated separately and optimized differently. So unfortunately doing live feedback on a high speed stream is going to suffer in one way or another.

The framerate you see is most probably the "display" framerate which is set on Preferences > Capture > General tab (25 fps by default). This is what gets saved when recording is set to display (a.k.a what you see is what you get). The other frames aren't pushed to the delay buffer in the first place.

You could try to increase it and see how high you can go. I don't remember if it's capped to the monitor refresh rate on the top of my head. I'm curious to see if you can get it to 300fps and where the bottleneck is, please report your results!

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.

Hi Joan,
Thanks for Kinovea - it is an amazing tool!  I've been using Kinovea with Inokuo's AutoIt golf swing recording script.  Instead of the standard two OV2710 cameras, I am using two OV4689 cameras recording 100fps at 1280x720 on a 4 second delay. I updated the camera firmware with a fixed framerate version so there are no drops.  With the "Display Framerate" set to 100fps, I get a steady maximum of 32fps in this "Two Capture Screen" configuration.

I rewrote Inokuo's script to take advantage of the "Allow Multiple Instances of Kinovea" option.  Two Kinovea windows are both recording 1 camera feed each.  With this configuration, I get double the previous framerate, which turns out to be 64fps.  This is pretty close to the 60Hz screen refresh rate you mentioned as the possible upper limit for delayed recording.  I have two questions:

1) If I used a 120Hz display, would you expect Kinovea to display the full 100fps that the camera is putting out?

2) Perhaps 1 out of 10 swings while running the 2 instance configuration, Kinovea gives me an "Unhandled Exception - The process cannot access the file 'x.xml' because it is being used by another process".  My guess is that the two Kinovea instances are trying to access the same file at the same time, but it could also be a timing problem in the AutoIt script.  I added the log file in the bug tracker (Issue #421).  Do you know what could be causing this issue?

Thanks!

Go to forum: General