Non-AAC MP4 audio codec treated as AAC (eg. mp4a.a6: EAC3)

[tedjp]

Issue description

ExoPlayer treats all codec strings that start with "mp4a" as AAC. However any audio codec packaged as MP4 will match that signature; the string following the "mp4a." prefix needs to be examined to determine the codec. For example the strings "mp4a.a5" and "mp4a.a6" (AC3 and EAC3) are treated by ExoPlayer as AAC.

The codecs "mp4a.a6" and "mp4a.a6" (at least) should not be treated as AAC. Some other codec string samples that begin with "mp4a" but are not AAC are listed at https://developers.google.com/cast/docs/media , for example:

• mp4a.a5 (AC3)
• mp4a.a6 (EAC3)
• mp4a.69 (MP3)
• mp4a.6B (MP3)

The source appears to be MimeTypes.getMediaMimeType():

ExoPlayer/library/core/src/main/java/com/google/android/exoplayer2/util/MimeTypes.java

Line 196 in 2b20780

} else if (codec.startsWith("mp4a")) {

The "mp4a" codec strings appear to be correct according to the DASH spec (ISO/IEC 23009-1:2014 § 5.3.7.2 "Semantics") which says that codec strings shall be RFC 6381 Section 3.3 strings (ie. "mp4a.…").

A common workaround is to use "ac-3" and "ec-3" which appears to me to be nonstandard. (Perhaps there's a newer, more relaxed spec, or I misunderstood it?)

Expected behavior:

Representations with codecs such as "mp4a.a6" should be treated as the correct codec (eg. "audio/eac3") and not selected for playback if unsupported.

Reproduction steps

Find or modify a DASH manifest so that one of the audio AdaptationSets contains the attribute codecs="mp4a.a6" and observe that it is selected for playback despite EAC3 being unsupported on Android (so I'm told) and the player stops.

Link to test content

No public sample. Will provide privately.

Version of ExoPlayer being used

3rd party says "I think it was Exo 2.6.0"

Device(s) and version(s) of Android being used

3rd party says "I think it was … Android 7.0 and 7.1.1"

A full bug report captured from the device

Can request this from 3rd party if necessary. Hopefully the steps to reproduce will be sufficient.

[ojw28]

I think you're right. We should probably also be looking at the object type after mp4a., values for which are defined here.