Topic: 1 camera, 2 capture screens (2 different delays)

Hi Joan

Is it possible to have 2 capture screens using the same camera?

I'm trying to mimic BAM Video delay, a nice feature it has is to show up to 4 delays (but 2 would be great to start wink ).

The source I'll be using will be a GoPro connected using a HDMI capture device.

Tnx for the info
NarN

Re: 1 camera, 2 capture screens (2 different delays)

You may use the new feature introduced in 0.8.25 that splits the capture screen in several tiles and display the stream at different delays.

Look for the grid-like icon between the configuration and pause buttons. Select "multiple view" and choose the number of tiles (restricted to perfect squares so that it fits nicely in the original aspect ratio).

At the moment the delay of each sub stream is computed internally so that they spread equally over the memory buffer containing the delayed frames. Does your use-case involve having to manually specify the delay of each stream?

Note that it is purely a "display" feature, if you hit record it is still the original camera stream that will be recorded to disk.

Re: 1 camera, 2 capture screens (2 different delays)

The tiles are great!

Yes, I want to set the delays. I have a player serve then come over to the monitor and see her serve 4 times in a row with a delay.

So first delay is 10sec then 5sec, 5 sec, 5sec (example).

I don't need 4 delays, 2 would be great.

Re: 1 camera, 2 capture screens (2 different delays)

Great. That's the type of feedback I was looking for for this feature. I put it in as an experiment with default settings but not really knowing the level of configurability that would be useful for all the use cases.

I'm not sure the other modes are that useful after all, even the slow motion one. If anyone has tried them please write up.
If not it might be better in terms of usability to focus on the multiple delays use-case and just be able to input the delay of each stream.

I feel having only two tiles instead of four will not add anything because we still need to draw them at their original aspect ratio and so they won't be able to take more space on the frame.

I also feel that supporting 25 tiles or even 16 is overkill. So maybe focusing on the 4 quadrants with custom delays would be the simplest in terms of user interface for both the user and dev since it can be hardcoded as 4 text boxes.

The underlying code would still be capable of all the other stuff but not necessarily exposed until clear user-cases are defined.

Re: 1 camera, 2 capture screens (2 different delays)

Great Joan, looking forward to test.

Slow motion on a live feed, that would set kinovea apart from other software.

I'll describe a use case I think would be great to have:

5 second recording = Player does his action
10 second delay = Player gets to the screen
5 second replay = Player sees his action full speed
20 second replay ie 1/4 speed = Player sees his action in slow motion
5 second replay = Player sees his action again in full speed
Sound signal to start
New sequence starts for next player.

Of course everything configurable wink

You don't need multiple views, just 1 big view.

Whole different approach, maybe some day...

Re: 1 camera, 2 capture screens (2 different delays)

There is slow motion on a live feed indeed. It was actually the challenge that sparkled the development of this multi-view feature. In the mosaic configuration dialog the third option is Slow motion.

Obviously continuous slow motion is not sustainable per se, if you are at 0.5x speed for example, during the time you are watching the slowed down feed, twice as much data needs to be cached for later display. This can't be going on forever. The way it works is using the multiple views, each view starts at a different point in time and slowly drifts, until it jumps back to live and start drifting again. Any given action should be displayed in slow motion somewhere in one the sub-feed or maybe start in one and end in another.

Yeah record/replay scenarios would be very interesting. I'm starting to think that the way to keep it completely open to the myriad of use-cases would be to make it fully "programmable", and have a bunch of standard scripts built-in for ease of use. Then for niche use-cases people can write their own script or have someone write it for them.