Search options (Page 101 of 133)

Ah yes. Motion perfect slow motion, I've always been very impressed by their demo video.
On the suggestion / todo-list, I have referred to this as "Smooth slow motion".

This type of extreme slow motion by reconstructing missing frames from adjacent frames content would definitely be a killer feature and quite a challenge!

As far as I can tell this is extremely tricky to implement.
Also in the same vein, the Re:vision Twixtor set of plug-ins¹. Some say it's the best in the industry at this type of stuff.

I'm not too confident that I can code this all by myself to a usable result though I have a few leads and reference papers but it's quite a long shot. Very interesting though.

¹ Some Twixtor videos on vimeo.

Hi,
Thanks for the reports.
Which version of Kinovea are you using ?

This sounds a lot like bug 207 which should be corrected in version 0.8.9 and above.

I'll try to reproduce the crash.
Thanks

edit:
Reproduced the crash, added as bug 223

Tracking is done by template matching using Normalized Cross Correlation.

If it is indeed a similar issue than bug 214, then yes, the problem is during saving the file to MKV.
We specify the initial fps, for example 29.97fps, and it is somehow changed to 30fps (only some specific fps are subject to the issue).
The final video contains the same number of images, but they are not aligned with time anymore.

Seeing the large shift and the fact that it goes the other way, your issue may be a different one.
Also, if you didn't reencode the .asf and when reopening the key images are still offset, then it is definitely a different issue.

If possible, create a very short video on the camcorder, like 1 or 2 seconds, and do your conversion to .asf.
Then attach the .vob and the .asf to bug 214, or send them by mail to: joan at kinovea dot org. Thanks

Also, the .vob might be readable directly in Kinovea if it's an option.

I don't have problems when checking out… Even as anonymous (I just cleared out authentication data to check, and I can still check out the trunk)

If someone else can give his/her experience ?

Hello,
Thanks for the pointer, I didn't know this software. I'll try the demo version.

However, as of now the Capture feature has been architectured around the other approach: an in-memory buffer that will cache frames.
From the coding perspective with such a buffer, displaying the frame from 5 seconds ago is about as easy as displaying the most recent one. We just retrieve from a different spot in the buffer.

I think that for the targeted applications (self-coaching and continuous feedback for a rotating group of students), a delay of a about 15-20 seconds would be enough (?). The athlete performs, and then come by the laptop to watch back.

For sports that takes longer attempts, or when it takes too much time to come by the computer (swimming pool comes to mind), then maybe recording and watching the recorded video will be a better approach.
For example it's possible to set the workspace to "One capture screen and one playback screen". Then you can drag the recorded files to the playback screen to watch it back, while the other screen is recording the next person.
Any feedback on this use case is welcome too, it may be be heavy on computer resources.

Hi,
Thanks for the report.

Would you have a link or a copy of the file that you could share ?
(for example by mail to joan at kinovea dot org if less than 2 or 3 MB).

Do you know what is the original size of the movie and the wanted aspect ratio (16/9, 4/3) ?

(Best is if you can have a sample of less than 1MB that I could attach to the bug tracker for reference).
Thanks