[FFmpeg-devel] [PATCH] movenc: Add an option for hiding fragments at the end

[Martin Storsjö]

On Sat, 1 Jun 2024, Dennis Sädtler via ffmpeg-devel wrote:

> Should the ftyp atom also be updated to remove brands no longer required 
> for non-fragmented files?
> I'm not sure how important that is in real-world scenarios, so it might 
> not be worth it to deal with some of the additional changes required 
> e.g. to deal with the new ftyp possibly being a different size.

Hmm, good point, I hadn't thought about that. I'd prefer not to do that, 
as it becomes a bit more of a mess to change the size of the ftyp.

If we mux a plain default mp4 with h264/aac, we produce this ftyp:

         major_brand = isom : ISO Base Media file format version 1
         minor_version = 512
         compatible_brands
             brand[0] = isom : ISO Base Media file format version 1
             brand[1] = iso2 : ISO Base Media file format version 2
             brand[2] = avc1 : Advanced Video Coding extensions
             brand[3] = mp41 : MP4 version 1

If we add -movflags frag_keyframe, we produce this:

         major_brand = isom : ISO Base Media file format version 1
         minor_version = 512
         compatible_brands
             brand[0] = isom : ISO Base Media file format version 1
             brand[1] = iso6 : ISO Base Media file format version 6
             brand[2] = iso2 : ISO Base Media file format version 2
             brand[3] = avc1 : Advanced Video Coding extensions
             brand[4] = mp41 : MP4 version 1

This has one extra entry in compatible_brands, but it shouldn't affect the 
baseline for what demuxers accept reading the file or not. However if we 
add e.g. "-movflags frag_keyframe+cmaf" (or negative_cts_offsets, or 
default_base_moof), we end up with something like this:

         major_brand = iso6 : ISO Base Media file format version 6
         minor_version = 512
         compatible_brands
             brand[0] = iso6 : ISO Base Media file format version 6
             brand[1] = cmfc
             brand[2] = mp41 : MP4 version 1

So if using this hybrid fragmented/non-fragmented mode, it'd be wise to 
not enable any of those options.

> Since coincidentally I've implemented the exact same feature in a 
> different application a couple weeks ago I'll also throw in the fun fact 
> that files produced this way can be smaller than regular MP4s for long 
> and/or large files.
> This is due to the lack of interleaving of A/V samples resulting in the 
> file having much fewer but larger chunks, which means the moov atom - 
> mainly the stco/co64 and stsc boxes - can be much smaller.

Oh, indeed, that's a good point. But on the other hand, the file ends up 
containing all the leftover moof boxes in the mdat. But are you saying 
that a compact moov + leftover moof, still is smaller than one large moov, 
in your practical test cases?

> Also good to know that Apple thought of this as well. I had no idea 
> about that, but that further justifies adopting this method for 
> achieving resilient but compatible recordings in my mind.

Indeed!

Btw, the patch in this form has one minimal time gap for when the file can 
end up unrecoverable; we patch the mdat size (hiding the moof boxes) 
before we write the moov - if we die at that specific moment, we'd have an 
unreadable file. I guess it should be possible to reorder these two calls 
as well - but it makes for a slightly bigger patch.

// Martin