XiphWiki - Recent changes [en]

User talk:PressRTbox

2012-05-16T11:46:20Z

deleted "[[User talk:PressRTbox]]" SPAM links: spamicide

User:StephenF

2012-05-15T12:12:00Z

New user account

User:Apradoc

2012-05-14T04:26:09Z

New user account

User:PressRTbox

2012-05-13T23:08:57Z

New user account

User:Swtorbots32

2012-05-13T05:09:22Z

New user account

TDLT

2012-05-12T22:00:08Z

← Older revision		Revision as of 22:00, 12 May 2012
(One intermediate revision not shown)
Line 42:		Line 42:
	Optimal real-valued coefficients for V:		Optimal real-valued coefficients for V:

-	p0 = -0.~~3625885819608689~~	+	p0 = -0.39460731547057293

-	p1 = -0.~~41911703104506826~~	+	p1 = -0.33002212811740816

-	p2 = -0.~~06962862896922385~~	+	p2 = -0.12391270981321137

-	q0 = 0.~~8423686986993569~~	+	q0 = 0.822154737511288

-	q1 = 0.~~6393969893363041~~	+	q1 = 0.632488694485779

-	q2 = 0.~~3894929113709107~~	+	q2 = 0.40214668677553894

-	CG = 9.~~52441~~	+	CG = 9.56867

	Optimal [maybe] integer-valued coefficients (d=6) for V:		Optimal [maybe] integer-valued coefficients (d=6) for V:

TDLT

2012-05-12T21:43:03Z

New page

This page holds the results of Time Domain Lapped Transform (TDLT) optimization problems looking for integer transform coefficients that provide optimal coding gain. Wherever possible the assumptions are stated. Later we should include testing against actual image data to verify the results (see test data [http://people.xiph.org/~tterribe/tmp/subset1-y4m.tar.gz here]).

The coding gain objective used as the objective is taken from slide 13 of Tim's presentation [http://people.xiph.org/~tterribe/pubs/lca2012/auckland/intro_to_video1.pdf An Introduction to Video Coding]

<need figure with block matrix diagrams>

The free parameters are initially just the coefficients p_0,...,p_m,q_0,...,q_m where m=(n/2)-1. We limit these to being dyadic rationals, e.g., x/2^d with d=6, between [-1,1].

Given p's and q's and assuming a linear ramp constrains the s's.

== 4x8 ==

s0 = 4*(1-q0)
s1 = 4*(1-p0*(1-q0))/3

Optimal real-valued coefficients for V:

p0 = -0.18117338915051454

q0 = 0.6331818230771687

CG = 8.60603

Optimal integer-valued coefficients (d=6) for V:

p0 = -12/64 = -0.1875

q0 = 41/64 = 0.640625

CG = 8.60486

Optimal integer-valued coefficients (d=6) were (1-p0*(1-q0)) is divisible by 3:

p0 = -13/64 = -0.203125

q0 = 41/64 = 0.640625

CG = 8.60446

== 8x16 ==

Optimal real-valued coefficients for V:

p0 = -0.3625885819608689

p1 = -0.41911703104506826

p2 = -0.06962862896922385

q0 = 0.8423686986993569

q1 = 0.6393969893363041

q2 = 0.3894929113709107

CG = 9.52441

Optimal [maybe] integer-valued coefficients (d=6) for V:

p0 = -26/64 = -0.40625

p1 = -22/64 = -0.34375

p2 = -8/64 = -0.125

q0 = 53/64 = 0.828125

q1 = 41/64 = 0.640625

q2 = 26/64 = 0.40625

9.56627

User:Unlord

2012-05-12T20:30:20Z

New user account

User:Tribeshack64

2012-05-12T08:55:48Z

New user account

OggOpus

2012-05-10T17:43:31Z

ID Header:

← Older revision		Revision as of 17:43, 10 May 2012
(One intermediate revision not shown)
Line 102:		Line 102:

	* '''Version'''		* '''Version'''
-	The version number ~~must~~ always be '1' for this version of the encapsulation specification. ~~This 8-bit field is partitioned into two sub-fields. The lower four bits constitute a "minor revision", while~~ the upper four bits ~~correspond to~~ a ~~"major revision". I.e~~., the ~~current~~ major ~~revision is '0',~~ and ~~the current~~ minor ~~revision is '1'. Implementations SHOULD treat streams~~ with ~~an unknown~~ minor ~~revision as backwards~~-~~compatible as long as they recognize~~ the ~~major revision~~. ~~When encountering~~ a stream with ~~an unknown major revision~~, ~~implementations~~ SHOULD assume it is ~~not backwards compatible~~. The initial version '1' was chosen to keep implementations from relying on this byte as a null terminator for the OpusHead string.	+	The version number MUST always be '1' for this version of the encapsulation specification.
		+
		+	Implementations SHOULD treat streams where the upper four bits of the version number match a recognized specification as backwards-compatible with that specification. That is, the version number can be considered split into "major" and "minor" version sub-fields, with changes to the "minor" sub-field in the lower four bits signaling compatible changes. For example, a decoder implementing this specification SHOULD accept any stream with a version number 15 or less, and SHOULD assume any stream with a version number 16 or greater is incompatible. The initial version '1' was chosen to keep implementations from relying on this byte as a null terminator for the OpusHead string.

	* '''Channel count''' 'c'		* '''Channel count''' 'c'

OggOpus

2012-05-10T17:29:36Z

Upgrade pre-skip recommendation for cropping to RFC 2119 strength.

← Older revision		Revision as of 17:29, 10 May 2012
(One intermediate revision not shown)
Line 21:		Line 21:
	The second Opus packet MUST contain the comment header. It must begin with the 8 bytes "OpusTags". It MAY span one or more pages, beginning on the second page of the logical stream. However many pages it spans, the comment header packet MUST finish the page on which it ends.		The second Opus packet MUST contain the comment header. It must begin with the 8 bytes "OpusTags". It MAY span one or more pages, beginning on the second page of the logical stream. However many pages it spans, the comment header packet MUST finish the page on which it ends.

-	All subsequent pages are audio data pages and the packets they contain are audio data packets. The first audio page SHOULD NOT have the 'continued packet' flag set (which would indicate the first packet is continued from a previous page). Packets MUST be placed into Ogg pages in order until the end of stream. Audio packets MAY span page boundaries. A decoder MUST treat a zero-byte audio packet as if it were an Opus packet with an illegal TOC sequence. The last page SHOULD have the 'end of stream' flag set, but implementations should be prepared to deal with truncated streams which do not have a page marked 'end of stream'. The final packet SHOULD complete on the last page, i.e., the final lacing value should be less than 255. There MUST NOT be any more pages in an Opus logical stream after a page marked 'end of stream'.	+	All subsequent pages are audio data pages and the packets they contain are audio data packets. The first audio page SHOULD NOT have the 'continued packet' flag set (which would indicate the first audio packet is continued from a previous page). Packets MUST be placed into Ogg pages in order until the end of stream. Audio packets MAY span page boundaries. A decoder MUST treat a zero-byte audio packet as if it were an Opus packet with an illegal TOC sequence. The last page SHOULD have the 'end of stream' flag set, but implementations should be prepared to deal with truncated streams which do not have a page marked 'end of stream'. The final packet SHOULD complete on the last page, i.e., the final lacing value should be less than 255. There MUST NOT be any more pages in an Opus logical stream after a page marked 'end of stream'.

	=== Granule Position ===		=== Granule Position ===
Line 102:		Line 102:

	* '''Version'''		* '''Version'''
-	The version number must always be '1' for this version of the encapsulation specification. This 8-bit field is partitioned into two sub-fields. The lower four bits constitute a "minor revision", while the upper four bits correspond to a "major revision". Implementations SHOULD treat streams with an unknown minor revision as backwards-compatible as long as they recognize the major revision. When encountering a stream with an unknown major revision, implementations SHOULD assume it is not backwards compatible. The initial version '1' was chosen to keep implementations from relying on this byte as a null terminator for the OpusHead string.	+	The version number must always be '1' for this version of the encapsulation specification. This 8-bit field is partitioned into two sub-fields. The lower four bits constitute a "minor revision", while the upper four bits correspond to a "major revision". I.e., the current major revision is '0', and the current minor revision is '1'. Implementations SHOULD treat streams with an unknown minor revision as backwards-compatible as long as they recognize the major revision. When encountering a stream with an unknown major revision, implementations SHOULD assume it is not backwards compatible. The initial version '1' was chosen to keep implementations from relying on this byte as a null terminator for the OpusHead string.

	* '''Channel count''' 'c'		* '''Channel count''' 'c'
Line 110:		Line 110:
	This is the number of samples (at 48 kHz) to discard from the decoder output when starting playback, and also the number to subtract from a page's granule position to calculate its PCM sample position.		This is the number of samples (at 48 kHz) to discard from the decoder output when starting playback, and also the number to subtract from a page's granule position to calculate its PCM sample position.

-	When constructing cropped Ogg Opus streams, ~~we recommend~~ a pre-skip of at least 3840 samples (80 ms) to ensure complete convergence.	+	When constructing cropped Ogg Opus streams, a pre-skip of at least 3840 samples (80 ms) is RECOMMENDED to ensure complete convergence.

	* '''Input sample rate'''		* '''Input sample rate'''

OggOpus

2012-05-10T17:19:28Z

ID Header: Update the header figure and brief description for the version bump

← Older revision		Revision as of 17:19, 10 May 2012
(One intermediate revision not shown)
Line 64:		Line 64:
	\| 'H' \| 'e' \| 'a' \| 'd' \|		\| 'H' \| 'e' \| 'a' \| 'd' \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-	\| version = 0 \| channel count \| pre-skip \|	+	\| version = 1 \| channel count \| pre-skip \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| original input sample rate in Hz \|		\| original input sample rate in Hz \|
Line 75:		Line 75:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		+	Brief description of each field:

	- Magic signature: "OpusHead" (64 bits)		- Magic signature: "OpusHead" (64 bits)
-	- Version number (8 bits unsigned): ~~zero~~ for this spec	+	- Version number (8 bits unsigned): 0x01 for this spec
	- Channel count 'c' (8 bits unsigned): MUST be > 0		- Channel count 'c' (8 bits unsigned): MUST be > 0
	- Pre-skip (16 bits unsigned, little endian)		- Pre-skip (16 bits unsigned, little endian)
Line 95:		Line 96:


-	~~Some discussion is in order.~~	+	Detailed definition of each field:

	* '''Magic signature'''		* '''Magic signature'''

OggOpus

2012-05-10T17:15:21Z

← Older revision		Revision as of 17:15, 10 May 2012
Line 204:		Line 204:
	When seeking within an Ogg Opus stream, the decoder should start decoding (and discarding the output) at least 3840 samples (80 ms) prior to the seek point in order to ensure that the output audio is correct at the seek point.		When seeking within an Ogg Opus stream, the decoder should start decoding (and discarding the output) at least 3840 samples (80 ms) prior to the seek point in order to ensure that the output audio is correct at the seek point.

-	Technically valid Opus packets can be arbitrarily large due to the padding format, although the amount of non-padding data they can contain is bounded. These packets may be spread over a similarly enormous number of Ogg pages. Encoders SHOULD use no more padding than required to make a VBR stream CBR. Decoders SHOULD avoid attempting to allocate excessive amounts of memory when presented with a very large packet. The presence of an extremely large packet in the stream could indicate a potential memory exhaustion attack or stream corruption. Decoders should reject a packet that is too large to process, and print a warning message.	+	Technically valid Opus packets can be arbitrarily large due to the padding format, although the amount of non-padding data they can contain is bounded. These packets may be spread over a similarly enormous number of Ogg pages. Encoders SHOULD use no more padding than required to make a variable bitrate (VBR) stream constant bitrate (CBR). Decoders SHOULD avoid attempting to allocate excessive amounts of memory when presented with a very large packet. The presence of an extremely large packet in the stream could indicate a potential memory exhaustion attack or stream corruption. Decoders should reject a packet that is too large to process, and print a warning message.

	In an Ogg Opus stream, the largest possible valid packet that does not use padding has a size of (61,298N - 2) bytes, or about 60 kB per Opus stream. With 255 streams, this is 15,630,988 bytes (14.9 MB) and can span up to 61,298 Ogg pages, all but one of which will have a granulepos of -1. This is of course a very extreme packet, consisting of 255 streams, each containing 120 ms of audio encoded as 2.5 ms frames, each frame using the maximum possible number of bytes (1275) and stored in the least efficient manner allowed (a VBR code 3 Opus packet). Even in such a packet, most of the data will be zeros, as 2.5 ms frames, which are required to run in the MDCT mode, cannot actually use all 1275 bytes. The largest packet consisting entirely of useful data is (15,326N - 2) bytes, or about 15 kB per stream. This corresponds to 120 ms of audio encoded as 10 ms frames in either LP or Hybrid mode, but at a data rate of over 1 Mbps, which makes little sense for the quality achieved. A more reasonable limit is (7,664*N - 2) bytes, or about 7.5 kB per stream. This corresponds to 120 ms of audio encoded as 20 ms stereo MDCT-mode frames, with a total bitrate just under 511 kbps (not counting the Ogg encapsulation overhead). With N=8, the maximum useful number of streams for the channel meanings currently defined by mapping family 1, this gives a maximum packet size of 61,310 bytes, or just under 60 kB. This is still quite conservative, as it assumes each output channel is taken from one decoded channel of a stereo packet. An implementation could reasonably choose any of these numbers for its internal limits.		In an Ogg Opus stream, the largest possible valid packet that does not use padding has a size of (61,298N - 2) bytes, or about 60 kB per Opus stream. With 255 streams, this is 15,630,988 bytes (14.9 MB) and can span up to 61,298 Ogg pages, all but one of which will have a granulepos of -1. This is of course a very extreme packet, consisting of 255 streams, each containing 120 ms of audio encoded as 2.5 ms frames, each frame using the maximum possible number of bytes (1275) and stored in the least efficient manner allowed (a VBR code 3 Opus packet). Even in such a packet, most of the data will be zeros, as 2.5 ms frames, which are required to run in the MDCT mode, cannot actually use all 1275 bytes. The largest packet consisting entirely of useful data is (15,326N - 2) bytes, or about 15 kB per stream. This corresponds to 120 ms of audio encoded as 10 ms frames in either LP or Hybrid mode, but at a data rate of over 1 Mbps, which makes little sense for the quality achieved. A more reasonable limit is (7,664*N - 2) bytes, or about 7.5 kB per stream. This corresponds to 120 ms of audio encoded as 20 ms stereo MDCT-mode frames, with a total bitrate just under 511 kbps (not counting the Ogg encapsulation overhead). With N=8, the maximum useful number of streams for the channel meanings currently defined by mapping family 1, this gives a maximum packet size of 61,310 bytes, or just under 60 kB. This is still quite conservative, as it assumes each output channel is taken from one decoded channel of a stereo packet. An implementation could reasonably choose any of these numbers for its internal limits.

OggOpus/testvectors

2012-05-10T17:14:49Z

Illegal test vectors that MUST fail: two new cases from derf's updates

← Older revision		Revision as of 17:14, 10 May 2012
Line 40:		Line 40:
	** R128_TRACK_GAIN comments containing illegal values (should this be required to fail?)		** R128_TRACK_GAIN comments containing illegal values (should this be required to fail?)
	*** Non-ASCII encodings of correct-looking values		*** Non-ASCII encodings of correct-looking values
-	*All GP==0	+	* All GP==0
		+	* first data granulepos too small
		+	* preskip > final granulepos

OggOpus

2012-05-10T17:12:15Z

Recommend against excessive padding.

← Older revision		Revision as of 17:12, 10 May 2012
(5 intermediate revisions not shown)
Line 29:		Line 29:
	The granule position of an audio page is in units of PCM audio samples at a fixed rate of 48 kHz (per channel; a stereo stream’s granule position does not increment at twice the speed of a mono stream). It is possible to run a decoder at other sampling rates, but the format and this specification always count samples assuming a 48 kHz decoding rate.		The granule position of an audio page is in units of PCM audio samples at a fixed rate of 48 kHz (per channel; a stereo stream’s granule position does not increment at twice the speed of a mono stream). It is possible to run a decoder at other sampling rates, but the format and this specification always count samples assuming a 48 kHz decoding rate.

-	The duration of an Opus packet may be any multiple of 2.5 ms, up to a maximum of 120 ms. This duration is encoded in the TOC sequence at the beginning of each packet. The number of samples returned by a decoder corresponds to this duration exactly, even for the first few packets. For example, a 20 ms packet fed to a decoder running at 48 kHz will always return 960 samples. A demuxer can parse these TOC sequences to work backwards or forwards from a packet with a known granule position (i.e., the last packet completed on some page) in order to assign granule positions to every packet, or even every individual sample. The one exception is the last page in the stream, as described below. ~~Every~~ other ~~page~~ with completed packets after the first MUST have a granule position equal to the number of samples contained in packets that complete on that page plus the granule position of the most recent page with completed packets. This guarantees that a demuxer ~~will~~ assign individual packets the same granule position when working forwards as when working backwards. There must not be any gaps. In order to support capturing a stream that uses discontinuous transmission (DTX), an encoder SHOULD emit packets that explicitly request the use of Packet Loss Concealment (PLC) (i.e., with a frame length of 0, as defined in Section 3.2.1 of the Opus Specification) in place of the packets that were not transmitted.	+	The duration of an Opus packet may be any multiple of 2.5 ms, up to a maximum of 120 ms. This duration is encoded in the TOC sequence at the beginning of each packet. The number of samples returned by a decoder corresponds to this duration exactly, even for the first few packets. For example, a 20 ms packet fed to a decoder running at 48 kHz will always return 960 samples. A demuxer can parse these TOC sequences to work backwards or forwards from a packet with a known granule position (i.e., the last packet completed on some page) in order to assign granule positions to every packet, or even every individual sample. The one exception is the last page in the stream, as described below.
		+
		+	All other pages with completed packets after the first MUST have a granule position equal to the number of samples contained in packets that complete on that page plus the granule position of the most recent page with completed packets. This guarantees that a demuxer can assign individual packets the same granule position when working forwards as when working backwards. There must not be any gaps. In order to support capturing a stream that uses discontinuous transmission (DTX), an encoder SHOULD emit packets that explicitly request the use of Packet Loss Concealment (PLC) (i.e., with a frame length of 0, as defined in Section 3.2.1 of the Opus Specification) in place of the packets that were not transmitted.

	There is some amount of latency introduced during the decoding process, to allow for overlap in the MDCT modes, stereo mixing in the LP modes, and resampling, and the encoder will introduce even more latency (though the exact amount is not specified). Therefore the first few samples produced by the decoder do not correspond to any real, input audio, but are instead composed of padding inserted by the encoder to compensate for this latency. These samples must be stored and decoded, as Opus is an asymptotically convergent predictive codec, meaning the decoded contents of each frame depend on the recent history of decoder inputs. A 'pre-skip' field in the ID header signals the number of samples which should be skipped at the beginning of the stream. This provides sufficient history to the decoder so that it has already converged before the stream's output begins. It may also be used to perform sample-accurate cropping of existing encoded streams. This amount need not be a multiple of 2.5 ms, may be smaller than a single packet, or may span the contents of several packets.		There is some amount of latency introduced during the decoding process, to allow for overlap in the MDCT modes, stereo mixing in the LP modes, and resampling, and the encoder will introduce even more latency (though the exact amount is not specified). Therefore the first few samples produced by the decoder do not correspond to any real, input audio, but are instead composed of padding inserted by the encoder to compensate for this latency. These samples must be stored and decoded, as Opus is an asymptotically convergent predictive codec, meaning the decoded contents of each frame depend on the recent history of decoder inputs. A 'pre-skip' field in the ID header signals the number of samples which should be skipped at the beginning of the stream. This provides sufficient history to the decoder so that it has already converged before the stream's output begins. It may also be used to perform sample-accurate cropping of existing encoded streams. This amount need not be a multiple of 2.5 ms, may be smaller than a single packet, or may span the contents of several packets.
Line 99:		Line 101:

	* '''Version'''		* '''Version'''
-	The version number must always be ~~zero~~ for this version of the encapsulation ~~spec~~. ~~We do not plan~~ to ~~revise~~ the ~~spec~~, ~~but~~ this ~~also acts~~ as a null terminator for the ~~signature bytes and helps align the rest of the fields~~.	+	The version number must always be '1' for this version of the encapsulation specification. This 8-bit field is partitioned into two sub-fields. The lower four bits constitute a "minor revision", while the upper four bits correspond to a "major revision". Implementations SHOULD treat streams with an unknown minor revision as backwards-compatible as long as they recognize the major revision. When encountering a stream with an unknown major revision, implementations SHOULD assume it is not backwards compatible. The initial version '1' was chosen to keep implementations from relying on this byte as a null terminator for the OpusHead string.

	* '''Channel count''' 'c'		* '''Channel count''' 'c'
Line 200:		Line 202:
	== Other Implementation Notes ==		== Other Implementation Notes ==

-	When seeking within an Ogg Opus stream, the decoder should start decoding (and discarding the output) at least 3840 samples prior to the seek point in order to ensure that the output audio is correct at the seek point.	+	When seeking within an Ogg Opus stream, the decoder should start decoding (and discarding the output) at least 3840 samples (80 ms) prior to the seek point in order to ensure that the output audio is correct at the seek point.
		+
		+	Technically valid Opus packets can be arbitrarily large due to the padding format, although the amount of non-padding data they can contain is bounded. These packets may be spread over a similarly enormous number of Ogg pages. Encoders SHOULD use no more padding than required to make a VBR stream CBR. Decoders SHOULD avoid attempting to allocate excessive amounts of memory when presented with a very large packet. The presence of an extremely large packet in the stream could indicate a potential memory exhaustion attack or stream corruption. Decoders should reject a packet that is too large to process, and print a warning message.

-	Technically valid Opus packets can be arbitrarily large due to the padding format, although the amount of non-padding data they can contain is bounded. These packets may be spread over a similarly enormous number of Ogg pages. Decoders SHOULD avoid attempting to allocate excessive amounts of memory when presented with a very large packet. The presence of an extremely large packet in the stream could indicate a potential memory exhaustion attack or stream corruption. Decoders should reject a packet that is too large to process, and print a warning message. In an Ogg Opus stream, the largest possible valid packet that does not use padding has a size of ~~15630988~~ bytes (14.9 ~~MiB~~) and can span up to ~~61298~~ Ogg ~~Pages~~, all but one of which will have a granulepos of -1. This is of course a very extreme packet, consisting of 255 ~~channels~~, each containing ~~120ms~~ of audio encoded as 2.~~5ms~~ frames, each frame using the maximum possible number of bytes and stored in the least efficient manner allowed.	+	In an Ogg Opus stream, the largest possible valid packet that does not use padding has a size of (61,298N - 2) bytes, or about 60 kB per Opus stream. With 255 streams, this is 15,630,988 bytes (14.9 MB) and can span up to 61,298 Ogg pages, all but one of which will have a granulepos of -1. This is of course a very extreme packet, consisting of 255 streams, each containing 120 ms of audio encoded as 2.5 ms frames, each frame using the maximum possible number of bytes (1275) and stored in the least efficient manner allowed (a VBR code 3 Opus packet). Even in such a packet, most of the data will be zeros, as 2.5 ms frames, which are required to run in the MDCT mode, cannot actually use all 1275 bytes. The largest packet consisting entirely of useful data is (15,326N - 2) bytes, or about 15 kB per stream. This corresponds to 120 ms of audio encoded as 10 ms frames in either LP or Hybrid mode, but at a data rate of over 1 Mbps, which makes little sense for the quality achieved. A more reasonable limit is (7,664*N - 2) bytes, or about 7.5 kB per stream. This corresponds to 120 ms of audio encoded as 20 ms stereo MDCT-mode frames, with a total bitrate just under 511 kbps (not counting the Ogg encapsulation overhead). With N=8, the maximum useful number of streams for the channel meanings currently defined by mapping family 1, this gives a maximum packet size of 61,310 bytes, or just under 60 kB. This is still quite conservative, as it assumes each output channel is taken from one decoded channel of a stereo packet. An implementation could reasonably choose any of these numbers for its internal limits.

	== Test Vectors ==		== Test Vectors ==

User:Derf

2012-05-10T14:59:58Z

changed group membership for User:Derf from Bots, Bureaucrats, Check users, Oversights and Administrators to Bureaucrats, Check users, Oversights and Administrators