Closed Bug 986926 Opened 11 years ago Closed 4 years ago

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

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr68 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix

People

(Reporter: elbart, Unassigned)

References

Details

(Keywords: losing-users, parity-chrome, parity-edge)

Attachments

(2 files)

owl.22khz.vbr.mp3.mp4
(deleted), video/mp4
Details
owl.22khz.vbr.mp3
(deleted), audio/mpeg
Details
Attached video owl.22khz.vbr.mp3.mp4 (deleted) —
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
Attached audio owl.22khz.vbr.mp3 (deleted) —
Blocks: 799315
Depends on: 986947
Confirmed in nightly 31.0a1 (2014-03-23) Win 7 x64.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Also happening for files with 24kHz and 16kHz, not for files with 32kHz, 44.1kHz or 48kHz.
Flags: needinfo?(cpearce)
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.
Flags: needinfo?(cpearce)
nightly 32.0a1 win8.1 can play the file after its extension name is changed to mp3
Component: Audio/Video → Audio/Video: Playback
Mass closing do to inactivity. Feel free to re-open if still needed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE

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

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

Status: RESOLVED → REOPENED
Has STR: --- → yes
status-firefox75: --- → wontfix
status-firefox76: --- → fix-optional
status-firefox77: --- → affected
status-firefox-esr68: --- → affected
Keywords: losing-users, parity-chrome, parity-edge
OS: Windows 7 → All
Hardware: x86_64 → All
Resolution: INACTIVE → ---
Status: REOPENED → NEW

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...

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.

Depends on: 1696780

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

Status: NEW → RESOLVED
Closed: 6 years ago → 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: