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)