Great tutorial. Followed this to get my setup working. Only issue I have is my 2MP ELP camera is really bad. Looks like I need something at 180+ fps
2021 Primer on Dual High-Speed Video Recording of a Golf Swing
Collapse
X
-
This is something that really needed to be done. Kinovea is a pretty daunting program, and the setup is not straightforward at all (things like "Drawings Tab: tick Opacity box so drawings are visible for entire video"). I got set up yesterday, and had to work off several different old threads when getting things up and running. This really captures the basics very cleanly. Great work!
The thing that surprised me was that my laptop is DEFINITELY being taxed when recording and playing back in 2 separate instances - and I have an almost new MSI GP66 gaming laptop.
Core i7-11800H 8 Core
16GB (8G*2) DDR4 3200MHz
My issue thus far:
- When scrolling through replay in a second Kinovea instance - the video often cuts out / misses frames / freezes
- When recording - the frames don't sync perfectly like I would expect (one camera is ~0.1 seconds ahead of the other). Each time I have to manually go frame by frame and sync the two views.
Comment
-
Snipe - did changing the exposure setting(s) fix all of your issues? I'd be curious what the specified requirements are for the Kinovea software you are using if you have an i7 - 8 core and 16 GB of RAM and are still having problems? Is your computer hard drive SSD and which brand? Working with tons of video would probably require SSD of some form to handle the rapid transfer of data from storage as you are working with it.
Comment
-
I'm running an MSI GP66 Leopard I bought recently at Costco:Originally posted by Brettster View PostSnipe - did changing the exposure setting(s) fix all of your issues? I'd be curious what the specified requirements are for the Kinovea software you are using if you have an i7 - 8 core and 16 GB of RAM and are still having problems? Is your computer hard drive SSD and which brand? Working with tons of video would probably require SSD of some form to handle the rapid transfer of data from storage as you are working with it.
https://www.costco.com/msi-leopard-g...100792120.html
It has a 1TB NVMe Solid State Drive.
I'm only recording 1.5 second clips - though I do have 2 instances of Kinovea running (one to record and one to auto-replay). The program is pretty buggy overall, but absolutely amazing given it's price tag. Just an amazingly generous piece of kit.
Issues that persist:
- Playing back video chokes pretty easily. I can't smoothly scroll through frames as it gets laggy or goes black
- The "workspaces" don't load properly. I have two cameras set up, and without fail only one loads when I open the program. I have to manually go in and start the second
- The frames never align perfectly. I *think* it's either because of slight variations with stream rates - or perhaps the program has to give the capture sequentially instead of in parallel? Idk - but I never get frames that align perfectly
Overall I'm extremely impressed with the cheapo setup and amazing program, but that doesn't mean I don't want seamless perfection.
Comment
-
This is usually an available RAM issue. You can adjust the allocated RAM in the settings under Playback. Be careful though, depending on the file size of each playback you may need to increase system RAM. Otherwise, I would check the CPU utilization while you fast scrub a playback and see if you are peaking the CPU.Playing back video chokes pretty easily. I can't smoothly scroll through frames as it gets laggy or goes black
I actually use three windows because I could never get them to sync in only one playback instance. Free is nice though rightThe frames never align perfectly. I *think* it's either because of slight variations with stream rates - or perhaps the program has to give the capture sequentially instead of in parallel? Idk - but I never get frames that align perfectly
Comment
-
Thanks for the tips. I'll take a look at CPU Utilization and see if perhaps 3 windows works better for me.Originally posted by preludesam View Post
This is usually an available RAM issue. You can adjust the allocated RAM in the settings under Playback. Be careful though, depending on the file size of each playback you may need to increase system RAM. Otherwise, I would check the CPU utilization while you fast scrub a playback and see if you are peaking the CPU.
I actually use three windows because I could never get them to sync in only one playback instance. Free is nice though right
I've experimented with increasing the allocated RAM (I believe) - as I was testing with recording longer clips. It didn't seem to help with the choking, but I'll give it another shot as well.
Unfortunately there's not much I can do if the CPU ends up being the problem (I don't think?). I've tried prioritizing Kinovea in the task manager but that didn't seem to do much either.
I'm not super comfortable on PC anymore as I've been on Mac exclusively for the last 12 years - but I'm trying!
Comment
-
Some recommendations on the setup of Kinovea:
Recording instance of Kinovea- Always use ONE instance of Kinovea for each camera. To my experience, the 2 camera mode doesn’t work correctly. The total CPU-load is even lower if you use one instance for each camera. Loading of each camera using the workspace function works perfect if 2 instances are used.
- In high FPS-recording always use uncompressed video AVI or MKV. If one camera is rotated, use MKV. The metadata of the AVI-files do not have information on the rotation and will be displayed without rotation. I use it for the down-the-line camera to get a better aspect ratio.
- Setting recording mode to retroactive (options/preferences/capture/recording) will allow Kinovea to record the video to memory without any disk writing activity during recording.
- To replay 2 videos a dual replay mode in one Kinovea instances may be used to display the 2 videos side by side. In general the cpu-load for replay is rather low. Also memory allocation is not a topic
- Try to activate „use motion synchronization mode“ (Options/preferences/playback/general) to get them synchronized
The power of your notebook seems to be high enough to record 2 videos at the same time.
Using an I7 CPU, one recording instance of Kinovea in retroactive mode will take about 30% CPU load, a dual replay about 10-15% or even less.
Also your USB-controller is an USB 3.2 that will deliver enough bandwidth to transfer the videos from the camera to the computer.
Use a direct USB-connection from each camera to the computer without any hub in between. Check if the USB-cable is of high quality or maybe faulty.
So far, there is no information of your camera specifications. I suggest they are USB2. What is the stream format, image size and frame rate you could set? In general, the exposure time should not be of a concern and will not influence the consistency of the video if it is shorter than 1 second divided by the number of frames/second. Example: 180fps -> exposure time should be below 5555 microseconds. Inconsistency mainly is created when frames are dropped during recording.
Go a step by step procedure to be sure that the setup for each single camera works fine.
First of all, deactivate any background tasks like Virus scanner during the tests. They may interfere with the setup.
Use the newest Kinovea version (0.9.5)
Start with only one camera in 1 instance of Kinovea and repeat it with the second camera.
During recording, take a look on the title bar of the recording window and check if the signal of your camera is what you have set in the camera settings (wrench icon) with respect to SIGNAL. Does it show the same fps?
The „throughput“ should not be over 300-400MB/s, otherwise it may be over the transfer limit.
To my experience most important is the dropping rate. If there are any drops during recording, the resulting video will not be as expected due to missing frames. If there are any drops, reduce the frame size, the fps-rate of the camera or switch to monochrome (if it is available in the camera settings)
Check the resulting video frame by frame in a Kinovea replay instance to see if the video runs as expected.
Check the CPU-load of one recording instance.
Finally try to use all instances together and check if the above parameters work the same.
Hope that helps
Comment
-
Well the professionals arrived. Thanks Reiner!
-
Thank you so much for this.
As I started to work through your suggestions, I realized that the choppiness seems to be an issue only with Replay Observer.
If I open two videos in a new replay window - they scroll just fine.
If I allow Replay Observer to open the same two videos - scrolling between frames becomes choppy / laggy / black / etc.
The cameras I have currently are ELP OV4689 (1280X720 MJPEG@ 120fps).
I believe I should be recording uncompressed MKV (Options > Preferences > Capture "Record uncompressed video" is checked and Uncompressed Video Format is MKV". HOWEVER - the files generated appear to be MP4 format in File Manager - but when I try to play them I get a message that "Can't play - This item was encoded in a format that's not supported. 0xc00d5212". I am able to play any videos I export as MP4 or MKV. Is this just a quirk of Kinovea?
Obviously I have quite a bit to test yet - but thank you so much!
-
Don’t really understand the situation completely.
1.
did you open the 2 videos independently and separately in a single replay window and they work fine or did you use a 2 panel replay (left and right panel to replay) opening one video on the left and one on the right?
There might be a synchronization problem. Try to open a dual panel replay, load one video on the left, the other on the right panel.
deactivate synchronization in preferences.
Activate the display of frames and time (preferences/playback/units top dropdown-list „time“, last entry).
Are the values of fps (both title bars) and duration/frames (i.e. 2.50 (78)) nearly are the same?
You will have 3 play-buttons. If you play the videos independently using the play button below each video, does it replay correctly?
Clicking the play-button on the common-control (below both videos) should show the observed behavior.
Finally, if any *.kva file is related to the video (with the same filename, i.e.: video1.mkv and video1.kva) rename the kea-files of both videos and reload them again if there is any difference.
Do you have an opportunity to upload both example files? It would be interesting to see evaluate the properties.
2.
What do you mean by „the files generated appear to be MP4 format in File Manager“ ? The file extension should be MKV or AVI for uncompressed video.
What program gives you the error message of „unsupported format“. Is it the default window-program that plays videos?
The file extension doesn’t mean all in video formats. It is called the container format (i.e. MP4,AVI,MKV), but the encoder may be different inside each container. Kinovea uses 2 codecs: mjpeg for compressed files (MP4,AVI,MKV) and rawvideo for uncompressed files (AVI,MKV).
Not all common video-player may play videos that have a "mjpeg" or „rawvideo“ codec. Therefore, in general, the standard window video player cannot replay uncompressed videos from Kinovea. You may use VLC, it plays most of the formats available.
3.
Did you check the videos if they are recorded in 2 independent Kinovea-instances?
Comment
-
Don’t really understand the situation completely.Originally posted by Reiner View PostDon’t really understand the situation completely.
1.
did you open the 2 videos independently and separately in a single replay window and they work fine or did you use a 2 panel replay (left and right panel to replay) opening one video on the left and one on the right?
There might be a synchronization problem. Try to open a dual panel replay, load one video on the left, the other on the right panel.
deactivate synchronization in preferences.
Activate the display of frames and time (preferences/playback/units top dropdown-list „time“, last entry).
Are the values of fps (both title bars) and duration/frames (i.e. 2.50 (78)) nearly are the same?
You will have 3 play-buttons. If you play the videos independently using the play button below each video, does it replay correctly?
Clicking the play-button on the common-control (below both videos) should show the observed behavior.
Finally, if any *.kva file is related to the video (with the same filename, i.e.: video1.mkv and video1.kva) rename the kea-files of both videos and reload them again if there is any difference.
Do you have an opportunity to upload both example files? It would be interesting to see evaluate the properties.
2.
What do you mean by „the files generated appear to be MP4 format in File Manager“ ? The file extension should be MKV or AVI for uncompressed video.
What program gives you the error message of „unsupported format“. Is it the default window-program that plays videos?
The file extension doesn’t mean all in video formats. It is called the container format (i.e. MP4,AVI,MKV), but the encoder may be different inside each container. Kinovea uses 2 codecs: mjpeg for compressed files (MP4,AVI,MKV) and rawvideo for uncompressed files (AVI,MKV).
Not all common video-player may play videos that have a "mjpeg" or „rawvideo“ codec. Therefore, in general, the standard window video player cannot replay uncompressed videos from Kinovea. You may use VLC, it plays most of the formats available.
3.
Did you check the videos if they are recorded in 2 independent Kinovea-instances?
1.
did you open the 2 videos independently and separately in a single replay window and they work fine or did you use a 2 panel replay (left and right panel to replay) opening one video on the left and one on the right?
================================================== ============================
[I opened the two videos independently and separately in a 2 panel replay (single Kinovea instance using the “Dual Display” icon) and opened one video on the left and one on the right.
================================================== ============================
There might be a synchronization problem. Try to open a dual panel replay, load one video on the left, the other on the right panel.
deactivate synchronization in preferences.
Activate the display of frames and time (preferences/playback/units top dropdown-list „time“, last entry).
Are the values of fps (both title bars) and duration/frames (i.e. 2.50 (78)) nearly are the same?
================================================== ============================
The sync issue seems to be during recording
The FPS on the title bars are both the same
The Duration / Frames are both the same
================================================== ============================
You will have 3 play-buttons. If you play the videos independently using the play button below each video, does it replay correctly?
Clicking the play-button on the common-control (below both videos) should show the observed behavior.
================================================== ============================
When I load a previously recorded video (aka not the most recent video which the Folder Observer is automatically replaying) everything is smooth and I can scroll through the frames both forward and backward.
When working with the most recently, automatically loaded video (via Replay Observer):
If I play the video forwards it plays fine
If I go frame by frame FORWARDS (with any of the 3 forward frame control buttons) it works just fine
If I try to reverse frames either by clicking the back frame button or scrolling back - the lag gets very bad - and one screen usually goes black for a bit.
Here are two videos of the same file.
Played automatically with file observer directly after recording:
Played after being reloaded via Kinovea side window file browser:
(Don’t judge the swing or hair too harshly. I’m making some swing changes trying to fix some old, deeply ingrained habits, and have been putting off getting a badly needed haircut)
================================================== ============================
Finally, if any *.kva file is related to the video (with the same filename, i.e.: video1.mkv and video1.kva) rename the kea-files of both videos and reload them again if there is any difference.
Do you have an opportunity to upload both example files? It would be interesting to see evaluate the properties.
================================================== ============================
What do you suggest as the best way to upload?
================================================== ============================
2.
What do you mean by „the files generated appear to be MP4 format in File Manager“ ? The file extension should be MKV or AVI for uncompressed video.
What program gives you the error message of „unsupported format“. Is it the default window-program that plays videos?
The file extension doesn’t mean all in video formats. It is called the container format (i.e. MP4,AVI,MKV), but the encoder may be different inside each container. Kinovea uses 2 codecs: mjpeg for compressed files (MP4,AVI,MKV) and rawvideo for uncompressed files (AVI,MKV).
Not all common video-player may play videos that have a "mjpeg" or „rawvideo“ codec. Therefore, in general, the standard window video player cannot replay uncompressed videos from Kinovea. You may use VLC, it plays most of the formats available.
================================================== ============================
I changed the Video Format to MKV and now it records uncompressed MKV by default - but there is no difference in performance.
Previously I had “Record Uncompressed By Default” checked - and I had “Uncompressed Video Format” dropdown set to MKV. However I had “Compressed Video Format” set to MP4. For some reason, it was recording in MP4 format (though Windows Media Player still would not recognize them directly from Kinovea. However - if I exported the video as MP4 - Windows media player recognized the files. Very odd but unimportant I guess)
================================================== ============================
3.
Did you check the videos if they are recorded in 2 independent Kinovea-instances?
================================================== ============================
Yes - no difference.
================================================== ============================
Comment
-
Could reproduce the situation.
There is a difference of how Kinovea is reading and playing videos in „pure“ replay mode and observer mode.
If you actively load the videos to a replay window they are loaded fully into memory (a status bar occurs during reading). During scrubbing back and forth, Kinovea can load and display each single frame from memory. Therefore, the performance of the ssd is of no interest.
Using observer mode, the video remains on the disk and each frame is read sequentially.
Suggestion:
As the log.txt file shows, Kinovea is using a prebuffer to read some frames in advance (in forward direction). So if you scrub backwards, the actual position inside the video changes and triggers a new read of a prebuffer with each step backwards.
That may cause a delay and black frames due to that Kinovea still is working to load the frames of the forward prebuffer.
Prebuffering works perfect if you are scrolling forward. The next (expected) frames are already loaded to memory and can be displayed very fast.
So far I didn’t realize this behavior, perhaps due to using an i9 CPU and a second very fast NVM-SSD to store the videos (MSI Z390 mainboard).
To overcome the situation it might be better to click back on a desired position and start replay in forward mode.
Comment on the setup:
To reduce the replay speed it might be advantageous to use the fps-reduction property in options/preferences/capture/recording, setting the „framerate replacement threshold (fps)“ below the fps you are recording (in your case i.e. 90, see next paragraph) and the „replacement framerate (fps)“ to 30. That will reduce your replay speed to better visualize your swing.
The fps that is shown in the replay window doesn’t really mean that the recording has been performed of this speed. It rather is the signal the camera gives to Kinovea. However, in USB2-cameras the value might not be correct.
Look in the camera instance what is shown on the title bar on „signal“. This fps value is the real fps the camera records the video.
Comment on Export
If you export a video from the replay window, the created file is compressed using the codec: mpeg4
This codec can be read by most of the video players.
The original MP4-file has the codec „mjpeg“ and cannot be read by windows media player
The reason is that mjpeg stores each frame (single image) of the video in its original form. Therefore, it is much faster to display each frame of the video because it is already in a final format.
The mpeg4 codec stores differences between frames. So to display a specific frame, the keyframe „before“ the actual frame has to be searched and every change has to be calculated to get the full frame at a specific position.
Comment
-
Thank you. Would any hardware upgrades be worth looking into or would I essentially need to buy an entire new rig?Originally posted by Reiner View PostCould reproduce the situation.
To overcome the situation it might be better to click back on a desired position and start replay in forward mode.
Typically my signal shows ~120 FPS. I'm not sure I understand the value / impact of the fps-reduction property - but will give it a shot to see if it's useful. Thank you.Comment on the setup:
To reduce the replay speed it might be advantageous to use the fps-reduction property in options/preferences/capture/recording, setting the „framerate replacement threshold (fps)“ below the fps you are recording (in your case i.e. 90, see next paragraph) and the „replacement framerate (fps)“ to 30. That will reduce your replay speed to better visualize your swing.
The fps that is shown in the replay window doesn’t really mean that the recording has been performed of this speed. It rather is the signal the camera gives to Kinovea. However, in USB2-cameras the value might not be correct.
Look in the camera instance what is shown on the title bar on „signal“. This fps value is the real fps the camera records the video.
This is really interesting. Thank you for the help and context!Comment on Export
If you export a video from the replay window, the created file is compressed using the codec: mpeg4
This codec can be read by most of the video players.
The original MP4-file has the codec „mjpeg“ and cannot be read by windows media player
The reason is that mjpeg stores each frame (single image) of the video in its original form. Therefore, it is much faster to display each frame of the video because it is already in a final format.
The mpeg4 codec stores differences between frames. So to display a specific frame, the keyframe „before“ the actual frame has to be searched and every change has to be calculated to get the full frame at a specific position.
Comment
-
Snipe
Checked the observer mode on different machines (i5,i9,Virtual machine Parallels on a Mac, which is rather slow, also using SSD and regular hard disk) but could not reproduce the delay.
So there might be something in the videos your cameras are creating.
Send you a PM with a link to upload videos for further evaluations.
Comment
-
Hi Snipe,
have observed your videos converting the following parameters singular and in each combination.
The following parameters have NO effect, the delay remains more or less the same:- converting mjpeg (compressed video) to rawvideo (no compression)
- change the pixel-format from yuvj422p to yuv420p
- reducing the frame rate of the RESULTING video from 120fps to 30fps (factor of 4)
So it seems to be important to use the fps-reduction in
preferences/Capture/Recording:
set the replacement threshold BELOW the value you are recording (in your case below 120fps)- frame rate replacement threshold (fps): 100
- replacement frame rate (rps): 30
This results in a correct display of your Kinovea-timeline and will reduce the timeline back to 1.5x seconds, showing the correct length.
To control the correct number of frames, you may select the last item in the dropdown-list in preferences/playback/units/time, showing time and frame number.
One further remark:
To prevent frames dropping during recording, use the „retroactive“ mode in preferences/capture/recording
The CPU-load will increase but will stay similar. So it is a valuable check to see if the CPU-power is high enough if both cameras are active.
The main effect is that this setting prevents any interference with hard disk writing during recording.
Let me know if that works for you
Comment
Comment