OpusFAQ - Revision history

Rillian: /* How do I report a bug? */

2026-01-04T13:32:52Z

How do I report a bug?

← Older revision		Revision as of 13:32, 4 January 2026
Line 177:		Line 177:
	=== How do I report a bug? ===		=== How do I report a bug? ===

	If you think you have found a bug in Opus (and not in your application), please [https://~~trac~~.xiph.org/~~newticket?component=Opus~~ file ~~a bug report~~].		If you think you have found a bug in Opus (and not in your application), please [https://gitlab.xiph.org/xiph/opus/-/issues file an issue].

	Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur.		Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur.
Line 183:		Line 183:
	If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc.		If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc.

	Don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.~~freenode~~.~~net~~/opus IRC].		Don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.libera.chat/opus IRC].

	=== What is Opus Custom? ===		=== What is Opus Custom? ===

VADemon: Fix 4 broken links via IA-WBM

2020-10-03T17:57:30Z

Fix 4 broken links via IA-WBM

Phschafft: Updated links from old git.xiph.org to gitlab

2020-08-12T16:36:43Z

Updated links from old git.xiph.org to gitlab

← Older revision		Revision as of 16:36, 12 August 2020
Line 131:		Line 131:
	Opus is not a large project with a fixed release schedule.		Opus is not a large project with a fixed release schedule.

	That being said, our '''[https://www.opus-codec.org/downloads/ pre-releases]''' and even the git repositories ('''[https://~~git~~.xiph.org/~~?p=~~opus~~.git~~ Xiph]''', '''[https://github.com/xiph/opus GitHub]''') are pretty stable and given proper testing (which you should always do anyway), are safe to distribute.		That being said, our '''[https://www.opus-codec.org/downloads/ pre-releases]''' and even the git repositories ('''[https://gitlab.xiph.org/xiph/opus/-/tree/master Xiph]''', '''[https://github.com/xiph/opus GitHub]''') are pretty stable and given proper testing (which you should always do anyway), are safe to distribute.

	Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.		Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.
Line 171:		Line 171:
	* Implement your application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.		* Implement your application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.
	* Read the [https://www.opus-codec.org/docs/ Opus documentation].		* Read the [https://www.opus-codec.org/docs/ Opus documentation].
	* Read the [https://~~git~~.xiph.org/~~?p=~~opus~~.git;a=~~blob~~;f=~~src/opus_demo.c opus_demo.c] source code to see how to use the encoder and decoder.		* Read the [https://gitlab.xiph.org/xiph/opus/-/blob/master/src/opus_demo.c opus_demo.c] source code to see how to use the encoder and decoder.

	If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on the '''#opus''' IRC channel on '''irc.freenode.net'''.		If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on the '''#opus''' IRC channel on '''irc.freenode.net'''.

EPirat: Fix WebRTC AEC link

2018-01-12T15:17:30Z

Fix WebRTC AEC link

← Older revision		Revision as of 15:17, 12 January 2018
Line 293:		Line 293:
	You can use any echo canceller (including the one from libspeexdsp) along with Opus.		You can use any echo canceller (including the one from libspeexdsp) along with Opus.

	That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://~~code~~.~~google~~.com/p/webrtc/ WebRTC codebase].		That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_processing/ WebRTC codebase].

	=== How do I get the duration of a .opus file? ===		=== How do I get the duration of a .opus file? ===

MrZeus: /* Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? */

2017-11-07T17:03:55Z

Does Opus support higher sampling rates, such as 96 kHz or 192 kHz?

← Older revision		Revision as of 17:03, 7 November 2017
Line 65:		Line 65:
	See Monty's '''[https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.		See Monty's '''[https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.

	If you want a codec to handle ~~higher~~ sampling rates losslessly, use '''[[FLAC]]'''!		If you want a codec to handle high sampling rates losslessly, use '''[[FLAC]]'''!

	=== What are the licensing requirements? ===		=== What are the licensing requirements? ===

MrZeus: /* What programs support Opus? */ add context to "relatively new codec"

2017-11-07T16:40:23Z

What programs support Opus?: add context to "relatively new codec"

← Older revision		Revision as of 16:40, 7 November 2017
Line 51:		Line 51:
	For real-time applications, Opus support is available in '''[https://www.webrtc.org/ Google's WebRTC codebase]'''.		For real-time applications, Opus support is available in '''[https://www.webrtc.org/ Google's WebRTC codebase]'''.

	Opus is a relatively new codec: '''[[OpusSupport\|many more applications]]''' will support it in the near future.		Opus is a relatively new codec (standardized in September 2012), but '''[[OpusSupport\|many more applications]]''' will support it in the near future.

	=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===		=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===

Derf: /* Wouldn't it be better to build an index? */

2017-07-07T20:46:56Z

Wouldn't it be better to build an index?

← Older revision		Revision as of 20:46, 7 July 2017
Line 336:		Line 336:
	=== Wouldn't it be better to build an index? ===		=== Wouldn't it be better to build an index? ===

	As with file durations, an index at the beginning of the file is incompatible with live streaming. It also means more data has to be fetched before a file can start playing over the network, because you must read past the index even when you don't intend to seek. The index could be stored at the end (which even still allows encoding the file in a single pass), but this requires one (or more) extra seeks to read the index (especially if its exact location at the end is not known), either on file open or on first seek. Unlike the final timestamp, which is small and fixed in size, an index grows with the file duration, and can have unbounded size. It is also easy for an index to become out of sync with a file that has been edited or damaged, in which case seeking will simply fail. In contrast, you can seek in a truncated .opus download without issues.		As with file durations, an index at the beginning of the file is incompatible with live streaming. It also means more data has to be fetched before a file can start playing over the network, because you must read past the index even when you don't intend to seek. The index could be stored at the end (which even still allows encoding the file in a single pass), but this requires one (or more) extra seeks to read the index (especially if its exact location at the end is not known), either on file open or on first seek. Unlike the final timestamp, which is small and fixed in size, an index grows with the file duration, and can have unbounded size. It is also easy for an index to become out of sync with a file that has been edited or damaged, in which case seeking will simply fail. By contrast, you can seek in a truncated .opus download without issues.

	In practice, bisection seeking on VBR audio achieves performance that is very nearly as good as seeking with an index, without any of the drawbacks of an index. libopusfile provides a test program called seeking_example which can be used to benchmark the performance on your files.		In practice, bisection seeking on VBR audio achieves performance that is very nearly as good as seeking with an index, without any of the drawbacks of an index. libopusfile provides a test program called seeking_example which can be used to benchmark the performance on your files.

Derf: /* How do I seek in a .opus file? */

2017-07-07T20:45:39Z

How do I seek in a .opus file?

← Older revision		Revision as of 20:45, 7 July 2017
Line 332:		Line 332:
	libopusfile also takes shortcuts when the target location is near the current position, to make small seeks cheaper. In the best case it can loop forever over very short files whose data is contained in a single page (e.g., less than 1 second long with default encoder settings) without any seeking at all.		libopusfile also takes shortcuts when the target location is near the current position, to make small seeks cheaper. In the best case it can loop forever over very short files whose data is contained in a single page (e.g., less than 1 second long with default encoder settings) without any seeking at all.

	You can find more information on seeking in ~~multiplexed~~ files ~~when you want to play more than just a single~~ Opus ~~stream~~ '''[[GranulePosAndSeeking\|on this page]]'''.		You can find more information on seeking in files that contain Opus multiplexed with other streams (e.g., video) '''[[GranulePosAndSeeking\|on this page]]'''.

	=== Wouldn't it be better to build an index? ===		=== Wouldn't it be better to build an index? ===

Derf: /* How do I seek in a .opus file? */

2017-07-07T20:43:34Z

How do I seek in a .opus file?

← Older revision		Revision as of 20:43, 7 July 2017
Line 325:		Line 325:
	* Seek to that location and scan forward until you find an audio data page with a completed packet (that contains a valid granule position).		* Seek to that location and scan forward until you find an audio data page with a completed packet (that contains a valid granule position).
	* If you think you are sufficiently close to the adjusted target, scan forward until you find the next audio data page with a completed packet.		* If you think you are sufficiently close to the adjusted target, scan forward until you find the next audio data page with a completed packet.
	* If the adjusted target lies between the first audio data page with a completed packet you found and the next one, stop. You can decode forward from here and start playing when you reach your (original unadjusted) target.		* If the adjusted target lies between the first audio data page with a completed packet you found and the next one, stop. You can decode forward from here and start playing when you reach your (original, unadjusted) target.
	* Otherwise, go back and re-estimate the seek location using the granule positions and file offsets of the page(s) you just found.		* Otherwise, go back and re-estimate the seek location using the granule positions and file offsets of the page(s) you just found.

Derf: /* How do I seek in a .opus file? */

2017-07-07T20:42:38Z

How do I seek in a .opus file?

← Older revision		Revision as of 20:42, 7 July 2017
Line 321:		Line 321:
	If you want to implement seeking yourself, you need to		If you want to implement seeking yourself, you need to
	* Identify the link that contains the target (if you have a chained file).		* Identify the link that contains the target (if you have a chained file).
	* Adjust the target by 80 ms to ~~ensure you will~~ get enough pre-roll data (to ensure the decoder will have converged by the time you reach the target), as recommended by '''[https://tools.ietf.org/html/rfc7845 RFC 7845]'''.		* Adjust the target by 80 ms to get enough pre-roll data (to ensure the decoder will have converged by the time you reach the target), as recommended by '''[https://tools.ietf.org/html/rfc7845 RFC 7845]'''.
	* Estimate the location of the last audio data page with a completed packet prior to the adjusted target, using the duration and size (in bytes) of the link.		* Estimate the location of the last audio data page with a completed packet prior to the adjusted target, using the duration and size (in bytes) of the link.
	* Seek to that location and scan forward until you find an audio data page with a completed packet (that contains a valid granule position).		* Seek to that location and scan forward until you find an audio data page with a completed packet (that contains a valid granule position).

← Older revision		Revision as of 17:57, 3 October 2020
Line 63:		Line 63:
	The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.		The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.

	See Monty's '''[https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.		See Monty's '''[https://web.archive.org/web/20200426050432/https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.

	If you want a codec to handle high sampling rates losslessly, use '''[[FLAC]]'''!		If you want a codec to handle high sampling rates losslessly, use '''[[FLAC]]'''!
Line 105:		Line 105:
	Although it is unlikely that Opus encoders will see such a spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder.		Although it is unlikely that Opus encoders will see such a spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder.

	In fact, the 1.1 libopus release significantly improves on the reference encoder's quality. See '''[https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml Monty's demo]''' for more details.		In fact, the 1.1 libopus release significantly improves on the reference encoder's quality. See '''[https://web.archive.org/web/20190814051043/https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml Monty's demo]''' for more details.

	=== Will all future Opus releases comply with the [https://tools.ietf.org/html/rfc6716 Opus specification]? ===		=== Will all future Opus releases comply with the [https://tools.ietf.org/html/rfc6716 Opus specification]? ===
Line 141:		Line 141:
	The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.		The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.

	Some of the platforms ~~'''~~[https://mf4.xiph.org/jenkins/view/opus/ ~~on which Opus has been tested~~]''' include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.		Some of the platforms on which Opus has been tested<ref name="mf4-tests">Automated test results used to be available [https://mf4.xiph.org/jenkins/view/opus/ here] ([https://web.archive.org/web/20160316111354/https://mf4.xiph.org/jenkins/view/opus/ last saved copy]). The [https://gitlab.xiph.org/xiph/opus/-/tree/master new git repository] doesn't have any links to test results, but you can always run the tests yourself!</ref> include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.

	=== Is there a fixed-point implementation? ===		=== Is there a fixed-point implementation? ===
Line 255:		Line 255:
	=== How can I ensure that my software interoperates with other software implementing Opus? ===		=== How can I ensure that my software interoperates with other software implementing Opus? ===

	For applications using Ogg files, there are some [https://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful.		For applications using Ogg files, there are some [https://web.archive.org/web/20191223064407/https://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful.

	In general, here's a list of specific issues to check:		In general, here's a list of specific issues to check:
Line 352:		Line 352:

	That is, the number of physical seeks required is almost always 1, every once in a while 2, and in short files, sometimes even 0.		That is, the number of physical seeks required is almost always 1, every once in a while 2, and in short files, sometimes even 0.

			==References==

	[[Category:Opus]]		[[Category:Opus]]