Re: Experimental version - 0.8.27

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!

Re: Experimental version - 0.8.27

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.

Re: Experimental version - 0.8.27

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.

Re: Experimental version - 0.8.27

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!

Re: Experimental version - 0.8.27

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

Re: Experimental version - 0.8.27

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!

Re: Experimental version - 0.8.27

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.

Re: Experimental version - 0.8.27

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

Re: Experimental version - 0.8.27

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.

Re: Experimental version - 0.8.27

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

26 (edited by laskowskimaciej 2019-Apr-14 12:06:37)

Re: Experimental version - 0.8.27

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

Re: Experimental version - 0.8.27

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