Chas Tennis wrote:

1) sometimes the magnification boxes appeared on Vimeo in different screen locations than in my computer video.  In the wrong place, they blocked video and often obscured the labels, arrows etc that were on the screen.

I think that's a bug in the export process in Kinovea that has been corrected for the next version. Same bug that was causing dual view export to not work.

Chas Tennis wrote:

2) often the Vimeo processed video would do single frame so that the faster video (say 240 fps) would advance 2 frames using the Vimeo process for single frame advance.
(...)
I contacted Vimeo about the issue of skipping frames when uploading  Kinovea videos to Vimeo.  Here is their reply.

" The original video you uploaded to Vimeo is 100 fps, which exceeds our 60fps threshold. We reduce the frame rate for all videos exceeding 60fps during our conversion process. Frame drops can occur during our conversion process in this case.

Thanks for the investigation. I can see why they would do that since most people have 60Hz refresh displays and are just playing back the videos at normal speed.
I thought Vimeo had an option for the end viewer to download the original video as a file (original framerate and without the compression), but I'm not sure.

Regarding the capping at 60fps I'm confident it is the same for YouTube.

Chas Tennis wrote:

Vimeo single frame process - Hold down SHIFT KEY & use ARROW KEYS
(...)
Youtube single frame exists - you simply use the "." and ","  keys!!

Wow, that's awesome, I wasn't aware of that!

722

(44 replies, posted in General)

Regarding Vimeo and Youtube I think it's an important topic that would be best in its own forum thread so we can collect the knowledge in a single dedicated place there. I'll move the discussion.

Edit: new thread here.

723

(44 replies, posted in General)

Hi everyone!
Sorry for the lack of updates lately, I'll try to address all the comments in order.

VF wrote:

Is it possible to change the label color somehow? (...) it was very useful feature in 0.8.15 version and now all the labels just stay black.

Using the text tool? This should work. I can't reproduce the problem, right click on the label > Configuration... I can change the color of the label.

VF wrote:

you've added some new 'trackable' tools. say, i have a video that lasts from point A to point E and i want to track 2 different objects using the spotlight tool (one from point B to point D and another one from point C to point E).

There is some new stuff for the next version in that a tool can start and stop tracking during the lifetime of the video without resetting the tracking data like before, but I'm not sure it'll be very practical with regards to the spotlight tool. This tool is a bit special to handle the fading in/out. Maybe it would be better to be able to take the trajectory tool and have a display mode for the trajectory that would be a spotlight. Or to be able to point the spotlight tool to an existing drawing like a tracked crossmark.

724

(44 replies, posted in General)

Right click the marker and select "End path edition", you should get the path. Right click the marker and select "Configuration" to get the display options.

725

(44 replies, posted in General)

I can send a private test version if you need this urgently and promise to give feedback about it :-)
I don't know when the next experimental version is going to be finalized. I made good progress on the angular kinematics analysis and export which is the bulk of the release. But I'm abroad for about a month for work and I won't make much progress on Kinovea during that period.

726

(44 replies, posted in General)

Please go to Help > Open log folder and collect the log.txt file and sent it over at joan at kinovea dot org. So I can better understand what is happening. Thanks.

727

(44 replies, posted in General)

Hi dangthuhuongvn,
It could be linked to the Windows locale used for non-Unicode programs causing an issue when loading the video decoding library. There is an open bug submitted a while ago of a similar thing. Most people don't have the issue but on some systems it causes this problem.

Is your Windows in Vietnamese? Can you see thumbnails for images (.gif, .png, .jpg, etc.) they use a different decoder, it would confirm the origin of the problem.

Please check the following setting in Windows: Control panel > Region > Administrative > Language for non-Unicode programs. What is the value of this?

Try to change this to match the language of your system if it's set to English. This is mostly to test the hypothesis, this may have side-effects on the functionality in other programs so keep that in mind if this fixes the issue but you see bugs arising in other programs.

punkduck2064 wrote:

You can see the camera thumbnail, but when you try to capture the video is when you get the error.

What is the error exactly ? Error message saying to try a different format? Black screen? Can you open the camera settings dialog? Can you change the stream format? What is the list of stream formats? Can you paste what the header bar is displaying above the camera screen?

TL;DR: at the end.

This is on the road to being able to export tracked angles and other tracked data.

Persistence is the thing that makes a drawing fade in/out around the frame it was added on.

Currently there are 3 visibility levels:
1. The drawing is shown only on the frame (persistence off).
2. The drawing is shown for a customizable amount of time before/after the frame.
3. The drawing is shown for the entire video ("Always visible").

These options can be customized for each drawing. It's also possible to set defaults in Preferences > Drawings > Persistence. And there is also a checkbox in Preferences > Drawings > General to hide drawings altogether when the video is playing.

Now drawings can also be tracked individually, to review position, length or angle variation over time. When you track a drawing it is always visible as long as it is tracked, and when you stop tracking it reverts back to its original visibility. So if you track a drawing for a while and then turn off tracking, it will usually disappear because its visibility option is to fade out a few frames after the frame it was added on, which is way before. The tracking data is not lost.

Requirement: I want to be able to start/stop tracking the same drawing multiple times. With the current way it works, I have to first set the drawing to "always visible" which is cumbersome: Right click drawing > Persistence > uncheck "Use default value" > check "Always visible".

I started adding an option specific to trackable drawings to let them "show the drawing even if not tracking", but it is redundant with the option of "Always visible" persistence.

Also, I'm not convinced that having fade in/out values customizable "per-drawing" is that useful. It seems to make the whole "persistence" thing unnecessary complicated for most people.

I'm considering the following:
- Drawings are created using the default fading option from the preferences just as it is now.
- The persistence dialog at the drawing level is removed.
- At the drawing level, we can only toggle between "Always visible" or not.
- When "Always visible" is off, the drawing uses the global option from preferences.
- The "Always visible" toggle menu is directly in the drawing's context menu, not in a dialog box as it was with persistence.
- In preferences, merge the whole "Persistence" tab into "General".

TL;DR:
I'm considering simplifying the user interface for "persistence" of drawings, leaving just "Always visible" as a per-drawing toggle. When off it would use a global fade in/out option from preferences.

Q: Is it reasonable to remove per-drawing fading options?

I feel it would make things more straightforward and would allow the most useful toggle to be directly accessible in one click.

Thanks.

The way these exporters work makes it complicated to distinguish these cases. The data is first exported to a Kinovea XML dialect and then converted "declaratively" directly between the XML formats to a target format like ODF, XHTML or Excel XML. It has proved rather burdensome to maintain.

If this is for trajectories, please consider using the "Data analysis" menu on the trajectory itself (in 0.8.25). This will bring a time series plot and can export the data to CSV, either clipboard or file. In this dialog the time coordinates are always numeric.

I'm currently expanding the data analysis dialog and it's possible that at some point it will replace the spreadsheet exporters altogether.

Mail sent.

It's not 100% clear to me, what are you trying to do? If you want to compare two videos, one being 210 fps and the other 240 fps it should be possible.

First, go to Options > Preferences > Playback > General and uncheck "Link speed sliders when comparing videos".

Next you need to find the slow motion factor you will have to apply to one of the video so that their ratios to real time match. This depends on the playback framerate marked in the file (e.g: 30 fps).

Example:
- Video A has a capture framerate of 240 fps, and a playback framerate of 30 fps.
- Video B has a capture framerate of 420 fps, and a playback framerate of 24 fps.
- Let Ra be the ratio to real time of A : 30 / 240 = 0.125.
- Let Rb be the ratio to real time of B : 24 / 420 = 0.0571.
- Let S be the slow down factor to apply to A so that it matches the ratio to real time of B : Rb / Ra = 0.45714.
- By setting video A speed to ~46% of video B speed, you should be able to compare them on equal grounds.
- This speed should be set via the main speed slider.

The formula can be summarized like this:
- slowdown for A = (Ac * Bp)/(Ap * Bc).
- Where Ac and Bc are the capture framerate of A and B, and Ap and Bp are the playback framerate of A and B.

You can read the playback framerate by going to Video > Configure video timing…. In the "Video" section, read the "Framerate read in the file" value.

Please plug your numbers into this and let me know if it works.
I realize this is not trivial, should probably detect this comparison case and offer a way to set this up automatically.

Which version of Kinovea? Can you try with 0.8.25? Do you see the camera thumbnail?

OK, I think I have a fix for the initial black screen on DirectShow cameras, and it could possibly fix the issue for this camera.

Can you help testing this? Let me know if I can use the email address you registered with on the forum or send me a mail at joan at kinovea dot org.

Hum. I should log more context when it fails, as it is there not much information to work with.

It appears that getting one frame on the default stream format is OK but the problem is that we can't get the details of this format. Kinovea needs these details to compute buffer sizes. There is a mechanism to cover for this case in the IP camera module.

I've set the camera at 1280x720 30fps, as the only settings available on the UVC camera on Kinovea

Are you saying the list of stream formats is empty? I'm interested in this list:

http://www.kinovea.org/screencaps/0.8.25/0825-cameraconfig.jpg

.

On the top I see the data for the signal: 29-30 fps and 79 MB/s

Ah, (1280*720*3*30)/(1024*1024) = 79.10 MB/s. So the camera is sending uncompressed RGB24.
I will review the issue that the first time we open the camera we get a black image and need to change the configuration. For cameras that have only one possible configuration it may cause a problem.