Opus, the Swiss Army Knife of Audio Codecs
Sep. 7th, 2011 09:45 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jmvalinI just got the news today that LCA 2011 has accepted my talk proposal: "Opus, the Swiss Army Knife of Audio Codecs". I'll be presenting it in Ballarat, Australia in January. If there's any specific topic you'd like me to include in the talk, please let me know (by email or comment on this post).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Audiobooks?
Date: 2011-09-08 08:58 am (UTC)I'd imagine the long length of audiobooks means even small bitrate advantages can add up, and the difference could be substantial if you were using a mix of content suited to both modes.
Re: Audiobooks?
Date: 2011-09-08 02:15 pm (UTC)Container
Date: 2011-09-11 01:05 pm (UTC)Re: Container
Date: 2011-09-11 04:59 pm (UTC)Re: Container
Date: 2011-09-12 03:53 am (UTC)Maybe my use of the phrase "directly streambable" was a little bit ambiguous. What I meant was a container that you can listen to(network) a stream of it at any seek point. A file that you can split with dd and still being able to listen to(with ears) or watch the now-split parts. ADTS MP3 and MPEG-TS can do this for example.
One use-case of this is udp:// live streaming with ffmpeg.
As I can't do this with files transcoded/remuxed by tools like ffmpeg oggenc and speexenc. I'm wondering If this is an optional capability of OGG! Or does Icecast use a completely different approach/method?
"want is a different extension, just name your files differently."
I wasn't suggesting this for my personal use. I'm just worried that a lot of people -who don't know what magic numbers and file headers are- will get confused (Or even worse, unaware of Opus's presence).
People have been listening to ogg/oga files mostly with vorbis. Luckily, SPEEX and FLAC had their own extensions. So, not a lot of confusion had taken place.
Adding Opus to the mix and with no dedicated advertised extension (even if nothing is actually different underneath) will cause at least some confusion, I'm worried. Or maybe I'm underestimating the masses.
"There's no point into inventing a new container just to change the extension."
Hence the subset suggestion.
"That being said, one of the goals of the Ogg mapping we did was to make it easy for others to wrap Opus into their own favorite container, be it Matroska, Nut, Quicktime, or anything else."
Good to hear.
Thank you for your reply (and nullc's of course). And I apologise if I got somewhat off-topic in this reply.
Re: Container
Date: 2011-09-13 04:44 am (UTC)> ambiguous. What I meant was a container that you can listen to(network)
> a stream of it at any seek point. A file that you can split with dd and
> still being able to listen to(with ears) or watch the now-split parts.
> ADTS MP3 and MPEG-TS can do this for example.
Ogg itself can do this (of all the other containers in existence it's most similar in spirit/goals to MPEG-TS). Unlike MP3 Ogg also provides good support for accurate seeking without scanning the whole file.
Many codecs in Ogg need non-trivial setup headers that make blindly joining them in the middle impossible, Opus doesn't, however. (well, greater than stereo multichannel streams will need a channel layout header). We avoided the headers because they're burdensome over unreliable transports (e.g. RTP/UDP), I haven't encountered much concern about the headers in other codecs in ogg otherwise.
That said, a dd-level cut won't produce a totally valid file because it won't have the stream identification metadata. You can easily make it valid again by tagging some onto the front (which is, incidentally, what icecast does: copies the initial headers onto the stream wherever you join then sends the rest unmodified).
The way opus is speeced you could periodically repeat the initial headers without harm (they can be distinguished from paylod, though not much else can be), but adding that metadata throught the file in a mandatory way would add overhead we don't want, to address a use case that can be equally addressed by replacing dd with something only very slightly smarter (e.g. oggz-chop).
You have to keep in mind— with the low latencies we support overhead is critical. A _single_ byte of additional overhead per frame adds 3.2kbit/sec for our lowest latency modes. We support direct streaming but the streaming environment has to provide at least framing (the ability to distinguish one opus frame from the next) and identification (the ability to distinguish opus from anything else). Because of the avoidance of overhead there is so little redundancy in opus itself that much of the time /dev/urandom is outputting a perfectly valid opus stream.
Re, extensions: If people are using ".oga" with vorbis then they're doing something strongly non-recommended. Dunno what to say about that. I think it's uncommon enough that it won't matter too much. I expect that opus usage be so much larger than any other oga usage soon enough that there won't be any real suffering.
Re: Container
Date: 2011-09-14 02:21 pm (UTC)"That said, a dd-level cut won't produce a totally valid file because it won't have the stream identification metadata. You can easily make it valid again by tagging some onto the front (which is, incidentally, what icecast does: copies the initial headers onto the stream wherever you join then sends the rest unmodified)."
Sounds like what RTMP servers do to FLV sources. As a user of both icecast and rtmpd(crtmpserver), I find the downside of relying on such tools is that they bind you to specific protocols and force you to use a setup that you might not want to use.
"but adding that metadata throught the file in a mandatory way would add overhead we don't want, to address a use case that can be equally addressed by replacing dd with something only very slightly smarter (e.g. oggz-chop)."
What if I want to receive a stream from a network source and dump it to a network interface? And I don't control when the source stops and when It starts streaming again. Would oggz-chop help in a scenario like this one? Can I use whatever network tool/protocol I like in a scenario like this one? If the answer is yes, then I have nothing to complain about as all I(and I assume others) ask for is complete flexibility in choosing streaming solutions.
If the answer is no, Is there a chance we can have metadata replication as an option for those of us who care about flexibility and don't mind a slight overhead? Is there a tool that I can test that outputs such streams?
Re: Container
Date: 2011-09-11 05:36 pm (UTC)(and thanks for asking for direct streamability, thats important to me too and thats why we use Ogg by default)