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.
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.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
JMR-devandClaude Opus 5
00c422f317