Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Support MP3 audio in MPEG-4 per ISO/IEC 14496-3:2009 § 9.D.2.2 #319

Open
jkcalhoun opened this issue Jul 11, 2021 · 2 comments
Open

Support MP3 audio in MPEG-4 per ISO/IEC 14496-3:2009 § 9.D.2.2 #319

jkcalhoun opened this issue Jul 11, 2021 · 2 comments

Comments

@jkcalhoun
Copy link

jkcalhoun commented Jul 11, 2021

As described for pull request #227, mp4parse currently mishandles and fails to play MP3 audio carried in MPEG-4 files according to the updated specification published as ISO/IEC 14496-3:2009.

For more details please see the pull request, along with the test cases that were uploaded in connection with it.

@jkcalhoun jkcalhoun changed the title Support MPEG audio in MPEG-4 per ISO/IEC 14496-3:2009 § 9.D.2.2 Support MP3 audio in MPEG-4 per ISO/IEC 14496-3:2009 § 9.D.2.2 Jul 11, 2021
@baumanj
Copy link
Contributor

baumanj commented Jul 12, 2021

Thanks for the report and the PR. It may take a bit to get around to this due to relative priorities and limited resources, but I just wanted you to know it's been seen and is in the queue.

@jkcalhoun
Copy link
Author

Thanks for the report and the PR. It may take a bit to get around to this due to relative priorities and limited resources, but I just wanted you to know it's been seen and is in the queue.

Thanks for the update.

Some relevant history: some 5 or 6 years ago Mozilla requested broader interoperability for object types 0x69 and 0x6B when carried in MPEG-4, and in response a proposal was made to MPEG to define decoder specific info for those object types in order to remove the remaining barriers to broader adoption. The problem with the decoder specific info documented here, originally present in Mozilla's version of Stagefright, was known at the time, but because it nevertheless offered the best available solution to achieve Mozilla's goal of broader interoperability, it's what the standards body approved. A fix in Stagefright was described, but in the transition to mp4parse-rust that fix never made its way into a build.

Various parties can move forward on writing object types 0x69 and 0x6B with greater interoperability when the decoder specific info can be handled benignly.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants