Media3Engine never called setMuxerFactory or setAudioMimeType, and built a bare EditedMediaItem, so it always produced MP4 with an H.265 video track. The router meanwhile sends it WebM, Ogg, WAV and AAC-ADTS jobs, plus audio-only M4A, Opus and WAV — and ConversionWorker.media3MimeType() mapped VideoCodec.NONE through its else branch to VIDEO_H265.
The visible result: "extract audio to M4A" transcoded the video to HEVC and named the file .m4a. Nothing failed, and nothing caught it, because Media3EngineTest had no audio-only case at all.
What changed
media3-muxer already ships WebmMuxer, OggMuxer, WavMuxer and AacMuxer; only the MP4 ones come pre-wrapped as a Muxer.Factory. Media3Muxers supplies the rest. Their reported sample MIME types are read from each muxer's own support check rather than assumed, because Transformer uses those lists to decide whether a track needs re-encoding.
HardwareTranscoder.transcode now takes the OutputFormat instead of a video MIME string, which is what gives the container, the audio codec and "this output has no video" somewhere to travel.
MEDIA3_CONTAINERS stops being private so a test can assert it agrees with the factories. Those two drifted once already: the router's set was right the whole time the engine was ignoring it.
Verification
:app:testDebugUnitTest — 71 tests green (66 existing + 5 new in Media3MuxersTest).
Three new instrumented cases in Media3EngineTest: audio-only M4A asserts exactly one AAC track and no video track (the regression guard for the bug above), plus RIFF and OggS header checks for WAV and Ogg.
⚠️The instrumented tests have not been executed — the emulator segfaults on my machine (exit 139 across three AVDs and both GPU backends, environmental). This PR's CI run is the first real exercise of them. WAV and Ogg output through the new muxers are newly reachable and unproven; setAudioMimeType(AUDIO_RAW) for WAV assumes Transformer does PCM passthrough, which is plausible from the muxer's reported MIME list but not verified. If those two come back red, the honest fix is dropping WAV and OGG from MEDIA3_CONTAINERS — Media3MuxersTest will then require the matching factories to go too, which is the right coupling. runMedia3OrFallBack already catches export failures and reruns on FFmpeg, so the failure mode is "slower", not "wrong file".
Media3Engine never called `setMuxerFactory` or `setAudioMimeType`, and built a bare `EditedMediaItem`, so it always produced MP4 with an H.265 video track. The router meanwhile sends it WebM, Ogg, WAV and AAC-ADTS jobs, plus audio-only M4A, Opus and WAV — and `ConversionWorker.media3MimeType()` mapped `VideoCodec.NONE` through its `else` branch to `VIDEO_H265`.
The visible result: **"extract audio to M4A" transcoded the video to HEVC and named the file `.m4a`.** Nothing failed, and nothing caught it, because `Media3EngineTest` had no audio-only case at all.
## What changed
`media3-muxer` already ships `WebmMuxer`, `OggMuxer`, `WavMuxer` and `AacMuxer`; only the MP4 ones come pre-wrapped as a `Muxer.Factory`. `Media3Muxers` supplies the rest. Their reported sample MIME types are read from each muxer's own support check rather than assumed, because Transformer uses those lists to decide whether a track needs re-encoding.
`HardwareTranscoder.transcode` now takes the `OutputFormat` instead of a video MIME string, which is what gives the container, the audio codec and "this output has no video" somewhere to travel.
`MEDIA3_CONTAINERS` stops being private so a test can assert it agrees with the factories. Those two drifted once already: the router's set was right the whole time the engine was ignoring it.
## Verification
- `:app:testDebugUnitTest` — 71 tests green (66 existing + 5 new in `Media3MuxersTest`).
- Three new instrumented cases in `Media3EngineTest`: audio-only M4A asserts exactly one AAC track and **no video track** (the regression guard for the bug above), plus RIFF and OggS header checks for WAV and Ogg.
⚠️ **The instrumented tests have not been executed** — the emulator segfaults on my machine (exit 139 across three AVDs and both GPU backends, environmental). This PR's CI run is the first real exercise of them. WAV and Ogg output through the new muxers are newly reachable and unproven; `setAudioMimeType(AUDIO_RAW)` for WAV assumes Transformer does PCM passthrough, which is plausible from the muxer's reported MIME list but not verified. If those two come back red, the honest fix is dropping WAV and OGG from `MEDIA3_CONTAINERS` — `Media3MuxersTest` will then require the matching factories to go too, which is the right coupling. `runMedia3OrFallBack` already catches export failures and reruns on FFmpeg, so the failure mode is "slower", not "wrong file".
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Media3Engine never called
setMuxerFactoryorsetAudioMimeType, and built a bareEditedMediaItem, so it always produced MP4 with an H.265 video track. The router meanwhile sends it WebM, Ogg, WAV and AAC-ADTS jobs, plus audio-only M4A, Opus and WAV — andConversionWorker.media3MimeType()mappedVideoCodec.NONEthrough itselsebranch toVIDEO_H265.The visible result: "extract audio to M4A" transcoded the video to HEVC and named the file
.m4a. Nothing failed, and nothing caught it, becauseMedia3EngineTesthad no audio-only case at all.What changed
media3-muxeralready shipsWebmMuxer,OggMuxer,WavMuxerandAacMuxer; only the MP4 ones come pre-wrapped as aMuxer.Factory.Media3Muxerssupplies the rest. Their reported sample MIME types are read from each muxer's own support check rather than assumed, because Transformer uses those lists to decide whether a track needs re-encoding.HardwareTranscoder.transcodenow takes theOutputFormatinstead of a video MIME string, which is what gives the container, the audio codec and "this output has no video" somewhere to travel.MEDIA3_CONTAINERSstops being private so a test can assert it agrees with the factories. Those two drifted once already: the router's set was right the whole time the engine was ignoring it.Verification
:app:testDebugUnitTest— 71 tests green (66 existing + 5 new inMedia3MuxersTest).Media3EngineTest: audio-only M4A asserts exactly one AAC track and no video track (the regression guard for the bug above), plus RIFF and OggS header checks for WAV and Ogg.⚠️ The instrumented tests have not been executed — the emulator segfaults on my machine (exit 139 across three AVDs and both GPU backends, environmental). This PR's CI run is the first real exercise of them. WAV and Ogg output through the new muxers are newly reachable and unproven;
setAudioMimeType(AUDIO_RAW)for WAV assumes Transformer does PCM passthrough, which is plausible from the muxer's reported MIME list but not verified. If those two come back red, the honest fix is dropping WAV and OGG fromMEDIA3_CONTAINERS—Media3MuxersTestwill then require the matching factories to go too, which is the right coupling.runMedia3OrFallBackalready catches export failures and reruns on FFmpeg, so the failure mode is "slower", not "wrong file".🤖 Generated with Claude Code