UI: Use fragmented MP4/MOV recording by default

[derrod]

Description

Implementation for RFC obsproject/rfcs#51.

• Adds new checkbox "Fragment MP4/MOV files" to simple and advanced recording settings (only visible with MP4/MOV selected)
• Only shows MP4/MOV warning if fragmentation is not enabled (default is enabled)
• Adds mp4 as a valid input file extension in the remuxing window
• Makes MP4 the default recording format

Screenshot:

Motivation and Context

See https://github.com/derrod/rfcs/blob/fragmented-recording/text/0000-fragmented-recording.md#motivation

tl;dr MKV support isn't great in many places, fragmented MP4 offers the same resilience against crashes, but is more compatible with editors and video players.

How Has This Been Tested?

Recorded a video, verified it was fragmented.

Additionally several users have verified that fMP4 works in various NLEs such as Resolve, Premiere, Kdenlive, etc.

Types of changes

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• [x] My code has been run through clang-format.
• [x] I have read the contributing document.
• [x] My code is not on the master branch.
• [x] The code has been tested.
• [x] All commit messages are properly formatted and commits squashed where appropriate.
• [x] I have included updates to all appropriate documentation.

[derrod]

I've been told that checkboxes are frowned upon, so perhaps if we have to change how the dropdown works for #7010 anyway we could add separate entries for MP4 (fragmented) and MOV (fragmented) alongside the existing entries. Doesn't entirely solve "how do we tell users wtf this is" but would certainly require fewer UI changes.

However, personally I think the checkbox is fine, and I'm happy to offer removing the muxer settings from simple output in return!

[SuslikV]

1. Reason for the '+empty_moov+delay_moov' flags?

~~2) Also, the only frag_keyframe will make fragment on each keyframe literally - this makes fragments to small (in size) for any CRF encoding. The file may grow in size for about 20% (depending on content) because of excessive fragmentation.~~

~~Solution (to p2):~~ ~~The usage of the parameter min_frag_duration=16000000 together with the movflags will make each fragment at least 16 sec long. They still may be short in size, but in my opinion it is way better, than fragment created on each keyframe that is usually is 2 sec only (or less, depending on the content).~~

[derrod]

1. Reason for the '+empty_moov+delay_moov' flags?

empty_moov will cause the entire output to be fragmented, otherwise everything up until the second fragment would be a self-contained "movie". Technically it is redundant because delay_moov sets it as well, so it could probably be omitted (I'd have to check ffmpeg source code again).
The reason delay_moov there is because in some situations (e.g. when using file splitting) the timestamp in the written file may not start with 0, so the muxer could error out if this option is not set.

2. Also, the only frag_keyframe will make fragment on each keyframe literally - this makes fragments to small (in size) for any CRF encoding. The file may grow in size for about 20% (depending on content) because of excessive fragmentation.

That's nonsense and I have no idea where you got that number from. Here's a comparison (CRF 5, default keyint of 250):

5936124776 crf5_fragmented.mp4
5936164678 crf5.mp4

As you can see, the fragmented file is actually smaller. Not by much, just about 40 KiB, but certainly not 20% larger.

Writing as a fragmented file would also actually decrease memory use as the muxer does not have to store information about each packet in memory (see https://www.ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv).

Edit: the only way I found to create fragmented files that are larger than non-fragmented ones was to lower the GOP below 1 second (which OBS odes not allow you to do unless you use manually entered settings). And even then we're talking fractions of a percent.

Edit 2: So the only way I could achieve significant overhead with fragmented recording was to deliberately construct a scenario in which the individual frames are tiny, and fragments are short. For instance: recording a black screen in i-frame only mode. A normal user is pretty much never going to do this. And intermittent black screens will ultimately average out to an amount of overhead that's negligible.

For example, compressing video game footage with ProRes HQ (which is an intra-only codec) gave me an overhead of 0.0076% when compared to a non-fragmented file.

[SuslikV]

That's nonsense and I have no idea where you got that number from...

I was wrong. Assumption was based on encoding small static images with zeroed sound and has no real use case.

[GeorgesStavracas]

Marked as a Draft so that nobody accidentally merges this

[PatTheMav]

Is this fine to merge in tandem with the ProRes/HEVC PR (given that @GeorgesStavracas only draft-ed it to avoid accidental merging)?

We maybe want to create additional PRs to fix remuxing (e.g. shouldn't automatically remux to MP4 with ProRes, maybe remux to MOV by default on macOS), see also the other MKV issues raised by users.

[derrod]

Based on discussion regarding ProRes it might make sense to make MOV the default on macOS and use MP4 on Windows.
As ProRes is incompatible with MP4, and AV1 is incompatible with MOV it so happens that hardware encoding support for those codecs maps perfectly onto those two operating systems.

[gxalpha]

As ProRes is incompatible with MP4, and AV1 is incompatible with MOV it so happens that hardware encoding support for those codecs maps perfectly onto those two operating systems.

This assumes that AV1 hardware encoding won't come to Mac. According to rumors this might change, perhaps even not that far in the future.

[derrod]

This assumes that AV1 hardware encoding won't come to Mac. According to rumors this might change, perhaps even not that far in the future.

Hardware decoding seems likely, encoding I doubt (But since Apple are the arbiters of MOV, perhaps if they actually do add encode support they'd be nice enough to make AV1 a valid codec for MOV as well).

[derrod]

Rebased and conflicts resolved. Also changed mac default to MOV.

[derrod]

Updated with some UI changes to remove the checkbox and also excluded 0785e67ecc925be96993125d82ca7d629e7e6626 to not switch defaults yet.

Changes:

• Removed checkbox
• Format dropdown is now translateable and includes extra entries for fragmented MP4/MOV
• Tooltip now applies to format dropdown instead

[PatTheMav]

Based on discussion regarding ProRes it might make sense to make MOV the default on macOS and use MP4 on Windows. As ProRes is incompatible with MP4, and AV1 is incompatible with MOV it so happens that hardware encoding support for those codecs maps perfectly onto those two operating systems.

Following up on this - did we make this change already? Is this still blocking this PR?

[derrod]

Based on discussion regarding ProRes it might make sense to make MOV the default on macOS and use MP4 on Windows. As ProRes is incompatible with MP4, and AV1 is incompatible with MOV it so happens that hardware encoding support for those codecs maps perfectly onto those two operating systems.

Following up on this - did we make this change already? Is this still blocking this PR?

We have not changed any defaults yet. This PR originally did change it to fragmented MOV on macOS and fMP4 everywhere else but I have opted not to change defaults for now to unblock on that discussion and save that for a later time.

[PatTheMav]

Yeah I'm also fine with making this available to users without changing defaults.

[derrod]

Are there any concerns/objections as far as merging this for the next release goes?

Currently this does not alter any defaults, and only adds the option for using fragmented MOV/MP4 as a recording format, and I would like to encourage users to test this as part of the 30 Beta to make decisions regarding the change of defaults proposed in https://github.com/obsproject/rfcs/pull/51 for a future release.

[PatTheMav]

I think @RytoEX has not finished the review yet? Otherwise I was fine with it.

[RytoEX]

Let me take another look next week, but it seemed largely fine to me.