MaartenBaert / ssr

SimpleScreenRecorder, a screen recorder for Linux
http://www.maartenbaert.be/simplescreenrecorder/
GNU General Public License v3.0
2.54k stars 286 forks source link

autosave after xx minutes or xx mb #714

Open 4evermaat opened 5 years ago

4evermaat commented 5 years ago

I would like to implement continuous recording. But it is impractical to have 20,50,100 hour video files. I would like to have ability to save video continuously to a folder every xx minutes or after video files becomes every xx MB.

A checkbox would be needed that says after finishing file, keep recording

only a handful of programs have this done successfully: Bandicam, BSR screen recorder, and Debut.

Here is a screenshot (from bandicam) that might help you understand the problem a bit

bandicam auto-complete recording limit by time or file size

Hopefully this is easy to implement. It makes continuous recording much easier, no frames are lost as far as I know, And safer also as a program crash could destroy hours of video if it is one big file and gets corrupted.

editl loosely related to #462, but I want a passive setting that determines default action on each recording run (unless overridden by command line argument).

MaartenBaert commented 5 years ago

This already exists internally, it is called fragmented recording, however it is not exposed in the user interface. The plan was to implement 'ShadowPlay'-like functionality, i.e. allow continuous recording in short fragments (~5 seconds) that get deleted automatically after some time, so that the user can press a button to save the last few minutes of video when something actually happens.

The problem I ran into was that current tools seem to be unable to seamlessly glue these video fragments together. This is because the audio is saved in blocks of e.g. 1024 samples each, and usually these audio blocks don't line up with the video frames. So one 5 second fragment may actually contain 5.01 seconds of audio and the next fragment might only contain 4.99 seconds of audio. When attempting to glue these fragments together, all the tools I tried would introduce gaps in the video and/or audio, which is annoying. I didn't feel like writing my own tool for this, so the feature was never really used.

Maybe you don't care about this if your fragments are sufficiently long, since the number of glitches will then be quite small. You can enable fragmented recording by modifying the following two lines in OutputManager.cpp:

    m_fragmented = false;
    m_fragment_length = 5;

Change m_fragmented to true and m_fragment_length to something like 600 (10 minutes). Note that this will activate code that hasn't been tested in a long time. It is most likely less reliable than the standard recording method, at least if you use a format like MKV that doesn't get corrupted if the recording is interrupted (unlike MP4, which becomes unplayable).

If there's enough interest in this feature I can also add it to the graphical user interface, but I felt that it wasn't that useful due to the glitches it produces.

Technically it should be possible to make the audio length match the video length exactly by cutting audio blocks in half at the fragment boundaries, but it's not implemented like that, and I'm not sure how well FFmpeg would handle this. It may also introduce glitches at the boundaries because of how audio compression works.

4evermaat commented 5 years ago

In my case, I rarely recorded audio simultaneously. I would voice over later or use it as source material for YouTube.

But the programs I mentioned didnt appear to lose any frames, whether it was mp4 or avi.

Maybe they temporarily save the video frames / audio chunks in a temp file. So it doesn't splice at exactly 5 min or 5MB. Some files might be 5:01 or 4:59.

Especially the MB splicer. It was approximate. Some files might be 5.1 or 4.99MB. I assume that the program took into account nuances like the audio chunk and video frame not lining up.

Internally the user-defined splice point was more of a target, but some flexibility was allowed internally to reduce or eliminate dropped frames/audio between.

Bandicam users must use that feature often. If there were so many dropped frames/audio, there would be a lot of complaints.

I would put the priority on the video frames. You can always record some audio again (e.g. Narration), but a real time video.

4evermaat commented 5 years ago

Bandicam has bandicut to splice/join videos without re-encoding them.

There is also bolisoft splitter/joiner that can splice/join same size video in lossless way.

There are a couple of other lossless splitters out there.

joshrabinowitz commented 5 years ago

I agree that this feature (autosaving each xx minutes of xx MB) would be useful for my use case, (making screen recordings at a rate of 1 frame/second).

I also am not concerned with recording audio.