Search options (Page 46 of 129)

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.

@Faultyclubs & @inorkuo,

I looked into the issue of recording with delay today and found a way to have it back without disrupting the architecture.
I still think the default option should be the optimized path from camera to disk, to ensure the most correct timing possible in the default case.

There will be a new option in the preferences to switch that "Recording mode".

In "Camera" mode it will record the current image coming from the camera. In "Display" mode it will record the current image displayed on screen. This second mode will thus take delay and mosaic view into account. It will not include any drawing overlays for now.

I'm not sure the labels "Camera" and "Display" are descriptive enough to intuitively understand what the options are doing, if someone can find a short and to-the-point explanation for each, that would be welcome.

This should be fixed in the next version.

Thanks for the report!