MP3 decoding fails arbitrarily; network/cache loading behaviour difference?




Audio/Video: Playback
5 years ago
3 years ago


(Reporter: Andrew Stibbard, Unassigned)


Windows 7

Firefox Tracking Flags

(Not tracked)




5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131107161719

Steps to reproduce:

I'm seeing a severe non-deterministic MP3 loading/decoding error on the game I developed at . I haven't observed this before as previous versions of Firefox have loaded the OGGs instead. Chrome has always loaded the MP3s and consistently works as expected.

Each sound effect is a separate short MP3 that is loaded on an instantiated Audio object.

1. Open console/Firebug.
2. Load and wait for the loading screen to get stuck loading audio.
3. Look through the console output for decoding errors. Note that these appear only for me in Firebug, not the native dev tools, but the behaviour is the same.

First noticed on Firefox 26b1, confirmed on Firefox 26b2, and still present on Firefox 28a trunk nightly dated 09-Nov-2013 12:28 with a blank profile.

Alternate steps to observe the problem:
1. Open a tab and load . The file should load and play properly.
2. Open a new tab and load and wait for it to get stuck loading audio.
3. Go back to the previous tab and reload. "Video can't be played because the file is corrupt" appears.

Actual results:

Firefox arbitrarily reports that one or more of the MP3s could not be decoded, but subsequent reloads of the page (including non-cache reloads) can report that the same files loaded fine, but others failed instead.

When restarting the browser and clicking on the tab again to "lazy load" it, the audio files will decode without error and the game will start, which makes me think the issue is related to network vs cache loading.

You can also observe it by loading some of the files directly in the address bar (see alternate steps above), but they'll frequently load/decode properly for minutes at a time until the game is reloaded in another tab and gets stuck, whereupon the files will start showing the "Video can't be played because the file is corrupt" message. Waiting a few minutes then reloading the file will result in it loading/decoding correctly again.

Direct links for two files that frequently error after attempting to start the game:

Expected results:

The loading screen on the game should progress to 32/32 audio and begin animating as expected.

Comment 1

5 years ago
Possibly related to the concurrent audio playback/decoding limits mentioned in ?

When the game does load, taking one of the characters and punching another repeatedly can cause MP3s to stop playing altogether for a few seconds. Hitting another character plays two sounds very closely together (a swing and a hit sound) and doing this repeatedly will result in overlap.

Unfortunately the point at which sounds stops playing is arbitrary as well. :/
You're probably seeing bug 882537 (which is the bug tracking the problem that I outlined in bug 846264 comment 7 that you pointed out).

Could you check if the bug is fixed in this build:

(You'll need to close other open firefox instances when you start this up).

That build uses DirectShow instead of Windows Media Foundation for MP3 playback, so it shouldn't be effected buy bug 882537. It would be good to know if the bug is fixed in this build.

Unfortunately we had to switch MP3 decoding back to WMF from DirectShow on Win7 because of another bug, but we're planning to get it fixed and re-enable DirectShow MP3 decoding soon. I hope using the DirectShow backend fixes this.
In fact I was able to test this on my Win7 machine myself on your jsrage example, and was able to reproduce the problem using MP3 playback using WMF but not using DirectShow. So we should be able to get this fixed once Edwin gets a fix in bug 918135.
Depends on: 918135

Comment 4

5 years ago
Thanks Chris -- that build loads the audio correctly and consistently across multiple reloads.
Component: Audio/Video → Audio/Video: Playback
You need to log in before you can comment on or make changes to this bug.