Topic: Experimental version - 0.8.24

Experimental version. As always feedback is very appreciated! wink
Beware of regressions and report anything suspicious. Do not assume the issue is known.


Special thanks to Milan Djupovac and the folks at Sport Diagnostic Center Šabac (Serbia) for the ongoing testing and support of this version.
And many thanks to the Jumpers Rebound Center in Gillingham (UK) who donated a Microsoft LifeCam Studio for testing purposes.
And also many thanks to DVC Machinevision BV (Netherlands) for the super deal on the Basler camera many months back.


This release is almost entirely about cameras and capture.

  1. Improved capture performances and camera configurability

  2. Support for Basler cameras.

  3. Capture history.

  4. Other goodies.

1. Improved capture performances and camera configurability
This has taken the most part of the multi-month effort of this release. I also acquired 7 various USB cameras in the process and was donated one smile

Parts of the low level capture architecture were rewritten from scratch and gave birth to a new capture "pipeline" with a more direct path from the camera to the disk and an improved multi-threading model.

The camera configuration dialog is now more detailed, and lets you choose the precise stream format and framerate, configure exposure duration, gain and focus, when the camera supports it.

The maximum performance will be reached when using the MJPEG stream format with cameras that have on-board compression, as the stream will be directly pushed to the capture file without any transcoding. This should enable the capture of two full HD streams without frame drops.

On the top of the camera screen, the status bar contains new information:

  • Signal : the actual frame rate received from the camera. May or may not match the configuration.

  • Data : the bandwidth between the camera and Kinovea.

  • Drops : the number of frame drops during the current or last recording session.

The new output file format (whichever option is selected as stream input) is MJPEG inside MP4 container (not configurable).

For the live image, another change is the "Display synchronization strategy", to decouple the preview framerate from the captured framerate. I did not find a concise sentence to quickly convey all the implications of this setting, so I'll attempt to describe it in this topic.

2. Support for Basler cameras
This version introduced preliminary support for Basler high end industrial cameras, though their Pylon SDK.
I was only able to test it using a black and white camera so if you have access to a color camera please report how it works for you.

Live view, configuration and recording should all be supported.

3. Capture history
A little feature that was added almost at the last minute, but I think it could prove quite useful.
Basically each time you make a recording, an entry is saved in the history panel, and from there you can launch the videos.

Note that you can import your current capture directory (or any other directory for that matter) into the history using the button on the left. This can also be useful when you recorded a session on the camera and later dumped the SD card on the main computer.
After some threshold the days are grouped into months.

4. Other goodies
- A new tool "Test grid" under menu Image, for cameras. This can be used to assert that the camera is level, locate the center of the image, etc.
- A new timecode "total microseconds" and the ability to select up to one million fps in the high speed camera dialog. For those users that have really high speed cameras.

A number of defects were fixed and even more things were crammed in, please check the raw changelog.


Re: Experimental version - 0.8.24

It is our pleasure to work with Joan and Kinovea community, Kinovea is such great piece of software, we use it daily and we have best words about it. We stay at disposal for further testing and development. One more time all regards from SDCS Team.

Re: Experimental version - 0.8.24

I forgot to mention an important change in the way the recording works with regards to the delay feature.

In previous versions of Kinovea, when you started the recording, you would record what was visible on screen. If you had delay in place of say 10 seconds, then the first image of the resulting video would be 10 seconds earlier than the time you pressed record.

This is no longer the case due to the decoupling of the preview and the recording. This means that the configured delay is no longer taken into account when recording. You always record the "live" feed. Minus the base latency between the camera and the computer memory (which depends on the selected stream format by the way).

Re: Experimental version - 0.8.24

Hi Joan,

These changes look great, thanks for the latest updates!

You previously mentioned that you were considering adding angle-angle plots to the data analysis tools, is there any progress on this? I am very keen to be able to track simple movements, for example a squat exercise and display angle-angle plots for joints like the hip and the knee. There are obviously quite a few applications in gait where the plots would also be useful.

Thanks again

Re: Experimental version - 0.8.24

Many thanks to Joan for the latest version of Kinovea. The ability to make use of hardware compression in the Logitech C920 is very welcome and eases the bandwidth requirements very significantly. In my measurements the data rate decreases by an order of magnitude for this camera. Of course this does not solve all the problems associated with using multiple webcams. I would like to mention a couple of long standing problems and suggest possible modifications to address them.

First let me briefly describe my hardware and use to illustrate the problems although they impact multiple scenarios. For swimming coaching in an Endless Pool, I have an underwater camera connected to a USB rame grabber which runs at 25 fps which is fixed as this is a PAL device. In addition there is a Logitech C920 above the pool and a Microsoft webcam with a front view. Together they allow a three dimensional view of the swimmer. Simultaneous recordings of different pairs of cameras are extremely useful in coaching technique.

The two webcams will only reliably run at 15 fps due to the poor lighting level with auto exposure (auto exposure is useful because of varying lighting levels day/night). This is fast enough for this application and recordings can be made with no dropouts or missing frames with all possible camera pairs at all light levels. The underwater camera provides its own lighting and always achieves good performance at 25 fps.

The first problem is associated with playing back video which is normally done in the 2 playback window mode. There are numerous discussions in the forums about slow playback rates but to illustrate the problem imagine recording 60 seconds of video and then playing it back. Opening video from the two webcams (15 fps) reveals a recording length of 30 seconds whilst the underwater camera (25 fps) video duration is 50 seconds. Clearly Kinovea thinks that all the videos were recorded at 30 fps. I note that the C920 always reports a frame rate of 30, the underwater camera does report 25 fps and I am not sure what the Microsoft camera reports. In all cases Kinovea creates video which includes a frame rate of 30 fps and then plays it back faster than realtime.

When viewing video from the two webcams the problem with linked controls there is not a real problem since the speed can be set to 50% and all is well. When playing video from one webcam (15 fps) and the underwater camera (25fps) then one must unlink the controls to set the appropriate speeds which is not very convenient.

Since Kinovea knows the frame rate selected by the user (even if the camera does not report the selected frame rate correctly), would it be possible to tag the video with the correct frame rate? This would, I think, cause the video to playback at the correct speed. There might be a problem for the underwater camera for which the device properties in the latest version of Kinovea no longer show the frame rate. Previous versions allowed one to select 25 or 30 although this had no effect since it is determine by the camera hardware.

The second problem is really just a long standing inconvenience but since I have spent so long explaining my setup, it can usefully be summarised here. In the two recording mode, one can set the file names to be free text plus auto incrementing number and then set the video names to be something like "John_Camera_A - 1" and "John_Camera_B -1". Subsequent recordings increment the numbers and all is well.


if you playback the videos and the return to recording, the video file names become the same in the two recording windows e.g. both are "John_Camera_B -8". Clearly the recording name is remembered but there is no provision for the two recordings mode (or it is not read back correctly). It would be very helpful if this could be fixed and might not be too difficult to achieve. Don't you hate it when people say that!

I apologise for the length of the post and perhaps not posting it in the correct place. I would like to say that Kinovea is extremely useful tool and to thank everyone who has contributed to its development.

Re: Experimental version - 0.8.24

Thanks for the detailed message.
I'll try to recap. I think you have correctly identified the various causes. I'll just repost them here for clarity.

1. Framerate mismatch due to auto-exposure.
Kinovea uses the camera configuration information to write the framerate in the file. So if the camera is configured for 30 fps but due to Auto Exposure only actually streams at 15 fps, the resulting video will be sped up.

2. Framerate mismatch due to using a default value.
Kinovea probably cannot read the configuration of the frame grabber. When you go in the configuration dialog do you have the framerate drop down available ?

3. Issues with dual mode when one or both of the videos have a mismatched framerate.
Both videos do not share a common truth for what they consider real-time.

Possible solutions:

  • A. At playback time, being able to correct the information written into the file with a user provided value. I think this is what you propose. I like this idea because it would open other use-cases as well. There are caveats though.

  • B. At record time, write the "signal" value to the file. This value is the computed framerate from the actual stream. It is smoothed over a time window but still subject to noise and variation from auto exposure. I don't particularly like this option because it will result in a lot of files marked as 29.99 fps or 30.01 fps, even though the frames were actually captured by the camera at the correct frequency. The noise is coming from various buffers on the computer side.

  • C. At record time, ask the user to specify a value. This could disrupt the recording workflow.

Caveats of A:
How do you know the actual recording framerate? It depends on the current exposure duration and may change during the recording if exposure is on Auto. It is not always 1/exposure duration anyway (Logitech and Microsoft cameras differ on their strategy here).

There will be a confusion possible between this and the high speed camera dialog which only changes timecodes.

4. Naming pattern for dual cameras
I completely agree and I have been experiencing that very same annoyance myself recently while filming sterescopic videos.

There are other improvements to be had in this area. I'd like to
- be able to specify separate capture directories (to be able to record on two different drives in parallel for performance),
- make it easier to change the capture directory,
- be able to use macros in the directory path so they get named with the date automatically
- have separate prefix/suffix for left/right cameras, etc.
I'll probably start another thread for this to brainstorm ideas.

Re: Experimental version - 0.8.24

Many thanks for your considered reply. On the issue of the recording frame rate I do think that your option A would provide the most utility. Whilst it does rely on the user have set the most appropriate frame rate (one that encompasses any auto frame rate adjustment likely to be encountered), they are very unlikely to be any worse off than at present. With the correct choice of frame rate then playback speed will be correct which is something that can at present only be achieved if the user's cameras can all achieve 30 fps. I do agree that B and C are perhaps not the best way forward for the reasons you indicated.

In my use case where I wish to make recordings in a swimming pool which has both artificial and natural light so the illumination can change significantly. Auto exposure is useful because it removes the need for adjustments before recording and I have carried out test which show that 15 fps can be achieved even at night. So option A would be the ideal solution.

I think the situation may be slightly more complex than cameras not reporting actual frame rates. As far as I can see all cameras, including the camera simulator running at 50 fps, result in recordings which have the frame rate set as 30fps, irrespective of the actual frame rates. This according to the tool I used to reveal the video parameters in the recordings. This is, I think, why so many people report problems with playback speeds. I wonder if this is a default setting which is always used?

On the naming pattern for dual cameras topic and specifically the last point:
- have separate prefix/suffix for left/right cameras, etc.
I am uncertain if by left/right you mean a camera alias or the left and right recording windows. I think you mean left/right camera as in stereoscopic.

My suggestion would be the capability to include the camera name or an alias, in the file name. I recall that there was once a capability of assigning an alias to each camera but I can no longer find how to do that. If I could rename/alias my three cameras to be identified as top, front and underwater, and then include that in the filename along with the auto-incrementing number then I think it would make things much more convenient. This would then work whichever way around the cameras appeared in the dual recording window. In the perhaps unusual situation where one is recording two of a possible three or more cameras, then if the incrementing number might refer to the recording rather than the individual camera. So if I recorded my swimmer John with different pairs of cameras I would end up with:
   John_(top)_1 and John_(front)_1                 recorded at the same time, then
   John_(front)_2 and John_(underwater)_2     then,
   John_(underwater)_3                                  just using a single camera, then
   John_(underwater)_4 and John_(top)_4       and so on
Inspection of the file names then allows me to identify which files go with which, the order in which they were made and from which camera the recording originates. I think that some form of suffix is better than a prefix because in this example it allows me to separate all John's recordings from those of Jane. It is the subject that is more important than the camera used so the naming hierarchy should be subject > camera > time

I do not think that there are any downsides to this scheme for the more normal one or two camera use.

Apologies for the length of this post and many thanks for all your hard work on Kinovea.

Re: Experimental version - 0.8.24

It's been quite some time since I've been able to get involved with this wonderful tool and now that baseball season is upon me I'm back full swing. smile    I love cutting edge things so loaded version .24 but have noticed some minor problems.  I opened my video file and when I hit play the position slider jumps forward then backwards as it travels to the end of the video.  It's really pronounced when I shortened the video clip to something that's small (10 seconds long) and it really jumps!  When I open the second playback screen sometimes I can only play the video on the left, sometimes the one on the left will play for 4 seconds and the one on the right will play just fine and other times I can' t play either video.  I've tried changing the videos and mixing them up but playing 1 video on 1 playback screen works fine.  Also, when I set the working zone to a specific point there are times when I can't get the video to start from the beginning.  Other times I'll slide the position bar to the beginning of the video and then will hit play and the video starts from where it left off and didn't go to the beginning. Other times I'll try sliding the position bar in the working zone all the way to the left but it won't go to the beginning of the video.

Otherwise I love this tool!

Re: Experimental version - 0.8.24


I don't think this will help but I saw this type of behaviour when I first installed this version. Subsequently I reinstalled and set the frame rates to appropriate values for my setup. After that it has been well behaved with recordings playing back correctly both individually and two together. I have no idea what caused the initial problem but suspect that it was deleting everything I could find associated with Kinovea and then installing again. Might be worth trying again.

Re: Experimental version - 0.8.24

Oh, I completely missed the messages from April 30th and May 1st, sorry.

@gollum: I'll double check the issue with exported framerate. I did several tests where it worked and properly recorded the framerate. I have to check if the value written at the codec level is the same as the value written at the container level.

Regarding naming, thanks for the examples, it helps. Yes, being able to include the alias of the camera in the filename is a must-have.

For auto-incrementing counters, maybe there should be several of them. One global counter that increments whenever a video is recorded, then screen-specific counters, or maybe a global counter that is dual-camera aware and only increment once, and then maybe camera-specific counters.

It would also probably be nice to be able to manipulate the current value of the counters beside just reset.

To change the camera alias you can:
- Right-click the thumbnail and choose "Rename".
- Inside the camera configuration dialog, directly edit the alias (blue text). I always wondered if this hidden editbox was hard to discover, I have my answer. Maybe an explicit rename button would be more usable.
Note that you can change the icon by clicking on it in both dialogs.

@cmdi035: I have seen this effect with some H.264 encoded content, is it your case? I don't have a solution at the moment. The images themselves should be in the correct order but the timestamps are all mangled which is why the cursors jumps back and forth, and why there are issues with seeking.

Re: Experimental version - 0.8.24

Ahhh.   Yes - it was H.264 content.   I'm ok with the cursor jumping around but the biggest challenge is when there are 2 playback screens and I can't get one to play the video.   

A couple of suggestions or possible feature enhancements: 
1) is there a way to include a "flip" option similar to the mirror option?  Sometimes when I use my Samsung Note 4 to record the video it doesn't automatically orientate the video and when I play the video it's upside down.  I see you have a "mirror" option but would like to see if you can add a "flip" option. 
2)  for the drawing tool, is there a way to make the circle smaller?  It's pretty big and for some highlights I'd like a smaller radius that's about half the size of what's used now
3) is there a way to have the entire video loaded into memory so when we slide the cursor left and right the video advances accordingly?  I use the tool for analyzing baseball swings and many times I'll set the camera up and just record the whole inning.  I'd like to be able to use the cursor advance to find the place in the video where the swing occurs. 


Re: Experimental version - 0.8.24

Joan, many thanks for pointing out how to add an alias for a camera. I do not think this is a failure of the interface but more a failure of the user (me)! Being able to add the alias to the file name would be helpful to allow the workflow described below.

I have been experimenting with video formats and have noticed several things which I will attempt describe. I am, however, not well informed about video which appears to be very complicated and I clearly do not understand many things! So let me concentrate on the situation in which I use Kinovea to record from a webcam at a fixed frame rate of 15 fps. I would like to be able to import this into Windows Movie Maker (I realise that this may not be the best application but is one with which I am familiar) and for it to play at the correct speed.

So this file will play at the correct speed in VLC on a Mac. It plays at double speed in VLC under Windows 7 and in Kinovea. The container is marked as 30fps but since the Mac at least, will play it correctly the individual timestamps on frames must be "correct". I would conclude that the codec in Windows fails to interpret the video correctly. I have messed with alternative codec packs with no success but I don't really know what I am doing.

If I transcode the file to mpeg, wmv or avi, I can then import the file into Movie Maker although it still plays at double speed. But if I use ffmpeg to transcode I can also change the frame rate so the file can be imported into Movie maker and will play at the correct speed. This file also plays at the correct speed in Kinovea. The duration is doubled as expected.

I use something like this on either the PC or the Mac with the same result: ffmpeg -i Jane1.mp4 -filter:v "setpts=(30/15)*PTS  -y Jane1.wmv    (where 15 is the actual frame rate)

It is now possible for me to write a batch file to convert all the raw Kinovea files in a folder to an appropriate format and correct the playback speed. In the situation of multiple cameras running at different speeds they can all be corrected if the filename contains the camera name and I know the frame rate of each camera. It would be slightly easier if the frame rate of each camera could be included in the filename so something like, Jane_top_camera(15)_1 since the batch file could remain the same irrespective of changes to frame rates in Kinovea. I think we need two additional options in the Options > File naming > Naming pattern e.g. %c for camera name or alias if defined and %f for actual frame rate.

So this would improve the situation but I am left with questions. Why do the Kinovea recording play at the correct speed on the Mac but not on the PC? If I take my converted file and now send it back to the Mac it plays at one quarter speed. Both points are really irrelevant since I would like to do this all on the PC but my curiosity is aroused. There is clearly much I do not understand.

If anyone understands video better than me I would welcome other solutions to this issue. As always, thanks to Joan for all the hard work on Kinovea and responding to questions.

Re: Experimental version - 0.8.24

I am a regular user of Kinovea for golf self training in my basement. I use also commercial software like cSwing, V1, and tried many others. I really think kinovea is the best solution for me now, with the functionality of two cameras (I use Ps3 for the frame rate) and the delay option. So, thanks to everybody behind this project.
I was really happy with the version 8.21.  I tried in a new computer the version 8.24 and there are some improvements but two major problems in my opinion.
1) You can not set the desire format for the video as it is in the previous version. The videos are recorded in MP4 but not being readable by Windows Media player, iTunes or cSwing. I think you have to go back to version 8.21 in that regard, being able to choose for instance, AVI format
2) The new functionality of recording live instead of the delayed video (when delay is applied) I think is a step back and not an improvement!. This is a huge problem for those who like to see in slow motion a previous saved video, but not want to record ALL the swings you do, but just selected ones, (in the new version, with or without delay, one should start recording before you actually hit the ball) . Please go back to version 8.21 in this regard too, or , if some people think is better now (which I doubt), please develop an option to choose either way.
All the best

Re: Experimental version - 0.8.24


I am glad that I am not the only person concerned that the new video format is not readable by some common video programs (iTunes and Windows Movie Maker). I do not think it is not the mp4 container that is the problem but the mjpeg codec that is not supported since these programs are quite happy with other mp4 movies. For applications like ours where the speed of the computer is not a significant issue, the ability to select a different video format that is compatible with e.g. Windows Movie Maker, would be an advantage. Whilst this would presumably involve some form of transcoding, I think that modern computers should be able to handle it without problem. Perhaps we could have an mp4 container but with a compatible codec as an option?

I have never used the delayed recording so I am not able to comment on the usefulness or not of the change in this feature.

If the new recording method can help in supporting recording dual cameras then it is a major bonus. The ability to use two Logitech C920s without getting confused then it would be great!

Re: Experimental version - 0.8.24

I have posted a response to juanecorrea in the other thread here.

It would seem that it is the specific combination of container and codec that doesn't please Windows Media Player and co. Having an option to package the content inside AVI should be enough to fix the issues.