Closed Bug 986926 Opened 9 years ago Closed 2 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
37.65 KB, video/mp4
Details
owl.22khz.vbr.mp3
36.66 KB, audio/mpeg
Details
Attached video 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
Attached audio owl.22khz.vbr.mp3 — 

    
  
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: 5 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: 5 years ago → 2 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.