Investigate whether is possible to start a new recording while processing a previous video file

[ArturoManzoli]

From issue #811, miniVideoRecorde widget has been updated with UI enhancements, but the suggestion about starting a new recording while processing another one have to be analyzed carefully. This parallel processing<->recording can potentially throttle down the system.

If it's alright to do the parallel processing, please create an issue to update the UI with the necessary elements as suggested in #811.

[ES-Alexander]

From a previous discussion with @rafaellehmkuhl, being able to start a new recording while the previous one is processing was definitely his intent, but I agree it makes sense to check whether that's feasible before making it the standard behaviour :-)

That said, the processing is happening in the browser on the control station computer, which can have much more variation in specs than we would expect for e.g. a BlueOS vehicle's onboard computer. It may have to be a functionality that we allow through the UI, but with a troubleshooting recommendation in the docs that users running into performance issues at the changeover of recordings can try waiting until the processing is complete before attempting to start the next one.

We could maybe also check the processor usage and provide a warning if it's maxed out, but I'm not sure how hard that would be to do, and I expect it's likely overkill even if it's possible (since starting a new recording is a direct user action, rather than just allowing the system to continue as-is, so if performance issues arise soon afterwards then it's likely quite intuitive that they might be related).

[ArturoManzoli]

Maybe there is another solution: I was thinking about why the user would stop the recording and start a new one right away.. in my opinion, the user would do this to organize it's video capture process and maybe add some context to each video section.

My solution for this case is to, instead of stopping the video capture and starting another one, just keep recording and add markings (timestamps) to the whole file (using a flag or scissors icon, maybe).
After pressing the stop button the video would be processed and sliced in to separate files according to the markings.

[ES-Alexander]

Hmm, I think in general that "adding context"/flagging is better captured by #594, but that's a much more involved idea (and isn't just related to video segments).

Cockpit's video recording is already performed in chunks (for recovery purposes), which then get joined together into a single file once a recording is completed. If we expect "stop the current recording and start a new one immediately" to be a commonly and intentionally used functionality¹ then we could add a UI element specifically for that (e.g. a button with a scissors icon, as you suggested)², but from an implementation standpoint I do think that should at least stop the current recording chunk and start the next one, to avoid needing to actually parse and split the chunks as part of the processing (which sounds likely to be expensive).

It may be worth displaying a text box whenever a recording stops, that allows the user to specify a filename/tag for the recording if they want to, but I think that's independent of whether/when the next recording should start. Feel free to open a separate issue for that if you think it's worth pursuing.

Footnotes

1. I personally don't think this would be common, because I think semantic markers are better stored in independent metadata (that can ideally be jumped between within a single video file, like YouTube's chapters), in which case the main remaining reason that I can think of to intentionally stop+start recording would be to limit file sizes, but that seems generally unnecessary, and could be better implemented as an automatic feature defined by a user-settable video size threshold. ↩

2. I am a bit concerned that an additional button per recording mini-widget could clutter up the interface, but if we decide it's worth implementing then I suppose we could make it hide-able from the widget's configuration, in which case only people who actually want to use it would need it displayed. ↩

[joaoantoniocardoso]

To add on the UI side, REAPER has a right-click on the record button that allows the user to select the intended behavior:

reaper_record_button.mp4

[rafaellehmkuhl]

Just to add on that: starting a recording is not resource intensive at all. Starting a recording while the previous one is being processed should work just fine.

The only problem would be if the user stops the second one before the processing for the first one is finished. In this case, a processing queue would come handy. It's an edge case thought.