-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-AAC MP4 audio codec treated as AAC (eg. mp4a.a6: EAC3) #3779
Labels
Comments
I think you're right. We should probably also be looking at the object type after |
ojw28
pushed a commit
that referenced
this issue
Mar 28, 2018
Currently, we are treating all codecs starting with "mp4a" as AAC. However, some codec strings starting with "mp4a" are not AAC format, as should be treated differently. GitHub: #3779 ------------- Created by MOE: https:/google/moe MOE_MIGRATED_REVID=189163517
ojw28
pushed a commit
that referenced
this issue
Mar 29, 2018
Currently, we are treating all codecs starting with "mp4a" as AAC. However, some codec strings starting with "mp4a" are not AAC format, as should be treated differently. GitHub: #3779 ------------- Created by MOE: https:/google/moe MOE_MIGRATED_REVID=189163517
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
The source appears to be
MimeTypes.getMediaMimeType()
:ExoPlayer/library/core/src/main/java/com/google/android/exoplayer2/util/MimeTypes.java
Line 196 in 2b20780
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.
The text was updated successfully, but these errors were encountered: