You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
I published a new version and changed the links in the original post. This update addresses a few important points, mainly 1. the crash at launch when installed over version 0.9.1 and 2. the inability to increase the memory buffer in the player.
Please continue to report any problem here.
Thanks!
Stepping frame by frame in debug, the timing info inside the file is fairly consistent with having just 59 frames, somehow the last 20 frames or so are not reachable by normal means.
Is there a player where it fully works? I think the file is broken. When I open in VLC it just freezes on the first frame. In media player classic it shows the entire video but the timeline jumps back at zero halfway through. In the Windows 10 media app it shows the whole video but the timeline reaches the end after maybe a third of the video so seeking with the timeline is even worse. In the classic Windows Media Player the timeline is also completely confused. Some of these players may have less strict requirements on frame-to-timestamp coherence when they just want to playback the video. For frame by frame and accurate time computation Kinovea needs more consistency.
Did you use a particular application or mode on the phone to record it or did you modify it afterwards to trim the endpoints or other post-process? Like maybe a pre-roll or slo-mo feature?
It's interesting to compare the behavior with version 0.8.15 which used a different way to get the timestamps. In that version the duration is computed wrong and the video goes all the way but then it loops back before the stated duration and the playhead continues and never loops back. It also completely breaks the working zone selector.
I have uploaded the firmware Waheeden shared with me at the following:
And the original firmware in case things go wrong:
standard_version_not_fix_the_frame_rate.rar
There are instructions inside on how to proceed. I haven't had time to try it myself yet.
Thanks for the sample.
It is one of those files where the first frame of the video has a negative timestamp, this throws off some calculations… Can you share what camera or process has generated the file?
It's probably fixable but needs care to not break other things in the process.
It is the first time I hear of this. Could you share a sample file please?
By going through the frames of the video I can see the timestamps and when the video reaches the last frame I can compute the total number of frames and total time that are actually in the video. So in theory this should be enough to fix this kind of files automatically. I'm not sure what's the best way to go about it though.
It could initially leave things as they are and after the first loop, when it realizes the last frame doesn't match the duration, try to fix it.
There could be a explicit "Fix duration" button in the Video > Configure timing dialog, that would perform the test and save the actual duration somewhere. This could then become an option in the main preferences to "always try to fix duration", but would be off by default because it will slow down opening the files in the normal case.
Other ideas are welcomed.
The color itself not so much. But it's best if the marker contrasts well against the background. It should also be "rotationally invariant" and if it has contrast itself it's also better. So for example a black disc with a white dot in the middle or vice versa. Otherwise a simple black or white disc should work well enough.
great thanks...generally the replay is once and delete...just for feedback to the golfer for practice. Sometimes that golfer is me...to check my swing etc.
If you are sure you won't save the sequence, the simplest way to do instant feedback is to use the delay function. For example you can set the delay to 5 seconds.
The lines on the capture screen are not the same when I replay the capture.
I'm trying to reproduce the problem. Could you send a screenshot at joan at kinovea dot org? In particular what is the camera image size, whether the camera view is filling the capture screen, and same for the playback side.
It is now possible to rotate the camera image at capture time in version 0.9.2.
This should work as expected now in version 0.9.2. The drawing will be visible while tracked and fade out afterwards. The custom visibility settings can also be used to deviate from this default.
This issue of corrupted alignment in dual save is fixed as of version 0.9.1. It was related to the total size of the composite video adding up to something not a multiple of 4 pixels, this is not always supported by the output format.
The problem with special characters preventing some files to be opened should be fixed now in version 0.9.2.
This scenario is supported now in version 0.9.2.
After copying and then pasting the image in the second screen, right click and Visibility > Custom fading, then lower the "Maximum opacity (%)" field to make it more transparent.
This should now be fixed in version 0.9.2.
Kinovea - Forums → Posts by joan