Ignore decoder specific info for object types 0x69 and 0x6B #227
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ation depend on the value of DecoderConfigDescriptor.objectTypeIndication. But for audio, mp4parse treats all decoder specific information as if it has the bit syntax defined for object type indication 0x40. This is not the case for object type indications 0x69 and 0x6B, which now have more recently defined decoder specific information with a distinct bit syntax, which Mozilla code can disregard. This allows tracks carrying MP3 audio to be parsed correctly when the new decoder specific info is present.
jkcalhoun
force-pushed
the
ignore_decoder_specific_info_for_object_types_0x69_and_0x6B
branch
from
89c725e
to
1757d24
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In connection with issue #319 —
Per ISO 14496-1 § 7.2.6.7.2, the semantics of decoder specific information depend on the value of DecoderConfigDescriptor.objectTypeIndication. But for audio, mp4parse treats all decoder specific information as if it has the bit syntax defined for object type indication 0x40. This is not the case for object type indications 0x69 and 0x6B, which now have more recently defined decoder specific information with a distinct bit syntax (now published as ISO 14496-3:2019 § 9.D.2.2).
The bit syntax of decSpecificInfo for object type indications 0x69 and 0x6B is as follows:
- 32 bits containing a representative MPEG audio frame header, from which the ID (i.e. MPEG-1 or MPEG-2), layer, sampling_frequency, and mode can be derived, if needed prior to or separately from access to the media data,
- 9 bits containing the maximum value of main_data_begin, or an upper bound thereof, for use in determining how many prior MPEG audio frames should be decoded at a random access point, and
- 7 bits of reserved flags.
Mozilla apparently doesn't need this information in order to decode MP3 audio tracks in MPEG-4 files successfully, and therefore simply skipping it — and averting the failure that now occurs — seems like a fine choice. Other implementations may require it.
Example: run the dump example tool on the attached MPEG-4 files
big_buck_bunny_h264-mp3+decSpecificInfo.mp4.zip
.
Kimiko Ishizaka - J.S. Bach- -Open- Goldberg Variations, BWV 988 (Piano) - 01 Aria.mp3.mp4.zip