Search options (Page 3 of 133)

Thanks, very interesting. It shows me something I haven't really taken into account in the new system I think.

The new system uses a concept of "windows", that is conceptually similar to the old workspace, they contain the 1 or 2 screens with the content in it. But the XML for these is stored in the application data folder and managed by the program. So now the way to start on a specific screen configuration from the command line is to pass the window id or name, instead of the path to an external file. All the existing windows are listed in the UI so it's easy to reload old ones but creating new ones is also done from the UI.

This means something appears to be missing compared to what you want to do, you would have to create/modify the window xml stored in app data which is doable but not ideal. It would be much simpler if you could pass the paths to the two videos on the command line no?

For a single video you can directly pass the path to the command line or use the -video parameter, no need to create a window or workspace file. Maybe there should be a -video2 parameter that let you start in compare mode directly.

Hi,
Synchronization works via the "time origin" annotation and is saved in KVA files. So the way to do this would be to have a KVA file for each video with a time origin set a the timestamp of the sync point.

Please note that this workspace file format will be obsolete in the next version as the multi-window system has been rewritten and better integrated in the program, and furthermore "workspace" means a different thing now.

Are you generating these files from code or are you editing manually? The timestamps are not in seconds or frames they are in a unit that depends on the video file so it's a bit more complicated.

Thanks.

It's related to the function of auto-numbering file names. I can reproduce if I set the file name to contain a very large number like "test1234567890123". When it tries to automatically increment the number it fails because it's too large.

It will be fixed in the next release.

The way they solve this in video editing software like Shotcut or Premiere Pro, which also need frame by frame navigation, is a workflow known as "Proxy editing".

Essentially they create lower resolution and editing-friendly versions of the files, you create your edits on these proxies, and when you are ready to make the final export they swap in the original footage.

This seems the way to go and the fact that it's an industry standard there is an indication that no amount of buffer optimization or GPU acceleration would truly solve it.

I could add a function to create frame by frame friendly version of the video. I think the simplest would be to create the file next to the original with a suffix, as this would open the way for automatically detecting the kva annotation file when opening the original video. This way we can have a similar workflow: add your annotations on the proxy, then export a video based on the original.

One caveat is for making measurements and tracking as the lower resolution will reduce precision. But I think for the main use case of visually inspecting technique/posture it would be a good solution.

Two ways to go about it, either from the file browser by right clicking the thumbnail and a simple convert menu. Or by first opening the video and having an option under export.

For the resolution it should probably be a preset while keeping the original aspect ratio.

Hi,
I looked into perfs a bit. Specifically I have some 4K @ 60 fps videos which are impossible to browse on the timeline.

Could you tell if you are seeing the same:

1. forward playback is actually decent. It's not buttery smooth but it runs without slowing down too much. I measured between 9 and 25 ms per frame to decode, and on average it can sustain about 45-50 fps so it's usable for the purpose of watching the action in real time.

2. forward frame by frame also works. For example holding the keyboard right arrow down and letting it move forward.

3. It's backward frame by frame and clicking around in the timeline that is horrendous.

Do you get the same behavior?

When you get this it's mainly related to the encoding. This particular video is encoded with key frames every 6 seconds (360 frames).

So whenever we click in the timeline, it will randomly drop in the middle of one of these segments. The way video decoding works we get to the previous key frame and then it has to decode all the frames forward until it gets to the target.

So I'm getting 2 or 3 seconds to get the requested position, just because it has to actually decode hundreds of other frames to get there.

As an experiment I exported it back using the export function (export in Kinovea uses MJPEG exactly for this reason, so every frame is a keyframe), and now I can do frame by frame and timeline browsing without issues, on the same 4K 60 fps video. (But yes the file is 10x bigger).

(edit: my computer is not particularly beefy).

Yeah 4K + H.265 is brutal for frame by frame. Pending further investigation the current strategy is to increase the memory buffers in Preferences > Playback > Memory and then reduce the working zone to have it fit in the buffer, then it should be smooth. But that's very limiting at these resolutions, required memory: width*height*3*frames, for 200 frames ~5 GB.

I'm not sure if it's me but the images are quite small and they don't match what you wrote in terms of coordinates.

I will add an option to disable bilinear filtering and pixel offset. Indeed it will be better to test if everything works as expected.

On mouse click the program first receives the mouse coordinates on the video surface, these are integer coordinate in a top-down system. This is converted to image coordinates based on the scaling, panning, rotation and mirror done in the viewport. Then this gets converted to world coordinates based on the active spatial calibration and possibly the lens distortion (+ more complications for camera tracking).

Sub-pixel precision mainly depends on the zoom level. You can go up to 10x zoom so at most you get 10 locations in each dimensions inside the pixel. These are stored as floating point.