Add hybrid MP4 muxer for crash-safe recording with non-fragmented fin…

[anthonybajoua]

Summary:

Hybrid MP4 support involves ending up with a normal, non-fragmented file on happy path cases, while still keeping the file readable via its interim state as fragmented mp4 allowing for crash/fault tolerance.

See Writing an MP4 Muxer for fun and profit for more details.

Components:

• HybridMp4Muxer / HybridMp4Writer are implementations of hybrid MP4 melding the current FragmentedMp4Muxer with some bookkeeping to convert it at the end.
• HybridMp4MuxerEndToEndTest which adds tests to the fault tolerance, as well as assertions of having no output.
• TransformerDemo: Integrates this logic into the TransformerDemo. To test one can transform a large file and in realtime do

adb pull /sdcard/Android/data/androidx.media3.demo.transformer/cache/

❯ mp4dump /Users/anthonybajoua/cache/transformer-output-3879342.mp4 | grep sidx

❯ mp4dump /Users/anthonybajoua/cache/transformer-output-3879342.mp4 | grep moov
[moov] size=8+810206

Credit

Inspired by FFmpeg-devel ingesting all of the optimizations from FFmpeg 8.1

[shahdDaghash]

Hi @anthonybajoua,

Thank you for putting together this PR. We would like to understand a bit more about the specific need for this feature.

You mentioned that the main goal here is to keep the file readable for crash/fault tolerance. However, our normal MP4 files are already recoverable on a crash because our current implementation updates the moov box periodically.

You can find the documentation for this behavior in Mp4Muxer.java, and the implementation detailing the periodic updates in Mp4Writer.java.

Could you take a look and let us know if using the existing Mp4Muxer implementation covers your crash-tolerance needs?

Looking forward to your thoughts!

[anthonybajoua]

Thanks for taking a look @shahdDaghash ! The specific use-case is long running video recording sessions that may encounter process crash, battery death.

Mp4Writer appears fault tolerant only up to a point as it pre-allocates 400KB at the beginning and if the moov is greater than the fault-tolerance is lost. See this code snippet.

In local testing, transcoding a 1GB file the file is the beginning it's viewable. Once the file becomes too large the mp4 format is as follows and unplayable. This transition happens around 20 minutes in

❯ mp4dump /Users/anthonybajoua/cache/transformer-output-58235394.mp4
[ftyp] size=8+20
  major_brand = isom
  minor_version = 20000
  compatible_brand = isom
  compatible_brand = iso2
  compatible_brand = mp41
[free] size=8+400000
[mdat] size=16+258480877

Hybrid MP4 will not have this problem as the media is fragmented all the way through until a final pass at hiding the sidx and moof boxes.

[ychaparov]

The amount of space reserved is configurable via an API on Mp4Muxer - do you have an estimate of how long the recording could be?

Would a much larger amount of reserved bytes for moov work for your use case?

[SheenaChhabra]

@anthonybajoua I would like add some more details.

Mp4Writer appears fault tolerant only up to a point as it pre-allocates 400KB at the beginning

If the preallocated space is not enough, even then moov box is written periodically but after the mdat box. So it will still be fault tolerant. The moov box might not have upto date data but it will still preserve some in case of crash.

Code reference

In your local testing do you not see a moov box after the mdat box?