obsproject
Add RFC: Fragmented MOV/MP4 recording
Summary
Fragmented MP4, or fMP4, addresses the drawback of MP4/MOV files requiring "finalisation" by splitting the file into "fragments" that can be read and decoded independently. This means that if a file is not finalised it is still readable up until the penultimate fragment.
This RFC proposes making this the default for the MP4/MOV container family.
We may also consider changing the default container if real-world tests show it to be reliable enough.
Motivation
While the current default format MKV is resilient against crashes, it does not have the greatest compatibility. Most browsers, some video players, and especially many video editors do not support MKV containers (properly).
There are also some known issues with MKV related to how it stores the video's frame rate that can result in issues with playback/seeking in editors, as well as potential issues when writing files with a very high bitrate (such as ProRes).
Additionally, with the upcoming ProRes support generally being expected to use MOV, having a higher resilience for that container as well is desirable.
Another benefit is that the files effectively become "faststart" mp4s without requiring disk-intensive remuxing to move the moov atom to the beginning.
This is beneficial for sharing over the web and can allow platforms such as YouTube to start transcoding while the file is still being uploaded.
View RFC
Demo file for testing compatibility with editor/video players/etc. (no audio): https://user-images.githubusercontent.com/3123295/187082436-80d8eb7d-31d8-4c4b-8ed6-0becebea3898.mp4
As a note, ProRes will probably not be limited to MOV as it's also supported by Matroska (which I tested with the current ProRes implementation. Your concerns with MKV obviously still apply).
As a note, ProRes will probably not be limited to MOV as it's also supported by Matroska (which I tested with the current ProRes implementation. Your concerns with MKV obviously still apply).
That's good to know, although I believe we had issues with matroska related to very high bitrates? Since ProRes usually writes very high bitratess (north of 400 Mbps) I wonder if this applies there as well?
On a very quick test, ProRes 422 HQ at 2160p60 (which resulted in close to 1800Mbps) seemed to work fine (that hardware encoder is damn impressive btw). Though I'd need to know what the issues were originally.
It seems that the issue related to high bitrates may only affect slower SSDs/HDDs (which Macs with ProRes HW encoders obviously won't have), and also has been worked around/addressed with https://github.com/obsproject/obs-studio/pull/5717.
If there's muxer flags being added by default, and those flags are then removed when the user types anything into the custom muxing area, then I think we should have those flags pre-typed into that box by default. That way, advanced users know what's actually going on, and there's no "hidden removal" of these flags; they should have to backspace them themselves.
Updated the RFC to align with the changes implemented in: https://github.com/obsproject/obs-studio/pull/7276
The main change was the usage of a checkbox to allow for disabling fragmented recording, rather than requiring the user to specify empty movflags or something like that. Just to make it more accessible in case it is needed.
Additionally I switched from changing the warning to a notice to having a tooltip on the checkbox explaining what fragmented recording is.
Is this really something we should have an option for in Simple mode? The custom muxer settings already are a sin, and to me this feels like it adds yet another option a user in simple mode shouldn't have to worry about. Especially if we're breaking existing setups anyways be defaulting to "on", I think it should just be enabled, with the setting only being an option in Advanced mode.
Is this really something we should have an option for in Simple mode? The custom muxer settings already are a sin, and to me this feels like it adds yet another option a user in simple mode shouldn't have to worry about. Especially if we're breaking existing setups anyways be defaulting to "on", I think it should just be enabled, with the setting only being an option in Advanced mode.
Existing setups wouldn't be broken since they're already set to mkv. So this would only affect newly created profiles.
I would actually like to use this as an opportunity to remove the custom muxer options from simple mode.
As stated in the PR comments perhaps this should just be part of the drop-down itself (since we have to futz around with that for ProRes anyway) rather than a checkbox.
There are some cases where you might want to disable fragmentation, apparently sharing such videos via simple file upload (e.g. discord) doesn't quite work everywhere, it also requires support for range requests for proper browser playback without a long buffering period. For local payback and editing it doesn't seem to cause any issues however.
We added support for fMOV/fMP4 in 29.1, so the only real thing left to be implemented from this RFC would be making it the default.
As this is already merged to OBS, I'm going to skip FCP and merge this.
Technically this RFC proposed making it the default, which we have not yet done. Though based on feedback we may decide to do so during the next beta period.
The RFC is supposed to be merged before implementation happens, which is why this is fine to merge now. It's a statement of intent, not completion :)