Search options (Page 51 of 135)

Which version of Kinovea? Can you try with 0.8.25? Do you see the camera thumbnail?

Hum. I should log more context when it fails, as it is there not much information to work with.

It appears that getting one frame on the default stream format is OK but the problem is that we can't get the details of this format. Kinovea needs these details to compute buffer sizes. There is a mechanism to cover for this case in the IP camera module.

Are you saying the list of stream formats is empty? I'm interested in this list:

.

Ah, (1280*720*3*30)/(1024*1024) = 79.10 MB/s. So the camera is sending uncompressed RGB24.
I will review the issue that the first time we open the camera we get a black image and need to change the configuration. For cameras that have only one possible configuration it may cause a problem.

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.