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

So, this is what I came up with, it's just a rough draft / suggestions, please definitely add your thoughts and what you think we should do.

So, from my point of view : (again, do not hesitate to scratch it and input your own views)
At a very high level, we could support the following functions : 1. delayed live, 2. pause the frame grabbing and browse in recent history, 3. continuous recording to disk, 4. draw on screen.

What I mean by these are:
- delayed live : the ability to display on screen what the camera saw a few frames ago instead of what it is imaging currently.
- pause frame grabbing and browse : the ability to freeze the frame grabbing and see what the frame buffer contains, eventually save it to a file.
- continuous recording : the ability to save what is currently grabbed by the camera, or what is currently displayed on screen, to a file.

Do you think they are reasonable and compatible goals ?
Do you think there are other functions that could be interesting ?
Do you think some of these are in fact pretty useless ?

If you have some specific usage scenarios corresponding to these or a combination of these, please input them as well. Having well defined usage scenario will help for the interaction design part.

Yes, forgot to mention that some thinking is also needed to handle the various cases of camcorders / screens.
This is probably on of the first thing to discuss.

So, basically as a user, we would be able to use the "View" menu to prepare the workspace : select one capture screen, select two capture screens, select a hybrid mode where you have one capture screen and one playback screen.

We need to clear up the user interactivity here because there are many possible scenarios. I'll give them names just in case we need to refer to them later.

Possible screen combinations :
S1 : 0 screen.
S2 : 1 playback screen.
S3 : 2 playback screens.
S4 : 1 capture screen.
S5 : 2 capture screens.
S6 : 1 playback screen + 1 capture screen.

Possible number of devices connected:
C1 : 0 camcorder
C2 : 1 camcorder
C3 : 2 camcorders
C4 : 3 or more camcorders

There are two kind of interactions here:
1 - The user plugs a camcorder to the computer. What do we do depending on the current screens cofiguration + number of camcorders already connected ?
2 - The user changes screen configuration. What do we do depending on the number of camcorders connected ?

Each and every combination will need to be taken into account at some point in the code, so it would be really nice to have a consistent and sensible behavior.

Examples for interaction 1 - The user plugs a camcorder to the computer.
S1 (0 screen) : show a dialog box inviting the user to display a capture screen. If there are already other connected devices, display a list to choose from ?
S2 (1 playback screen) : Should we display a dialog box ? Should we create a capture screen automatically ?
S3 (2 playback screens) : Should we display a dialog box ?
S4 (1 capture screen) : Is it already linked with another connected device ? if not we should directly link the device with this screen. If yes, what do we do ?
S5 (2 capture screen) : Is there an unused screen among the two ? Do we link the device with it automatically ?
etc.

OK, maybe we can group these and just need to define a globally consistent and intuitive behavior for:
- There are not any capture screen available to link the camcorder to.
- There is at least one empty capture screen that we could use.
- There is more than one camcorder that could be linked with a capture screen.
- There is more camcorders connected that we can handle.

Please anyone add your thoughts on what the behavior should be !

Let's tackle the user experience part, since it is one of the most important thing, in fact, probably more important than the raw number of features.

I made some UI mock-up, so we can do a little usability experiment

On the following image representing a tentative capture screen, can you guess what the buttons / icons / etc. mean ?
What do you think they mean ?

Thanks

Ha ! You only got one wrong, the one I had most doubts about

The video camera icon (first) was actually intended to be used as a start/pause for frame grabbing. That is, one may use it to freeze the stream sent by the camera on the current image.
I started with a Play/Pause classic icon, but I found it not appropriate for the function…

What you mention (Selecting the capture device) is missing. I thought it would be best if done only once at screen initialization time, but being able to switch device at any point would come in handy. So that means another button.

If anyone think one of these in unclear please chime in !

The "settings widget" was supposed to be a "foldable panel" rather than a drop down menu, the user would fold it by clicking the down arrow on the right (or anywhere in the grey area), leaving only the grey line with a summary of the settings. (unfolding by clicking the grey line again).

I'll upload another mockup.

edit:

So, there are two "camcorder" icons now, but hopefully they are understandable.
Also swaped image and video in the settings panel to match the order of the buttons…
The white area may host the delay slider, and frame cursor when these are implemented.

Thanks for the feedback.

Regarding the delayed live, (which I think can be useful in almost any sport to get unattended video feedback), technically, we need to cache frames somewhere to be able to play them later in sequence.

One approach would be to use a global parameter for "Memory Usage" for the whole application.

Such a memory usage setting is currently in use for analysis mode (frames caching) in Player screens, and it could be reused for the capture frame buffer. (meaning setting either a max duration, say 20 or 30 seconds, and setting a max RAM usage, 1GB for instance.)

Asking for RAM usage is not particularly user-friendly, but I couldn't find anything better for playback screens (ideas welcome). That is why it is more or less hidden in the preferences and we try to get good defaults that works for 90% uses. (Currently, 12 seconds and 512MB).

So to sum up, by default you would be able to select a delay between 0 and 12 seconds. For longer delays, you'd have to tweak preferences and increase allowed memory.
(Actually the 12 seconds would depend on the size of images captured…)

Does this sound reasonnable ?

Another completely different approach would be to use an on-disk buffer. In this case the frames would be temporarily stored on the hard drive instead of in memory.
This would allow for virtually unlimited delay (minutes, hours, depending only on hard drive space), but I'm not too sure of the complexity added by this approach in terms of architecture and obviously the loss in performance.

For those interested in the "under the hood" part, here is a schematic of a proposed architecture, using a in-memory buffer. (Comments also welcomed)

Sweet. Thanks for the insight.

I did some capture simulations this morning...so this is what I found.

I attached my camcorder via fire wire through a dedicated fire wire port on my computer. (Windows Vista Home Premium)  During live capture, the screen flickered back and forth from black to a quick view of video coming in. 

I also unplugged my fire wire connection, and then plugged back in.  When I did this, the software did not re-recognize my camcorder.  I had to close the program and re-start.  I would recommend that if a connection gets lost (and many times it does because the camcorder goes into sleep mode because when you are capturing live directly into the computer, you wouldn't necessarily need to also be capturing to tape) that the software saves the previous device connected, and will either re-connect automatically if it's the same device, or it will show back up in the menu.  Best suggestion is would automatically re-acquire the previously connected device.

I would also suggest for live capture mode, possibly a drop down box, of different popular encoding profiles to choose from. (Example - .avi, .wmv, .mpeg, .mov)  This allows the user to pick the file format they might use most often, and adds flexibility to regulate the file sizes during capture.  Especially important for competitions that go on for hours, when capturing directly into the computer  (If this one was already in there, I missed it)

Let me know what you think, and I will continue to test live mode....