New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 139 users

Issue metadata

Status: Fixed
Closed: Dec 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocked on:
issue 168524
issue 178302
issue 178309

issue 315165

Sign in to add a comment

Support OPUS in Ogg files for the audio tag and Audio object

Reported by, Nov 15 2011

Issue description

Chrome Version       : 17.0.932.0

Opus seems to be the successor to Speex, with more clear patent policy and development path.

Chrome currently supports Speex and FLAC but does not yet support OPUS for the <audio> tag.
Labels: Feature-Media
Putting this into our plate. Current codec supported by Chrome be found in

Status: WontFix
We can have a bug open for supporting any random codec but that doesn't create useful bugs and help us as developers. I'd rather file bugs for work that is actionable -- as it stands today I'm not aware of any plans to add OPUS for <audio>.

Comment 3 by, Nov 17 2011

Re: WontFix -- I could do without the derisive attitude. If you're interested in the topic, there's room for positive discussion.

Comment 4 Deleted

Comment 5 by Deleted ...@, Jan 3 2012

Opus is not some "random codec" and should be taken seriously considering that it may be the future of not only VoIP, but low latency audio codecs. Much better than Speex. Heck, I have also seen comparisons between this and MP3/Vorbis/AAC with Opus coming up top on various bitrates.

Opus will hopefully be an IETF standard soon and will be a heavily desired codec. Time to start planning now. If you want, the source code can be obtained from GIT here:
Other chromium developers were supportive of this; Xiph has expressed a preference for Opus over Speex/Vorbis focus, WebRTC and other vendors are working toward Opus. It's not random, but it is some work and not quite through the standards process. I expect we'll see quick movement on this in the future.
Labels: -Area-Undefined Area-WebKit FuturePlan

Comment 8 Deleted

Comment 9 by, Jul 21 2012

Actually, it is not patent free, but royalty-free usage rights are granted under conditions that the authors believe are compatible with most, or possibly all, open source licenses:
Ooops, "Delete comment" doesn't ask back if i was sure.

Sorry, my mistake, i meant royalty-free.
Fixed original comment: "OPUS is a very good codec and is royalty free so it would be a great addition to HTML5 <audio>. Firefox already has it in version 15. Please include it in Chrome."

Comment 11 by, Sep 3 2012

Now that Opus has gained multi-vendor support and is already shipping in Firefox, could we please change the status from "WontFix"?

Comment 12 by, Sep 3 2012

Also, the OS should be "All" and not just "Mac". Thanks.
I asked some developers: they were willing to accept Opus support, it's just not a priority.

Comment 14 by, Sep 4 2012

Even if it's not a top priority, the status should be updated from "WontFix" so that the wider developer community can push ahead with Opus support...
Opus is now an IETF standard ( and there is "strong concensus" for it as an MTI codec for WebRTC. The "Won't fix" status should really be removed, especially if all that keeps Opus from being added is it being low priority.
Consider it an item that ought to be put into the bug sheet. It's an "upstream" issue.
 Issue 148599  has been merged into this issue.
Labels: -OS-Mac -Pri-2 -Type-Bug -FuturePlan OS-All Pri-3 Type-Feature
Status: Available
Moving back into the general pool of bugs. My intention wasn't to offend -- lots of requests arrive via the bug tracker and keeping them all in the Available state is untenable. The good news is status labels are malleable :)

downchuck: for Chromium this is the proper place to file the bug. For other WebKit-based browsers (Safari, Blackberry, Gtk, Qt, etc...) you may want to file a bug.
Labels: Feature-WebRTC

Comment 20 by, Oct 2 2012

Oddly enough Chromium reports "Maybe" to the codec, but it doesn't work. Is support partially in? If not, why does the browser report "maybe"?

Comment 21 by, Oct 25 2012

I suspect the "Maybe" is due to the fact that the mimetype should still be "audio/ogg" (".opus" files are Opus audio in an ogg container). The browser won't know if it can actually play back the "audio/ogg" file until it looks to see what codec (or codecs) is/are actually contained therein.

I've got an HTML5 audio-format test page at - for me Chromium 22.0.1229.94 (x86_64 Linux) reports "Maybe" (I have the page describing that as "It should, but it might not") for 'audio/ogg; codecs="opus"', but only plays the Ogg Vorbis audio.  (Chromium also reports "Maybe" for audio/webm as well, apparently.)

(I don't have the necessary programming skills to actually offer patches to add opus support to chromium/chrome, but I'd be happy to help test and troubleshoot if it'll help, I'd love to see opus in <audio> work for other browsers in addition to Mozilla Firefox and Opera-on-Linux...)

Comment 22 Deleted

Just to be clear on the Royalty Free comment ... At least two companies, Huawei and Qualcomm, claim they have IPR on this that as far as I know they are not offering it royalty free. They have cited patents/applications 7,519,535; 5,579,433; 5,414,796; 5,657,420; 5,341,456; 5,742,734, and US11942118. You can find more details about IPR claimed on opus at 

Also, it is now a standard RFC6716. 

Opus is now required by WebRTC and the official WebRTC demo for Chrome scans for it, but Chrome still doesn't seem to support it.

What does "Status: Available" mean in the context of this bug report?

Comment 26 by Deleted ...@, Dec 5 2012

Please add support for this codec both as an .ogg file and as an .opus file for Windows, Mac, and Linux. As stated above, there are inklings of WebRTC support in the Chromium code, but the codec is still missing. What is holding it back from being included? Firefox 15 and above has it and it works perfectly for static and streaming files.
According to Opus is supposed to be added in Chrome 24. However, according to this functionality won't work outside of WebRTC (e.g. <audio> tags).

Can someone in Google please confirm Opus really is coming in Chrome 24?
My Chrome 23 on Arch Linux plays all Opus files perfectly:
Is this because the webbrowser supports it? Or because of libopus is installed and it uses that backend?

Comment 29 by, Dec 18 2012

The three players at the top play .wav files (Opus transcoded to .wav). Only the players below play opus directly; abnd those are grayed out here.
OPUS support has been added to Chromium, tagged with Milestone 25:

Comment 31 by, Dec 19 2012

Perhaps a clarification/rename of  issue #104241  might be relevant: "Support Opus in Ogg files for the <audio> tag and Audio object".

The link in comment #30 appears to only be for (non-standard?) WebM containers.

(There was a lot of talk that WebM would remain one video codec and one audio codec to make implementation simpler some time back, so not sure if this is to be a "new" WebM standard or what.)

Current Opus files supported in Firefox, VLC, Rockbox, etc. are packaged in Ogg containers. Hopefully the "initial version" mentioned in the comment #30 link means standard Opus-in-Ogg (".opus") file support is pending.
I've added Opus to the 'videotestmatrix'.  e.g.

Plays okay in Firefox
Chrome M24 (beta) or M26 (canary) fail by default.  It requires a switch:

M24 (beta) does not support Opus.
M25 (dev) does, with --enable-opus-playback
M26 (canary) does, with --enable-opus-playback

Google Chrome	25.0.1364.5 (Official Build 174090) dev-m
Someone will need to make a change to switch it on by default, with a flag to disable it instead.

Its so far only functional in ogg container.

The .opus extension is not supported:
url needs to end in .ogg, .oga, or .ogv

The decoder is not optimized.  Its best to use 48000 Hz.

Comment 34 by, Jan 7 2013

What is meant by "the decoder is not optimized"? What happens at sample rates other than 48 kHz?

Re #34
The decoder takes more CPU than other audio codecs in Chrome (aac, vorbis, mp3, wav).
One thing you can do, is ensure your audio is 48000 Hz.  At 44100 or 32000, it'll resample to 48000, which hurts performance alot and quality a little.

The .opus extension needs an apache server update to say its an audio mimetype.
But even doing that, its 'saving' the file for both Chrome and Firefox on my Windows machine?
Attached is an opus audio only sample that should work if you do the flag.

4.5 MB Download

Comment 36 by, Jan 7 2013

Thank you, good to know.

What is the status of PLC with the current implementation?  As noted in the RFC:

I suspect many WebRTC apps (for example) will be voice/video conferencing (i.e. "SILK mode" in OPUS).  For quality/bandwidth/packet loss optimization SILK needs access to received frames in the jitter buffer for LPC extrapolation.  Ideally this packet loss percentage is then passed back into the encoder to optimize packet size (per packet FEC).

Has anyone looked at this in Chromium? Thanks again!

In webkit, the source for opus has landed in the chromium dependencies tree.
WebRTC and webkit are fairly different than <audio> tag.  Audio and video go thru ffmpeg, which has its own copy of Opus.  This bug is for <audio> tag.
Silk should work fine for <audio>, but we're usually aiming at high bit rate, and Celt will be used for voice at high bitrate.

I'd like to weave Opus into webm for webma audio files, and vp9 videos.  But we'll need updated webm support in mkvtoolnix and/or ffmpeg.

Comment 39 by, Jan 8 2013

Thank you for the clarification. I will find out where to present my question for WebRTC.

Thanks again!

Comment 40 by, Jan 20 2013

Slightly off-topic, but not sure where else to ask:

Is there a way for the encoding side of Opus to be used via WebAudio (or indirectly via WebRTC) ? 

For example, if an audio sample is recorded from the user's microphone, what is the pathway to encode that to Opus before sending to a server for storage/saving (such as an audio memo app, or an audio workstation app)?

I've been scouring the net for javascript implementations of audio encoders, but nothing looks all that compelling (a narrowband Speex encoder seems to be the most developed thing out there, but not very practical).

There are javascript implementations of FFT and MDCT, so theoretically it seems possible to do it all in pure Javascript. Of course, integrating with a lower-level API would likely produce huge performance advantages if possible.



Comment 41 by Deleted ...@, Feb 4 2013

I may be incorrect here, but the opus site states that the files should be .opus, without the .ogg .oga extension (although they are ogg containers), firefox plays files like that but it appears that chrome/chromium do not.
I'm told .ogg, .oga, and ogg video types are also allowed.  But .opus should work.

Opened a bug for mimetype

Comment 43 by Deleted ...@, Feb 9 2013

Help needed! how much overall latency will webrtc and opus incur together? to keep latencies minimum, is it better to go for webrtc or have a local app that communicates directly with the web app???
Jahanzeb, Andreas, and everybody else who may come along later: this bug is only for getting Opus HTML5 <audio> support, turned on by default, into Chromium/Chrome. This isn't the place to ask general questions about Opus, and this bug has no direct relation to WebRTC/RTCWeb.

Use discuss-webrtc for WebRTC questions. Use the Opus IRC channel or mailing list for Opus questions. People at those locations will be better able to help, and it will improve the SNR of this bug report.
Labels: -Pri-3 -Feature-WebRTC Pri-2 Feature-Media-Audio
Re #41 fixed in canary.

Comment 46 by Deleted ...@, Mar 4 2013

When Opus is enabled by default for <audio> and <video> in Chrome 26, make sure the browser reports as "probably" when checking the canPlayType for the codec.
Labels: webrtc-feedback
Labels: -webrtc-feedback
Project Member

Comment 49 by, Mar 10 2013

Labels: -Area-WebKit -Feature-Media -Feature-Media-Audio Cr-Content Cr-Internals-Media Cr-Internals-Media-Audio
Blockedon: chromium:168524 chromium:178302 chromium:178309 chromium:188852 chromium:188900
Project Member

Comment 51 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
@#46 -  Issue #188852  points out the "testing" issue on this.

Comment 53 by, Aug 16 2013

I've tried to test this with a Opus stream and it doesn't seem to work.

We don't pass a Content-Lenth since its infinite.  (Just click the play button on the last one in the list)  (Direct link)

Comment 54 by, Aug 17 2013

i use chromium (win 7 64bit) 28.0.1500.95 m and (xubuntu 12.04 LTS 64bit) 28.0.1500.95-0ubuntu1, both does not work, please fix!

Comment 55 by Deleted ...@, Aug 31 2013

still dragging butt on the ubuntu side - no opus on current lts.  so i crank up firefox to play opus music.

Comment 56 Deleted

Comment 57 by Deleted ...@, Sep 8 2013

I'm tried today with my Chrome Version 29.0.1547.65 and my chromium Version 28.0.1500.71, and not works in both. I'm on "Linux 3.8.0-29-generic #42-Ubuntu SMP Tue Aug 13 23:12:18 UTC 2013 i686 i686 i686 GNU/Linux".

On my firefox 23 works.
Blocking: chromium:315165
Summary: Support OPUS in Ogg files for the audio tag and Audio object (was: Support OPUS for the audio tag and Audio object)
Project Member

Comment 60 by, Nov 25 2013

r237124 | | 2013-11-25T19:36:51.364245Z

Changed paths:

media: Adding test file for Opus in Ogg

Adding a test file for Opus in ogg container. Also removing an
unused test file.

BUG= 104241 , 178309 , 315165

Review URL:

Patch from vignesh <>.
Project Member

Comment 61 by, Dec 12 2013

r240320 | | 2013-12-12T14:20:02.105719Z

Changed paths:

FFmpeg fixups for M33 roll. Now with more Opus!

Besides the DEPs update there's also:
- Remove deprecated usage of avcodec_alloc_frame()
- Remove deprecated usage of pkt->pkt_pts
- Fix end trimming for ogg opus playbacks.
- Remove fragile bytes decoded check for end trimming.

Not all of the Opus issues are fixed yet, this just
pulls in the FFmpeg side of the fixes.  Chrome changes
are in a followup patch set.

BUG= 104241 , 166752 , 168524 , 315165 
TEST=unittests, asan, ogg opus links from bugs.

Review URL:
Project Member

Comment 62 by, Dec 13 2013

r240775 | | 2013-12-13T22:24:21.527965Z

Changed paths:

Cleanup OPUS decoder.  Remove extraneous transforms and copies.

Various cleanups:
- Fixes start trimming after seeks.
- Patches FFmpegDemuxer to workaround FFmpeg pre-stripping codec delay.
- Switches decoding to float on all platforms.
- Decodes directly into the AudioBuffer instead of making a copy.
- Switches various error logs to actually be DLOG(ERROR).
- Various tiny code cleanups.
- Rolls DEPS for a couple more OPUS FFmpeg fixes.

BUG= 104241 ,  166752 ,  168524 ,  315165 ,  328207 
TEST=opus decoding still works.

Review URL:
Labels: M-33
Aside from some canPlayType wonkiness and missing support for header gain.  Opus in ogg should work fine in M33.  If anyone has issues w/ the latest canary builds, let me know.
And... opus header gain should be fixed in tomorrow's canary.
Project Member

Comment 67 by, Dec 17 2013

Labels: -M-33 MovedFrom-33 M-34
Status: Assigned
Moving all non essential bugs to the next Milestone.
Blockedon: -chromium:188852 -chromium:188900
Labels: -MovedFrom-33 -M-34 M-33
Status: Fixed
 Issue 188852  and  188900  shouldn't block this bug.  Closing as fixed.
Tested latest Canary; Opus finally plays back by default and seeking, header gain, and trim all work just fine. Seems to have some trouble with audio briefly dropping under network or cpu load in situations that don't bother Firefox, but that's another story.

Dale Curtis, I think I speak for all of us who starred this bug and all those interested in quality open media when I say: many, many thanks for fixing this longstanding issue and removing one of the major roadblocks to web deployment of the world's best codec.

Comment 70 by, Feb 28 2014

hi, tested Canary build in win7 HP sp1 64bit and all .opus files tested random stop playing after about 25 seconds. Even the xrm.opus radio above stopped playing randomly in about 1 minute intervals.  

Version 35.0.1863.0 canary
1.7 MB Download
Opus Streams do not work on Android Chrome (Kit Kat).

Sign in to add a comment