Closed Bug 1504944 Opened 2 years ago Closed 2 years ago
Don't re-order audio channels for Opus channel mapping 2 (ambisonic) and 255
47 bytes, text/x-phabricator-request
|Details | Review|
We currently re-order those channels if the channel count is less than 8. We shouldn't as for channel mapping 2 and 255, the SMPTE order is meaningless (as we're not talking Left, Right, Centre etc..)
For channel mapping 0 (which is always mono or sterero), the mapping is identical to the SMPTE one, so can copy the mapping as-is.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/4d1ac3ae7fb9 Only re-order channels for opus mapping 1. r=padenot
Comment on attachment 9022847 [details] Bug 1504944 - Only re-order channels for opus mapping 1. r?padenot! [Beta/Release Uplift Approval Request] Feature/Bug causing the regression: None User impact if declined: Channels aren't produced in the right order. Proper audio order is required for WebVR, such as YouTube 360 Is this code covered by automated tests?: No Has the fix been verified in Nightly?: Yes Needs manual test from QE?: Yes If yes, steps to reproduce: Try the link site, clicking on the channel 1, you should be hearing "this is channel 1", and the right value for each channel. List of other uplifts needed: None Risk to taking this patch: Low Why is the change risky/not risky? (and alternatives if risky): There's no code risk. However, some sites may have been relying on the wrong order. Will contact sites known to use it directly (such as Facebook) String changes made/needed: none
Attachment #9022847 - Flags: approval-mozilla-beta?
Hans, this change may have an impact if you were using Opus mapping 255 with a channel count of 4 to 8. Those channels would have been incorrectly re-ordered. They will now be ordered exactly as stored in the opus file
Comment on attachment 9022847 [details] Bug 1504944 - Only re-order channels for opus mapping 1. r?padenot! webvr audio fix, approved for 64.0b9 or 64.0b10
Attachment #9022847 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I have managed to reproduce the issue using Fx65.0a1 buildID: 20181106220104. The issue is verified as fixed using Fx64.0b10 and latest Fx65.0a1 on macOS 10.14.1, Ubuntu 16.04 and Windows 10 x64. The channels are now correctly ordered and paired with their corresponding number.
You need to log in before you can comment on or make changes to this bug.