Hector Martin

The official "fix" for this is to tell the *decoder* to ignore the feature, and that software should tell the decoder when the output is going to be downmixed. Obviously, nobody does this, it is impossible to do in many frameworks, and it can't account for external downmixing.

This whole thing was such a mess that the Opus guys had to add *alternate* official decodings to the official spec, because now there are two valid ways of decoding an Opus bitstream: ignoring phase inversion, or not. Which is pretty insane when you think about it.

I hope they tweak the encoder to use this less aggressively, so it doesn't become a big gotcha for people who aren't aware that Opus kills mono compatibility by default. But now that you know, you can just turn it off yourself.

Storytime: I noticed this 2 years ago. I had set up an awesome low-latency network stream for @euskalencounter, using WebRTC and Opus. 70ms end to end latency. It sounded great when I set it up, but later during another event... I noticed really bad audio quality.

It wasn't the mono that I noticed (the audio was coming from some YouTube video on the feed end, it could've just been mono), but rather the artifacts. I thought the source video was bad, but then the next one also sounded bad... and I realized it was my stream.

I thought Opus was broken until someone on IRC pointed me at this feature. Turns out I had not configured the channel count in my RTP descriptor, and some Chrome update had changed behavior: now it downmixed to mono if not explicitly told the stream was stereo in the descriptor.

Anyway, I fixed the descriptor, but I also didn't want anyone with a mono path to end up getting crappy audio. At the time gstreamer did not support setting the no phase inversion flag, so I had to patch libopus to turn it off unconditionally.

Addendum: after a bit of further investigation, this is *particularly* horrible at 2.5ms frame sizes (which I use for the stream to keep latency down) with libopus. This might be a bug, as the RFC makes no mention of frame size affecting the intensity coding threshold.