Closed Bug 1234778 Opened 7 years ago Closed 7 years ago

decode audio errors since 45


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

45 Branch
Windows 7
Not set



blocking-b2g 2.5+
Tracking Status
firefox44 --- unaffected
firefox45 + fixed
firefox46 --- fixed


(Reporter: alex.vandenabeele, Assigned: jya)




(Keywords: regression, testcase)


(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151221151411

Steps to reproduce:

This is a Unity WebGL test project: 

When started it starts playing a sound (an annoying one, I know)

Actual results:

With firefox 44 and before you'll hear the sound, but with firefox 45 and 46 we get audio decode errors:

The buffer passed to decodeAudioData contains invalid content which cannot be decoded successfully. index.html
Decode error. e80c3ebf-0e8c-4eb9-a1d6-0c65195103c7:1:209815
EncodingError: The given encoding is not supported. <unknown>

Expected results:

We've tested this on multiple browsers and only the 45+ builds of Firefox give these results. We also tried this with multiple Unity versions but the results are the same.

Did something change in the audio decoding since 45?

We're discussing this issue also here:

Maybe related to

Thanks for any help!
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Push log:

Jean-Yves, I suspect this may have been regressed by bug 1227396.
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → Audio/Video: Playback
Ever confirmed: true
Flags: needinfo?(jyavenard)
Keywords: regression, testcase
Product: Firefox → Core
Blocks: 1227396
This audio mp4 is incorrectly muxed. None of the audio frames are tagged as keyframe when they should be.
As a frame to be playable, must have a keyframe: none of the samples are added to our array.

I will craft a workaround, but this is first and foremost a muxing issue
Flags: needinfo?(jyavenard)
Attachment #8701466 - Flags: review?(gsquelart)
[Tracking Requested - why for this release]: This is a regression from 44. Could be argued that the data is invalid, but seeing that it used to work (and Netflix had the same issues on some of their mp4 audio)
Assignee: nobody → jyavenard
Attachment #8701466 - Flags: review?(gsquelart) → review+
Jean-Yves - we should probably have a test... because web developers.
Flags: needinfo?(jyavenard)
Duplicate of this bug: 1234102
blocking-b2g: --- → 2.5+
Blocks: TV_P1
Hi Jean-Yves,
Thanks for helping this issue. This bug cause m4a/latm audio playback fail in 2.5 TV which is a major blocker now.
We will need to have this bug fixed and tested on real TV before Jan/8(also uplift to branch b2g44). 
It seems so far so good as the patch is already review+. Please let me know if there is any risk that it can not be fix by then. Thanks!
Why would it be in b2g 44? The issue was introduced in gecko in 45 only.

You can't uplift that change alone in 44 as it depends on bug 1227396 which can't be uplifted easily to 44 without some work.

And again, the issue is about *invalid* MP4. I doubt you'll find those commonly in real MP4 files
Flags: needinfo?(jyavenard)
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Comment on attachment 8701466 [details] [diff] [review]
Mark all audio frames as keyframe.

Approval Request Comment
[Feature/regressing bug #]:1234102
[User impact if declined]: Some audio files will no longer play, regression from 44
[Describe test coverage new/current, TreeHerder]: In central, local test.
[Risks and why]: Ultra low, all audio frames should be marked as keyframe. We just stop relying on the information in the container, same logic already done for fragmented mp4
[String/UUID change made/needed]: none
Attachment #8701466 - Flags: approval-mozilla-aurora?
Attachment #8701466 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.