[Capture] - How should it work ? (Page 3 of 4)

Hello,
Thanks for the pointer, I didn't know this software. I'll try the demo version.

However, as of now the Capture feature has been architectured around the other approach: an in-memory buffer that will cache frames.
From the coding perspective with such a buffer, displaying the frame from 5 seconds ago is about as easy as displaying the most recent one. We just retrieve from a different spot in the buffer.

I think that for the targeted applications (self-coaching and continuous feedback for a rotating group of students), a delay of a about 15-20 seconds would be enough (?). The athlete performs, and then come by the laptop to watch back.

For sports that takes longer attempts, or when it takes too much time to come by the computer (swimming pool comes to mind), then maybe recording and watching the recorded video will be a better approach.
For example it's possible to set the workspace to "One capture screen and one playback screen". Then you can drag the recorded files to the playback screen to watch it back, while the other screen is recording the next person.
Any feedback on this use case is welcome too, it may be be heavy on computer resources.

Great
However as noted in the 0.8.11 thread, there is a high chance that the final video created is not properly timed. (It will go too fast relatively to real time).

It's dependant on the CPU load so it's not linear and can't be corrected manually like this. Sometimes the problem is not there, e.g. if the image size is small, the machine powerful and the capture frame rate low.

The issue is that the rate at which images are grabbed is estimated and used as frame rate for the final video.
However, when the recording starts, the CPU is more heavily used and images come less frequently to the program.
What is needed is to completely decouple the recording from the frame grabbing.

About framerate / size configuration.

I have just looked at this today, it should be available in the next experimental version.

What happened before is that we took the first item in the list of the camera capabilities.
Now the biggest frame size will be selected by default, but you should also be able to change to another setting in the source configuration dialog.

Tested ok with a webcam (snapshot below). For the DV camcorder, the frame size change did not translate down to the device… to be investigated later (DV should always be 720x576 anyway, I was surprised to find an other option).

The goal now is to pack up the capture screen until it works well enough, and then publish a stable version.
Ideally the version 0.8.14 would be the last round of changes and then 0.8.15 can be the official version. (With translations and manual updates).

So here's a list of improvements that have been suggested or scheduled for the capture screen, please add yours if it's not listed.
Very big changes will probably not make it this round, but be pushed to future versions.

1 - A "file format" drop down list directly on the capture screen to select the file format for snapshot/recording (or only changeable in the preferences ?).
2 - A "file format" drop down in the preferences to set the default format. (or we could just save the last one used ?).
(Note: probably only one of the previous two will be integrated)

Naming and directories
3 - Save the last filename used so the auto-increment works across screens and restarts.
4 - Preference page with advanced naming conventions, with formatting tags for date and auto increment.
5 - Move the settings for "directory of recording" to the preference page ?

Misc
6 - Access to the device configuration from right click on the main image.
7 - Display the current resolution / frame rate somewhere. (in the status bar maybe).
8 - Display the file size taken so far while recording is in progress ?
9 - Is the ability to hide / show the "configuration" mini panel useful at all ?
10 - Fix memory issue when the combined space of the buffer goes over Windows (32-bit) addressable space. This might mean having a single memory setting for the whole application.
11 - Detect if the camera is used in the other screen and connect to the next device.

Most probably not in this version
12 - Fix issue with frame rate of created video. (I'm afraid this is a long shot, it might not be fixed for the release).
13 - On capture freeze, change the interface to allow for better navigation in the recently captured frames (play, pause, next, prev).

Again, if you have any more, feel free to add to the list.

Hi,
regarding no 10 of the list I would prefer to be able to set the buffer for each capture screen independently, this would allow a low definition general image and a high definition one focused on a key area.  Much more flexible that one fixed buffer size.