1234778 - decode audio errors since 45

Status: RESOLVED FIXED

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

Description

[alex.vandenabeele]

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: http://users.telenet.be/ava/unity/sound/index.html 

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: http://forum.unity3d.com/threads/audio-broken-since-5-3-1.375541

Maybe related to https://bugzilla.mozilla.org/show_bug.cgi?id=1234102

Thanks for any help!

Comment 1

[Gingerbread Man]

Push log:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=47b49b0d32360fab04b11ff9120970979c426911&tochange=66a6d7ec9534b9d7847b665142fef0dd87623768

Jean-Yves, I suspect this may have been regressed by bug 1227396.

Comment 2

[Jean-Yves Avenard [:jya]]

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

Comment 3

[Jean-Yves Avenard [:jya]]

Attachment: Mark all audio frames as keyframe.

Comment 4

[Jean-Yves Avenard [:jya]]

[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)

Comment 5

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Jean-Yves - we should probably have a test... because web developers.

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/51354eb12581

Comment 8

[Josh Cheng [:josh]]

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!

Comment 9

[Jean-Yves Avenard [:jya]]

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

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/51354eb12581

Comment 11

[Jean-Yves Avenard [:jya]]

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

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a7d36d3c727c