Hector Martin

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.

So libopus computes one bitrate-equivalent parameter, at 128kbps, as: 20ms: 127600 10ms: 26800 5ms: -7100 2.5ms: -33050 ... I'm pretty sure that's a bug.