Skip to main content

Topic: Opus is now RFC6716, version 1.0.1 released! (Read 77124 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • xiphmont
  • [*][*][*]
  • Developer
Opus is now RFC6716, version 1.0.1 released!
"Mozilla and the Xiph.Org Foundation are pleased to announce the Internet Engineering Task Force (IETF) has standardized Opus as RFC 6716. Opus is the first state-of-the-art, fully Free and Open audio codec ratified by a major standards organization."

Full announcement at xiph.org/press/2012/rfc-6716

Yay!
  • Last Edit: 11 September, 2012, 03:46:58 PM by Frank Bicking

  • bawjaws
  • [*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #1
https://hacks.mozilla.org/2012/09/its-opus-...codec-standard/

Quote
In a great victory for open standards, the Internet Engineering Task Force (IETF) has just standardized Opus as RFC 6716.

Opus is the first state of the art, free audio codec to be standardized. We think this will help us achieve wider adoption than prior royalty-free codecs like Speex and Vorbis. This spells the beginning of the end for proprietary formats, and we are now working on doing the same thing for video.

  • eahm
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #2
Great news!

The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.
  • Last Edit: 11 September, 2012, 04:12:06 PM by eahm

  • IgorC
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #3
Congratulations, Guys, Great job! 

The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.

1.0.1 isn't the latest. If You want the latest then  try an experimental branch.

P.S. Waiting for native Android support . 
  • Last Edit: 11 September, 2012, 04:27:21 PM by IgorC

  • eahm
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #4
The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.

1.0.1 isn't the latest. If You want the latest then  try an experimental branch.

No. When you say latest you mean latest stable.
  • Last Edit: 11 September, 2012, 04:58:01 PM by eahm

  • yourlord
  • [*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #5
Congrats and great work guys!

  • jensend
  • [*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #6
PARTY TIME!

  • benski
  • [*][*][*][*][*]
  • Developer
Opus is now RFC6716, version 1.0.1 released!
Reply #7
Is storage in the Ogg container format intended to be the go-forward standard for encoding of local files with the Opus codec?
  • Last Edit: 11 September, 2012, 07:09:07 PM by benski

  • Dynamic
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #8
Is storage in the Ogg container format intended to be the go-forward standard for encoding of local files with the Opus codec?


From the link through from the Opus homepage to the Ogg-Opus page, it appears so, and it's quite highly developed, including integration with EBU-R128 loudness normalization specified.

Congratulations to all involved including indeed all the corporate interests who have seen fit to ensure it is an open standard to prevent fragmentation and those such as Mozilla who have contributed employees to work on it.

Hopefully the Mandatory status in WebRTC and the IETF standardization and the number of organisations behind Opus will encourage a wide range of others to implement it as a well-backed standard and very much an open door to numerous use-cases, which need implementing only once for them all.
Dynamic – the artist formerly known as DickD

  • jensend
  • [*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #9
Is storage in the Ogg container format intended to be the go-forward standard for encoding of local files with the Opus codec?
Well, you could ask Monty about TransOgg

Fire up the cloning vats!
  • Last Edit: 11 September, 2012, 11:43:02 PM by jensend

  • hlloyge
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #10
Well, it would be nice if Apple adopts it for iTunes and mobile players, but I have some doubts about that...

  • mamboman
  • [*]
Opus is now RFC6716, version 1.0.1 released!
Reply #11
Congratulations to the developers - Opus is a real credit to them.

I've just got a question about Opus and low latency applications.

Pardon my ignorance, but I had always been led to believe that in order to be able to use software at low latencies that it was necessary for your operating system to be running a low latency kernel.

I have experimented with audio a fair bit on Linux and what musicians tend to do is to replace the Linux kernel that comes by default with their distribution with a low latency one.

They then tend to install the Jack audio server, which is designed for low latency work.

They also tend to use a dedicated soundcard.

My question is - it is great that Opus offers low latency, but will most users be able to benefit from this functionality if their operating system does not have a low latency kernel?

Also, given the benefits that a low latency kernel can offer why is the standard Linux kernel shipped by major distributions not low latency by default?

Are there any downsides to having a low latency kernel?

Is low latency not enabled by default because the integrated sound modules of a lot of motherboards are not powerful enough to run at low latency?
Do you tend to need a dedicated soundcard to do low latency recording?
I noticed that when recording using Jack at low latency with my motherboard sound I kept getting X runs, but once I started using a dedicated soundcard this problem vanished, so it was as if the integrated sound module was struggling to cope at low latency and the more powerful dedicated card was necessary for such work.

If this is the case could the usefulness of opus as low latency software be hampered somewhat by the kernels that many folks use being compiled without low latency enabled?
Similarly could the usefulness of opus as low latency software be hampered by hardware shortcomings?  Dedicated soundcards are very much an item for the enthusiast - the average computer user will rely upon less powerful integrated sound.

If I was to jam with a friend over the internet what prerequisites would we both need?
Fast internet connection?
Low latency kernels?
Dedicated soundcards?

Sorry if I am coming across as a bit negative - just trying to get my head around this low latency stuff as it is confusing me a bit.

I have transcoded my flac files to opus at the default bitrate of 96kbps and am astounded by the quality.

Thank you again to Opus devs for this tremendous piece of software.

  • bandpass
  • [*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #12
My question is - it is great that Opus offers low latency, but will most users be able to benefit from this functionality if their operating system does not have a low latency kernel?

Yes, because latencies add, reducing latency in any component reduces overall latency.

  • iwod
  • [*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #13
Is storage in the Ogg container format intended to be the go-forward standard for encoding of local files with the Opus codec?


From the link through from the Opus homepage to the Ogg-Opus page, it appears so, and it's quite highly developed, including integration with EBU-R128 loudness normalization specified.

Congratulations to all involved including indeed all the corporate interests who have seen fit to ensure it is an open standard to prevent fragmentation and those such as Mozilla who have contributed employees to work on it.

Hopefully the Mandatory status in WebRTC and the IETF standardization and the number of organisations behind Opus will encourage a wide range of others to implement it as a well-backed standard and very much an open door to numerous use-cases, which need implementing only once for them all.


Ogg and not Matroska ( WebM )?

Opus is now RFC6716, version 1.0.1 released!
Reply #14
The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.

1.0.1 isn't the latest. If You want the latest then  try an experimental branch.

No. When you say latest you mean latest stable.


+1. Where could we get win32 (or win64 if it exists) compile of Opus Encoder 1.0.1 stable?

  • Dynamic
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #15
Ogg and not Matroska ( WebM )?


Opus in Matroska is also being worked on within Xiph.org, but isn't ready today, from what I've read. I suspect that .opus files (i.e. opus in ogg container) will be the typical form of file-based Opus audio-only playback, just as .ogg is the typical form of file-based Vorbis audio-only playback.
Dynamic – the artist formerly known as DickD

  • Dynamic
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #16
+1. Where could we get win32 (or win64 if it exists) compile of Opus Encoder 1.0.1 stable?


The version of 0.1.5 for the opus-tools bundle might be misleading a few people.

It includes an encoder which reports version libopus 1.0.1-rc3 library, which being a release candidate should be pretty stable.

Code: [Select]
C:\Users\Me>opusenc -V
opusenc opus-tools 0.1.5 (using libopus 1.0.1-rc3)
Copyright (C) 2008-2012 Xiph.Org Foundation


Essentially, little changed except removal of the -voice and -music modes which weren't useful and other things that simply made building the binary easier, AFAICT.

Recent versions including the free reference implementation have all been tuned to a very good performance, though moderate improvements on music and probably problem sample performance will doubtless be made over time. The days of naive reference encoders (like early mp3 encoders) seem to have passed.

Dynamic – the artist formerly known as DickD

  • CoRoNe
  • [*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #17
If I understand correctly, these are the problems they're still facing with Matroska.
DC-Bass Source Mod: http://reino.degeelebosch.nl

  • 2012
  • [*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #18
If I understand correctly, these are the problems they're still facing with Matroska.


This thread could be also of interest. IIUC, Limitations in the Matroska container itself is what blocked Opus support.
saldl: A lightweight well-featured CLI downloader optimized for speed and early preview.
https://saldl.github.io

  • Speckmade
  • [*]
Opus is now RFC6716, version 1.0.1 released!
Reply #19
I guess this is the time and place for the big "Thank You!". –
I'm particularly grateful for everyone involved in pushing Opus through the standardisation process.
I hope it is now going to be as successful as it deserves. – To world domination! ;-)

Lets hope that projects like Daala can reach something similar in the future.

  • eahm
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #20
I just noticed, the homepage of Opus says "Bit-rates from 6 kb/s to 510 kb/s", shouldn't it be 6 - 512?
  • Last Edit: 12 September, 2012, 10:35:27 PM by eahm

  • m45t3r
  • [*]
Opus is now RFC6716, version 1.0.1 released!
Reply #21
I just noticed, the homepage of Opus says "Bit-rates from 6 kb/s to 510 kb/s", shouldn't it be 6 - 512?

Nope, it's really 510Kbps, thanks to how Opus represent the frame length. You can read more on here.

  • eahm
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #22
I just noticed, the homepage of Opus says "Bit-rates from 6 kb/s to 510 kb/s", shouldn't it be 6 - 512?

Nope, it's really 510Kbps, thanks to how Opus represent the frame length. You can read more on here.

Thank you, so then everyone else must fix this, starting from Mozilla https://hacks.mozilla.org/2012/09/its-opus-...codec-standard/. Come on, partner and supporter.

  • viktor
  • [*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #23
Those who'd like to see Opus being supported on Windows Phone, please vote for it!

  • Dynamic
  • [*][*][*][*][*]
Opus is now RFC6716, version 1.0.1 released!
Reply #24
If I understand correctly, these are the problems they're still facing with Matroska.


From that link:
Quote from: MastroskaOpus wiki link=msg=0 date=
Seeking in Opus files requires a pre-roll (recommended to be at least 80 ms). However, currently Matroska requires its index entries to point directly to the data whose timestamp matches the corresponding seek point, not some place arbitrarily before that timestamp. These two requirements are incompatible, and mean that seeking in Opus will be broken in all existing Matroska software. In particularly unlucky cases (e.g., around a transient), playing back audio decoded without any pre-roll can produce extremely loud (possibly equipment-damaging) results. We need a new element to signal this, e.g. Track::TrackEntry::PreRoll.


I believe the pre-roll is essential because of the SILK layer's predictors needing time to converge based on previous samples, but wouldn't matter in CELT-only (MDCT only) mode. Without this, excessive volume bursts may occur if SILK is active, so the BEST solution is a PreRoll (decoding but not playing 80 ms of audio or more to make it converge). Presumably if the PreRoll isn't accessible it should be acceptable (and mandatory) to mute the audio for 80ms (or follow a suitable fade-in curve).
Dynamic – the artist formerly known as DickD