Search options (Page 50 of 134)

I missed your previous message. It is interesting to know that the thumbnail works but not the video feed. The thumbnail uses a slightly simpler way to capture the image but it means it should be possible to make it work natively in Kinovea.

Could you send me the log file corresponding to trying to open the camera directly in Kinovea?

I don't have any experience with this camera. The global shutter + 1224x1024 @ 145 fps definitely sounds interesting on paper if it delivers. They mention "DirectShow" compatibility so yes, it should work with Kinovea.

I didn't know about this vendor, they have several other interesting listings. It's always hard to know if they are the actual manufacturer or just rebranding. They seem to be present on the usual Shenzhen online markets like Aliexpress to get an idea of princing, but this specific model is not listed yet.

I think these guys have the same unit under a different brand. Too bad none of them list the actual imaging sensor, we could have reviewed the claims.

Yeah, after thinking about it I came to the conclusion that this was your use case, replaying a high-speed video at its real time speed.

Currently there is no satisfying way to do it. Tweaking the reference video framerate in order to increase the range of the speed slider is a workaround based on a side effect, I don't think it's a good solution to overload this option with a completely different role than what it was intended for. 

The issue is that if you want to replay a say, 1000fps video to real time with the current player, it will need to decode and display these 1000 frames per second, it will most likely fail, which to me means that this use-case requires a different playback approach altogether.

I very much like the idea of being able to go way higher in speed. If we can do 10x we should be able to do 100x because at that point it wouldn't be related to computer perfs.

This would be very useful to quickly parse a long video, and it would provide timelapse out of the box which I think have unexplored applications in sports, to analyze cyclic motions or long term trends in posture.

So, I would say: 1. a new playback approach for very high framerates, most likely by seeking forward in the file instead of decoding frame by frame. 2. a logarithmic speed slider so you have fine control for slow motion but can still go to 100x speed at the other end, 3. an increased size of the speed slider (this is limited by the size of the screen in dual playback configuration at the minimal monitor resolution supported).

Not directly as for the trajectory tool unfortunately.

The only way currently is to change the global settings under Options > Preferences > Drawing > Tracking > Default tracking parameters. You could add a trajectory to find the optimal parameters for the video and then set this up so that other trackable objects use it when their tracking is enabled.

I agree and I think it should work like this (except that the first-to-finish would wrap and wait on the first frame instead of the last because it was much easier to implement it this way :-)). Sometimes the algorithm is thrown back and misses the slot though.

The entire thing uses real time in the common slider, and translates real time to local video time (taking slow motion and capture speed into account) to seek to the correct point in each video. The correct behavior of this seek is unfortunately dependent on file formats. I have tested a few of these scenarios but yeah, definitely room for improvement in this regards.

For the scenario you describe you should unlock the speed sliders from the preferences in Playback > General. This will let you match durations of arbitrary sequences. This is requested more often than I anticipated. It seems this would be better as a button directly in the common controls UI instead of hidden in the preferences.

edit: I agree it is currently much harder than it should to perfectly match the duration of one performance in one video to the other, if you want to compare *forms* without regards for timing. As in your example of comparing two swings performed at different speed. Currently you need to tweak the slow motion in one of the video until it seems to cover the same duration.

A two-point synchronization system would mitigate that. You would mark the start and end of the movement in each video and the time would be remapped so that these sections are of the same duration in both. It would still be a linear mapping so the rest of the algorithm shouldn't change.

Thanks for the feedback!

1) The original framerate of the video is indicated in the infobar above the video, maybe the playback framerate could be shown here too. It would be similar to what happens in the capture screen.

2) I think I understand what you mean. The issue is that 200% of real time may become several hundreds or thousands of frames per second to replay. It may not be sustainable or displayable by the monitor. This has become less true in recent years, maybe the max should be revisited. 

The other aspect of rescaling the range of playback speeds is that it lets you select slow motion more easily. If you have a 10x ratio for example which is one of the most common (30 to 300), the natural speed of the video would be too close to the left to be slowed down further with the mouse. Another approach to this would be to have the slider logarithmic instead of linear, as is already the case for the delay slider in the capture screen.

3) I agree. At the moment the way to do that is with the keyboard UP/DOWN arrows (jumps 25%), SHIFT+UP/DOWN (jumps 10%) and CTRL+UP/DOWN (jumps 1%).

Thanks for the feedback!
I have considered the concept of "projects" before but felt it was adding a layer of complexity that wasn't really required.

I very much like the idea of being able to launch the program back exactly where you left it. There are some pieces already in there that should make this not too complicated. In particular the crash recovery mechanism is able to restore the state of the video + analysis after a crash even if it wasn't explicitly saved. This works through a special field in the KVA file that references the video it was created on.

From reading your post I feel that the KVA file with the video reference is already matching the concept of "project" that you describe? A key missing feature is the ability to open a KVA file and automatically load the video it references. Also it would need to push back the state of zoom/scale, mirror, magnifier, working zone and current position of playhead.

"Load key image data" is important in itself to be able to load several KVA files onto a single video. This is useful for comparison purposes for example, or if you have a standard KVA with template lines or other reference material.

Regarding opening a video in the active window, I haven't received a lot of feedback about this. You can replace the first video by drag & drop from the explorer. The algorithm tries to make things work intuitively based on the state of the screens, especially for the case where there is an empty screen or if the single screen is a capture one. But yeah, when both screens are filled, the "open video" menu could take the active one into account. Although I'm not sure if replacing the active one is the most intuitive, you could argue that the user is working on it so it might be better to replace the other one. I don't feel the active screen is a really safe hint to rely on here. I agree that the current way, replacing the second screen, is not perfect.

The file explorer should switch to the directory containing the last opened video so if the user really wants to control where to open the next file when the two screens are already used, the drag & drop method should be the easiest and safest way.