Add muxer support for Dolby Atmos

[rexjin-meta]

Summary

Add support for muxing Dolby Atmos (E-AC-3 JOC) tracks in Mp4Muxer.

Problem

Mp4Muxer and FragmentedMp4Muxer did not support AUDIO_E_AC3 or AUDIO_E_AC3_JOC MIME types. Attempting to mux an E-AC-3 or Dolby Atmos track would fail at the supported-format check, and even if bypassed, the codec-specific box (dec3) and fourcc (ec-3) were not implemented. This made stream-copy of Dolby Atmos audio from one MP4 container to another impossible using the in-app muxer.

Changes

• Boxes.java: Added dec3Box() which wraps the raw EC3SpecificBox payload from format.initializationData (csd-0) verbatim into a dec3 box. Added AUDIO_E_AC3 / AUDIO_E_AC3_JOC cases in codecSpecificBox() and codecSpecificFourcc()
  (fourcc: ec-3).
• Mp4Muxer.java: Added AUDIO_E_AC3 and AUDIO_E_AC3_JOC to SUPPORTED_AUDIO_SAMPLE_MIME_TYPES.
• FragmentedMp4Muxer.java: Same addition to SUPPORTED_AUDIO_SAMPLE_MIME_TYPES.
• BoxesTest.java: Added 3 unit tests — dec3 payload wrapping for E-AC3, dec3 payload wrapping for E-AC3 JOC, and a guard test verifying IllegalArgumentException when csd-0 is missing.

Testing

• ./gradlew :lib-muxer:compileDebugJavaWithJavac — clean compile.
• ./gradlew :lib-muxer:test — all existing tests pass; 3 new unit tests added and passing.
• No device testing yet; the new code path is only exercised during stream-copy (no encoding/decoding involved).

Notes

• This is a stream-copy only implementation. The dec3 payload must be populated in format.initializationData by the caller (e.g. copied verbatim from the source track's EC3SpecificBox). There is no encoding-side support.
• The dec3 payload is carried verbatim with no parsing or validation beyond the non-empty check — consistent with how av1C and dOps are handled.
• Follow-up work: end-to-end test with a real Atmos source file via Mp4MuxerEndToEndParameterizedTest once test assets are available.

[andrewlewis]

Please could you based the changes on the main branch as per the instructions? It would also be good to have a minimal test file as part of the initial pull request.

[rexjin-meta]

hey @andrewlewis , I will send a new PR to main branch.

For the end-to-end test — sample_eac3joc.mp4 is already in the test asset library, so the input file is there.

The blocker is that BoxParser currently parses the dec3 box into Format fields (channel count, sample rate, mime type) but doesn't carry the raw bytes forwardinto initializationData. That's a pre-existing behavior in the extractor.

Since Mp4Muxer needs those raw bytes to write the dec3 box, the end-to-end pipeline doesn't connect yet.
Happy to add the end-to-end test once that extractor behavior is addressed, or if the team has a preferred approach for bridging that gap.

Thank you!