986926 - MP3-files with sampling rate of 22050Hz is not played at all when in a MP4-container

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[Elbart]

Attachment: owl.22khz.vbr.mp3.mp4

When playing a MP4-container with a MP3-audiotrack with the sampling-rate of 22050Hz, Firefox refuses to play the file at all.

Playing the plain MP3-track does work fine.

Setting media.directshow.enabled to false is no workaround, unlike for bug 986925.

Source for the testfiles: http://mxr.mozilla.org/mozilla-central/source/content/media/test/owl.mp3

Comment 1

[Elbart]

Attachment: owl.22khz.vbr.mp3

Comment 2

[Paul Silaghi, QA [:pauly]]

Confirmed in nightly 31.0a1 (2014-03-23) Win 7 x64.

Comment 3

[Elbart]

Also happening for files with 24kHz and 16kHz, not for files with 32kHz, 44.1kHz or 48kHz.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

We use Windows Media Foundation for playback of MP4s. I'm guessing WMF can't handle this particular variant of MP3 but DirectShow can. We're in the process of changing to use our own MP4 demuxer which will make it easier to decode MP3 in MP4 using DirectShow, so this will be fixed when that happens.

Comment 5

[[e-mail]]

nightly 32.0a1 win8.1 can play the file after its extension name is changed to mp3

Comment 6

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.

Comment 7

[hartnegg]

This bug is the reason why we must now recommend all students to use Google Chrome.

Comment 8

[Darkspirit]

Confirmed on Win10 and Debian Testing. File from comment 0 plays with Chrome and Edge, but not with Firefox.

Comment 9

[nbeisert]

It seems the problem is in the identification of the audio stream codec which happens here:
https://searchfox.org/mozilla-central/source/third_party/rust/mp4parse/src/lib.rs#3335
0x6B => CodecType::MP3,
this is the ID for MPEG-1 layer 3 (frequencies 48000/44100/32000).
the ID for MPEG-2 layer 3 (frequencies 24000/22050/16000) is 0x69.
with some luck adding the other ID will do the trick (MPEG-1/2 do not differ much otherwise):
0x69 | 0x6B => CodecType::MP3,
good luck...

Comment 10

[nbeisert]

This issue has now been addressed in https://github.com/mozilla/mp4parse-rust:
https://github.com/mozilla/mp4parse-rust/issues/274
https://github.com/mozilla/mp4parse-rust/issues/276
It should become available with a future release > v0.11.5.

Comment 11

[Jon Bauman [:jbauman:]]

Now that bug 1696780 has merged, including the update from mp4parse-rust, this should be resolved.