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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
