| CODENOTIFIER | HelpYou are not signed inSign in |
Project: OGG Vorbis
Revision: 15227
Author: ivo
Date: 31 Aug 2008 18:35:03
Changes:Replaced RTP draft with RFC 5215.
Files:| ... | ...@@ -0,0 +1,1459 @@ | |
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | ||
| 7 | Network Working Group L. Barbato | |
| 8 | Request for Comments: 5215 Xiph | |
| 9 | Category: Standards Track August 2008 | |
| 10 | ||
| 11 | ||
| 12 | RTP Payload Format for Vorbis Encoded Audio | |
| 13 | ||
| 14 | Status of This Memo | |
| 15 | ||
| 16 | This document specifies an Internet standards track protocol for the | |
| 17 | Internet community, and requests discussion and suggestions for | |
| 18 | improvements. Please refer to the current edition of the "Internet | |
| 19 | Official Protocol Standards" (STD 1) for the standardization state | |
| 20 | and status of this protocol. Distribution of this memo is unlimited. | |
| 21 | ||
| 22 | Abstract | |
| 23 | ||
| 24 | This document describes an RTP payload format for transporting Vorbis | |
| 25 | encoded audio. It details the RTP encapsulation mechanism for raw | |
| 26 | Vorbis data and the delivery mechanisms for the decoder probability | |
| 27 | model (referred to as a codebook), as well as other setup | |
| 28 | information. | |
| 29 | ||
| 30 | Also included within this memo are media type registrations and the | |
| 31 | details necessary for the use of Vorbis with the Session Description | |
| 32 | Protocol (SDP). | |
| 33 | ||
| 34 | ||
| 35 | ||
| 36 | ||
| 37 | ||
| 38 | ||
| 39 | ||
| 40 | ||
| 41 | ||
| 42 | ||
| 43 | ||
| 44 | ||
| 45 | ||
| 46 | ||
| 47 | ||
| 48 | ||
| 49 | ||
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | ||
| 54 | ||
| 55 | ||
| 56 | ||
| 57 | ||
| 58 | Barbato Standards Track [Page 1] | |
| 59 | ||
| 60 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 61 | ||
| 62 | ||
| 63 | Table of Contents | |
| 64 | ||
| 65 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 66 | 1.1. Conformance and Document Conventions . . . . . . . . . . . 3 | |
| 67 | 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 68 | 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
| 69 | 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 | |
| 70 | 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 | |
| 71 | 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8 | |
| 72 | 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8 | |
| 73 | 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9 | |
| 74 | 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10 | |
| 75 | 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12 | |
| 76 | 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12 | |
| 77 | 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13 | |
| 78 | 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13 | |
| 79 | 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14 | |
| 80 | 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15 | |
| 81 | 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 | |
| 82 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | |
| 83 | 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19 | |
| 84 | 7. SDP Related Considerations . . . . . . . . . . . . . . . . . . 20 | |
| 85 | 7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20 | |
| 86 | 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21 | |
| 87 | 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 22 | |
| 88 | 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22 | |
| 89 | 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |
| 90 | 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22 | |
| 91 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |
| 92 | 11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23 | |
| 93 | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | |
| 94 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |
| 95 | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 | |
| 96 | 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 | |
| 97 | ||
| 98 | ||
| 99 | ||
| 100 | ||
| 101 | ||
| 102 | ||
| 103 | ||
| 104 | ||
| 105 | ||
| 106 | ||
| 107 | ||
| 108 | ||
| 109 | ||
| 110 | ||
| 111 | ||
| 112 | ||
| 113 | ||
| 114 | Barbato Standards Track [Page 2] | |
| 115 | ||
| 116 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 117 | ||
| 118 | ||
| 119 | 1. Introduction | |
| 120 | ||
| 121 | Vorbis is a general purpose perceptual audio codec intended to allow | |
| 122 | maximum encoder flexibility, thus allowing it to scale competitively | |
| 123 | over an exceptionally wide range of bit rates. At the high quality/ | |
| 124 | bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is | |
| 125 | in the same league as MPEG-4 AAC. Vorbis is also intended for lower | |
| 126 | and higher sample rates (from 8kHz telephony to 192kHz digital | |
| 127 | masters) and a range of channel representations (monaural, | |
| 128 | polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 | |
| 129 | discrete channels). | |
| 130 | ||
| 131 | Vorbis encoded audio is generally encapsulated within an Ogg format | |
| 132 | bitstream [RFC3533], which provides framing and synchronization. For | |
| 133 | the purposes of RTP transport, this layer is unnecessary, and so raw | |
| 134 | Vorbis packets are used in the payload. | |
| 135 | ||
| 136 | 1.1. Conformance and Document Conventions | |
| 137 | ||
| 138 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
| 139 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
| 140 | document are to be interpreted as described in BCP 14, [RFC2119] and | |
| 141 | indicate requirement levels for compliant implementations. | |
| 142 | Requirements apply to all implementations unless otherwise stated. | |
| 143 | ||
| 144 | An implementation is a software module that supports one of the media | |
| 145 | types defined in this document. Software modules may support | |
| 146 | multiple media types, but conformance is considered individually for | |
| 147 | each type. | |
| 148 | ||
| 149 | Implementations that fail to satisfy one or more "MUST" requirements | |
| 150 | are considered non-compliant. Implementations that satisfy all | |
| 151 | "MUST" requirements, but fail to satisfy one or more "SHOULD" | |
| 152 | requirements, are said to be "conditionally compliant". All other | |
| 153 | implementations are "unconditionally compliant". | |
| 154 | ||
| 155 | 2. Payload Format | |
| 156 | ||
| 157 | For RTP-based transport of Vorbis-encoded audio, the standard RTP | |
| 158 | header is followed by a 4-octet payload header, and then the payload | |
| 159 | data. The payload headers are used to associate the Vorbis data with | |
| 160 | its associated decoding codebooks as well as indicate if the | |
| 161 | following packet contains fragmented Vorbis data and/or the number of | |
| 162 | whole Vorbis data frames. The payload data contains the raw Vorbis | |
| 163 | bitstream information. There are 3 types of Vorbis data; an RTP | |
| 164 | payload MUST contain just one of them at a time. | |
| 165 | ||
| 166 | ||
| 167 | ||
| 168 | ||
| 169 | ||
| 170 | Barbato Standards Track [Page 3] | |
| 171 | ||
| 172 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 173 | ||
| 174 | ||
| 175 | 2.1. RTP Header | |
| 176 | ||
| 177 | The format of the RTP header is specified in [RFC3550] and shown in | |
| 178 | Figure 1. This payload format uses the fields of the header in a | |
| 179 | manner consistent with that specification. | |
| 180 | ||
| 181 | 0 1 2 3 | |
| 182 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 183 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 184 | |V=2|P|X| CC |M| PT | sequence number | | |
| 185 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 186 | | timestamp | | |
| 187 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 188 | | synchronization source (SSRC) identifier | | |
| 189 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| 190 | | contributing source (CSRC) identifiers | | |
| 191 | | ... | | |
| 192 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 193 | ||
| 194 | Figure 1: RTP Header | |
| 195 | ||
| 196 | The RTP header begins with an octet of fields (V, P, X, and CC) to | |
| 197 | support specialized RTP uses (see [RFC3550] and [RFC3551] for | |
| 198 | details). For Vorbis RTP, the following values are used. | |
| 199 | ||
| 200 | Version (V): 2 bits | |
| 201 | ||
| 202 | This field identifies the version of RTP. The version used by this | |
| 203 | specification is two (2). | |
| 204 | ||
| 205 | Padding (P): 1 bit | |
| 206 | ||
| 207 | Padding MAY be used with this payload format according to Section 5.1 | |
| 208 | of [RFC3550]. | |
| 209 | ||
| 210 | Extension (X): 1 bit | |
| 211 | ||
| 212 | The Extension bit is used in accordance with [RFC3550]. | |
| 213 | ||
| 214 | CSRC count (CC): 4 bits | |
| 215 | ||
| 216 | The CSRC count is used in accordance with [RFC3550]. | |
| 217 | ||
| 218 | Marker (M): 1 bit | |
| 219 | ||
| 220 | Set to zero. Audio silence suppression is not used. This conforms | |
| 221 | to Section 4.1 of [VORBIS-SPEC-REF]. | |
| 222 | ||
| 223 | ||
| 224 | ||
| 225 | ||
| 226 | Barbato Standards Track [Page 4] | |
| 227 | ||
| 228 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 229 | ||
| 230 | ||
| 231 | Payload Type (PT): 7 bits | |
| 232 | ||
| 233 | An RTP profile for a class of applications is expected to assign a | |
| 234 | payload type for this format, or a dynamically allocated payload type | |
| 235 | SHOULD be chosen that designates the payload as Vorbis. | |
| 236 | ||
| 237 | Sequence number: 16 bits | |
| 238 | ||
| 239 | The sequence number increments by one for each RTP data packet sent, | |
| 240 | and may be used by the receiver to detect packet loss and to restore | |
| 241 | the packet sequence. This field is detailed further in [RFC3550]. | |
| 242 | ||
| 243 | Timestamp: 32 bits | |
| 244 | ||
| 245 | A timestamp representing the sampling time of the first sample of the | |
| 246 | first Vorbis packet in the RTP payload. The clock frequency MUST be | |
| 247 | set to the sample rate of the encoded audio data and is conveyed out- | |
| 248 | of-band (e.g., as an SDP parameter). | |
| 249 | ||
| 250 | SSRC/CSRC identifiers: | |
| 251 | ||
| 252 | These two fields, 32 bits each with one SSRC field and a maximum of | |
| 253 | 16 CSRC fields, are as defined in [RFC3550]. | |
| 254 | ||
| 255 | 2.2. Payload Header | |
| 256 | ||
| 257 | The 4 octets following the RTP Header section are the Payload Header. | |
| 258 | This header is split into a number of bit fields detailing the format | |
| 259 | of the following payload data packets. | |
| 260 | ||
| 261 | 0 1 2 3 | |
| 262 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 264 | | Ident | F |VDT|# pkts.| | |
| 265 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 266 | ||
| 267 | Figure 2: Payload Header | |
| 268 | ||
| 269 | Ident: 24 bits | |
| 270 | ||
| 271 | This 24-bit field is used to associate the Vorbis data to a decoding | |
| 272 | Configuration. It is stored as a network byte order integer. | |
| 273 | ||
| 274 | Fragment type (F): 2 bits | |
| 275 | ||
| 276 | ||
| 277 | ||
| 278 | ||
| 279 | ||
| 280 | ||
| 281 | ||
| 282 | Barbato Standards Track [Page 5] | |
| 283 | ||
| 284 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 285 | ||
| 286 | ||
| 287 | This field is set according to the following list: | |
| 288 | ||
| 289 | 0 = Not Fragmented | |
| 290 | ||
| 291 | 1 = Start Fragment | |
| 292 | ||
| 293 | 2 = Continuation Fragment | |
| 294 | ||
| 295 | 3 = End Fragment | |
| 296 | ||
| 297 | Vorbis Data Type (VDT): 2 bits | |
| 298 | ||
| 299 | This field specifies the kind of Vorbis data stored in this RTP | |
| 300 | packet. There are currently three different types of Vorbis | |
| 301 | payloads. Each packet MUST contain only a single type of Vorbis | |
| 302 | packet (e.g., you must not aggregate configuration and comment | |
| 303 | packets in the same RTP payload). | |
| 304 | ||
| 305 | 0 = Raw Vorbis payload | |
| 306 | ||
| 307 | 1 = Vorbis Packed Configuration payload | |
| 308 | ||
| 309 | 2 = Legacy Vorbis Comment payload | |
| 310 | ||
| 311 | 3 = Reserved | |
| 312 | ||
| 313 | The packets with a VDT of value 3 MUST be ignored. | |
| 314 | ||
| 315 | The last 4 bits represent the number of complete packets in this | |
| 316 | payload. This provides for a maximum number of 15 Vorbis packets in | |
| 317 | the payload. If the payload contains fragmented data, the number of | |
| 318 | packets MUST be set to 0. | |
| 319 | ||
| 320 | 2.3. Payload Data | |
| 321 | ||
| 322 | Raw Vorbis packets are currently unbounded in length; application | |
| 323 | profiles will likely define a practical limit. Typical Vorbis packet | |
| 324 | sizes range from very small (2-3 bytes) to quite large (8-12 | |
| 325 | kilobytes). The reference implementation [LIBVORBIS] typically | |
| 326 | produces packets less than ~800 bytes, except for the setup header | |
| 327 | packets, which are ~4-12 kilobytes. Within an RTP context, to avoid | |
| 328 | fragmentation, the Vorbis data packet size SHOULD be kept | |
| 329 | sufficiently small so that after adding the RTP and payload headers, | |
| 330 | the complete RTP packet is smaller than the path MTU. | |
| 331 | ||
| 332 | ||
| 333 | ||
| 334 | ||
| 335 | ||
| 336 | ||
| 337 | ||
| 338 | Barbato Standards Track [Page 6] | |
| 339 | ||
| 340 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 341 | ||
| 342 | ||
| 343 | 0 1 2 3 | |
| 344 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 345 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 346 | | length | vorbis packet data .. | |
| 347 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 348 | ||
| 349 | Figure 3: Payload Data Header | |
| 350 | ||
| 351 | Each Vorbis payload packet starts with a two octet length header, | |
| 352 | which is used to represent the size in bytes of the following data | |
| 353 | payload, and is followed by the raw Vorbis data padded to the nearest | |
| 354 | byte boundary, as explained by the Vorbis I Specification | |
| 355 | [VORBIS-SPEC-REF]. The length value is stored as a network byte | |
| 356 | order integer. | |
| 357 | ||
| 358 | For payloads that consist of multiple Vorbis packets, the payload | |
| 359 | data consists of the packet length followed by the packet data for | |
| 360 | each of the Vorbis packets in the payload. | |
| 361 | ||
| 362 | The Vorbis packet length header is the length of the Vorbis data | |
| 363 | block only and does not include the length field. | |
| 364 | ||
| 365 | The payload packing of the Vorbis data packets MUST follow the | |
| 366 | guidelines set out in [RFC3551], where the oldest Vorbis packet | |
| 367 | occurs immediately after the RTP packet header. Subsequent Vorbis | |
| 368 | packets, if any, MUST follow in temporal order. | |
| 369 | ||
| 370 | Audio channel mapping is in accordance with the Vorbis I | |
| 371 | Specification [VORBIS-SPEC-REF]. | |
| 372 | ||
| 373 | ||
| 374 | ||
| 375 | ||
| 376 | ||
| 377 | ||
| 378 | ||
| 379 | ||
| 380 | ||
| 381 | ||
| 382 | ||
| 383 | ||
| 384 | ||
| 385 | ||
| 386 | ||
| 387 | ||
| 388 | ||
| 389 | ||
| 390 | ||
| 391 | ||
| 392 | ||
| 393 | ||
| 394 | Barbato Standards Track [Page 7] | |
| 395 | ||
| 396 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 397 | ||
| 398 | ||
| 399 | 2.4. Example RTP Packet | |
| 400 | ||
| 401 | Here is an example RTP payload containing two Vorbis packets. | |
| 402 | ||
| 403 | 0 1 2 3 | |
| 404 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 405 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 406 | | 2 |0|0| 0 |0| PT | sequence number | | |
| 407 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 408 | | timestamp (in sample rate units) | | |
| 409 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 410 | | synchronisation source (SSRC) identifier | | |
| 411 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| 412 | | contributing source (CSRC) identifiers | | |
| 413 | | ... | | |
| 414 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 415 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 416 | | Ident | 0 | 0 | 2 pks | | |
| 417 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 418 | | length | vorbis data .. | |
| 419 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 420 | .. vorbis data | | |
| 421 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 422 | | length | next vorbis packet data .. | |
| 423 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 424 | .. vorbis data .. | |
| 425 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 426 | .. vorbis data | | |
| 427 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 428 | ||
| 429 | Figure 4: Example Raw Vorbis Packet | |
| 430 | ||
| 431 | The payload data section of the RTP packet begins with the 24-bit | |
| 432 | Ident field followed by the one octet bit field header, which has the | |
| 433 | number of Vorbis frames set to 2. Each of the Vorbis data frames is | |
| 434 | prefixed by the two octets length field. The Packet Type and | |
| 435 | Fragment Type are set to 0. The Configuration that will be used to | |
| 436 | decode the packets is the one indexed by the ident value. | |
| 437 | ||
| 438 | 3. Configuration Headers | |
| 439 | ||
| 440 | Unlike other mainstream audio codecs, Vorbis has no statically | |
| 441 | configured probability model. Instead, it packs all entropy decoding | |
| 442 | configuration, Vector Quantization and Huffman models into a data | |
| 443 | block that must be transmitted to the decoder with the compressed | |
| 444 | data. A decoder also requires information detailing the number of | |
| 445 | audio channels, bitrates, and similar information to configure itself | |
| 446 | for a particular compressed data stream. These two blocks of | |
| 447 | ||
| 448 | ||
| 449 | ||
| 450 | Barbato Standards Track [Page 8] | |
| 451 | ||
| 452 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 453 | ||
| 454 | ||
| 455 | information are often referred to collectively as the "codebooks" for | |
| 456 | a Vorbis stream, and are included as special "header" packets at the | |
| 457 | start of the compressed data. In addition, the Vorbis I | |
| 458 | specification [VORBIS-SPEC-REF] requires the presence of a comment | |
| 459 | header packet that gives simple metadata about the stream, but this | |
| 460 | information is not required for decoding the frame sequence. | |
| 461 | ||
| 462 | Thus, these two codebook header packets must be received by the | |
| 463 | decoder before any audio data can be interpreted. These requirements | |
| 464 | pose problems in RTP, which is often used over unreliable transports. | |
| 465 | ||
| 466 | Since this information must be transmitted reliably and, as the RTP | |
| 467 | stream may change certain configuration data mid-session, there are | |
| 468 | different methods for delivering this configuration data to a client, | |
| 469 | both in-band and out-of-band, which are detailed below. In order to | |
| 470 | set up an initial state for the client application, the configuration | |
| 471 | MUST be conveyed via the signalling channel used to set up the | |
| 472 | session. One example of such signalling is SDP [RFC4566] with the | |
| 473 | Offer/Answer Model [RFC3264]. Changes to the configuration MAY be | |
| 474 | communicated via a re-invite, conveying a new SDP, or sent in-band in | |
| 475 | the RTP channel. Implementations MUST support an in-band delivery of | |
| 476 | updated codebooks, and SHOULD support out-of-band codebook update | |
| 477 | using a new SDP file. The changes may be due to different codebooks | |
| 478 | as well as different bitrates of the RTP stream. | |
| 479 | ||
| 480 | For non-chained streams, the recommended Configuration delivery | |
| 481 | method is inside the Packed Configuration (Section 3.1.1) in the SDP | |
| 482 | as explained the Mapping Media Type Parameters into SDP | |
| 483 | (Section 7.1). | |
| 484 | ||
| 485 | The 24-bit Ident field is used to map which Configuration will be | |
| 486 | used to decode a packet. When the Ident field changes, it indicates | |
| 487 | that a change in the stream has taken place. The client application | |
| 488 | MUST have in advance the correct configuration. If the client | |
| 489 | detects a change in the Ident value and does not have this | |
| 490 | information, it MUST NOT decode the raw associated Vorbis data until | |
| 491 | it fetches the correct Configuration. | |
| 492 | ||
| 493 | 3.1. In-band Header Transmission | |
| 494 | ||
| 495 | The Packed Configuration (Section 3.1.1) Payload is sent in-band with | |
| 496 | the packet type bits set to match the Vorbis Data Type. Clients MUST | |
| 497 | be capable of dealing with fragmentation and periodic re-transmission | |
| 498 | of [RFC4588] the configuration headers. The RTP timestamp value MUST | |
| 499 | reflect the transmission time of the first data packet for which this | |
| 500 | configuration applies. | |
| 501 | ||
| 502 | ||
| 503 | ||
| 504 | ||
| 505 | ||
| 506 | Barbato Standards Track [Page 9] | |
| 507 | ||
| 508 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 509 | ||
| 510 | ||
| 511 | 3.1.1. Packed Configuration | |
| 512 | ||
| 513 | A Vorbis Packed Configuration is indicated with the Vorbis Data Type | |
| 514 | field set to 1. Of the three headers defined in the Vorbis I | |
| 515 | specification [VORBIS-SPEC-REF], the Identification and the Setup | |
| 516 | MUST be packed as they are, while the Comment header MAY be replaced | |
| 517 | with a dummy one. | |
| 518 | ||
| 519 | The packed configuration stores Xiph codec configurations in a | |
| 520 | generic way: the first field stores the number of the following | |
| 521 | packets minus one (count field), the next ones represent the size of | |
| 522 | the headers (length fields), and the headers immediately follow the | |
| 523 | list of length fields. The size of the last header is implicit. | |
| 524 | ||
| 525 | The count and the length fields are encoded using the following | |
| 526 | logic: the data is in network byte order; every byte has the most | |
| 527 | significant bit used as a flag, and the following 7 bits are used to | |
| 528 | store the value. The first 7 most significant bits are stored in the | |
| 529 | first byte. If there are remaining bits, the flag bit is set to 1 | |
| 530 | and the subsequent 7 bits are stored in the following byte. If there | |
| 531 | are remaining bits, set the flag to 1 and the same procedure is | |
| 532 | repeated. The ending byte has the flag bit set to 0. To decode, | |
| 533 | simply iterate over the bytes until the flag bit is set to 0. For | |
| 534 | every byte, the data is added to the accumulated value multiplied by | |
| 535 | 128. | |
| 536 | ||
| 537 | The headers are packed in the same order as they are present in Ogg | |
| 538 | [VORBIS-SPEC-REF]: Identification, Comment, Setup. | |
| 539 | ||
| 540 | The 2 byte length tag defines the length of the packed headers as the | |
| 541 | sum of the Configuration, Comment, and Setup lengths. | |
| 542 | ||
| 543 | ||
| 544 | ||
| 545 | ||
| 546 | ||
| 547 | ||
| 548 | ||
| 549 | ||
| 550 | ||
| 551 | ||
| 552 | ||
| 553 | ||
| 554 | ||
| 555 | ||
| 556 | ||
| 557 | ||
| 558 | ||
| 559 | ||
| 560 | ||
| 561 | ||
| 562 | Barbato Standards Track [Page 10] | |
| 563 | ||
| 564 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 565 | ||
| 566 | ||
| 567 | 0 1 2 3 | |
| 568 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 569 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 570 | |V=2|P|X| CC |M| PT | xxxx | | |
| 571 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 572 | | xxxxx | | |
| 573 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 574 | | synchronization source (SSRC) identifier | | |
| 575 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| 576 | | contributing source (CSRC) identifiers | | |
| 577 | | ... | | |
| 578 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 579 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 580 | | Ident | 0 | 1 | 1| | |
| 581 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 582 | | length | n. of headers | length1 | | |
| 583 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 584 | | length2 | Identification .. | |
| 585 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 586 | .. Identification .. | |
| 587 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 588 | .. Identification .. | |
| 589 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 590 | .. Identification .. | |
| 591 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 592 | .. Identification | Comment .. | |
| 593 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 594 | .. Comment .. | |
| 595 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 596 | .. Comment .. | |
| 597 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 598 | .. Comment .. | |
| 599 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 600 | .. Comment | Setup .. | |
| 601 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 602 | .. Setup .. | |
| 603 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 604 | .. Setup .. | |
| 605 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 606 | ||
| 607 | Figure 5: Packed Configuration Figure | |
| 608 | ||
| 609 | The Ident field is set with the value that will be used by the Raw | |
| 610 | Payload Packets to address this Configuration. The Fragment type is | |
| 611 | set to 0 because the packet bears the full Packed configuration. The | |
| 612 | number of the packet is set to 1. | |
| 613 | ||
| 614 | ||
| 615 | ||
| 616 | ||
| 617 | ||
| 618 | Barbato Standards Track [Page 11] | |
| 619 | ||
| 620 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 621 | ||
| 622 | ||
| 623 | 3.2. Out of Band Transmission | |
| 624 | ||
| 625 | The following packet definition MUST be used when Configuration is | |
| 626 | inside in the SDP. | |
| 627 | ||
| 628 | 3.2.1. Packed Headers | |
| 629 | ||
| 630 | As mentioned above, the RECOMMENDED delivery vector for Vorbis | |
| 631 | configuration data is via a retrieval method that can be performed | |
| 632 | using a reliable transport protocol. As the RTP headers are not | |
| 633 | required for this method of delivery, the structure of the | |
| 634 | configuration data is slightly different. The packed header starts | |
| 635 | with a 32-bit (network-byte ordered) count field, which details the | |
| 636 | number of packed headers that are contained in the bundle. The | |
| 637 | following shows the Packed header payload for each chained Vorbis | |
| 638 | stream. | |
| 639 | ||
| 640 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 641 | | Number of packed headers | | |
| 642 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 643 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 644 | | Packed header | | |
| 645 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 646 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 647 | | Packed header | | |
| 648 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 649 | ||
| 650 | Figure 6: Packed Headers Overview | |
| 651 | ||
| 652 | ||
| 653 | ||
| 654 | ||
| 655 | ||
| 656 | ||
| 657 | ||
| 658 | ||
| 659 | ||
| 660 | ||
| 661 | ||
| 662 | ||
| 663 | ||
| 664 | ||
| 665 | ||
| 666 | ||
| 667 | ||
| 668 | ||
| 669 | ||
| 670 | ||
| 671 | ||
| 672 | ||
| 673 | ||
| 674 | Barbato Standards Track [Page 12] | |
| 675 | ||
| 676 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 677 | ||
| 678 | ||
| 679 | 0 1 2 3 | |
| 680 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 681 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 682 | | Ident | length .. | |
| 683 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 684 | .. | n. of headers | length1 | length2 .. | |
| 685 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 686 | .. | Identification Header .. | |
| 687 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 688 | ................................................................. | |
| 689 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 690 | .. | Comment Header .. | |
| 691 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 692 | ................................................................. | |
| 693 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 694 | .. Comment Header | | |
| 695 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 696 | | Setup Header .. | |
| 697 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 698 | ................................................................. | |
| 699 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 700 | .. Setup Header | | |
| 701 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 702 | ||
| 703 | Figure 7: Packed Headers Detail | |
| 704 | ||
| 705 | The key difference between the in-band format and this one is that | |
| 706 | there is no need for the payload header octet. In this figure, the | |
| 707 | comment has a size bigger than 127 bytes. | |
| 708 | ||
| 709 | 3.3. Loss of Configuration Headers | |
| 710 | ||
| 711 | Unlike the loss of raw Vorbis payload data, loss of a configuration | |
| 712 | header leads to a situation where it will not be possible to | |
| 713 | successfully decode the stream. Implementations MAY try to recover | |
| 714 | from an error by requesting again the missing Configuration or, if | |
| 715 | the delivery method is in-band, by buffering the payloads waiting for | |
| 716 | the Configuration needed to decode them. The baseline reaction | |
| 717 | SHOULD either be reset or end the RTP session. | |
| 718 | ||
| 719 | 4. Comment Headers | |
| 720 | ||
| 721 | Vorbis Data Type flag set to 2 indicates that the packet contains the | |
| 722 | comment metadata, such as artist name, track title, and so on. These | |
| 723 | metadata messages are not intended to be fully descriptive but rather | |
| 724 | to offer basic track/song information. Clients MAY ignore it | |
| 725 | completely. The details on the format of the comments can be found | |
| 726 | in the Vorbis I Specification [VORBIS-SPEC-REF]. | |
| 727 | ||
| 728 | ||
| 729 | ||
| 730 | Barbato Standards Track [Page 13] | |
| 731 | ||
| 732 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 733 | ||
| 734 | ||
| 735 | 0 1 2 3 | |
| 736 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 737 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 738 | |V=2|P|X| CC |M| PT | xxxx | | |
| 739 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 740 | | xxxxx | | |
| 741 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 742 | | synchronization source (SSRC) identifier | | |
| 743 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| 744 | | contributing source (CSRC) identifiers | | |
| 745 | | ... | | |
| 746 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 747 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 748 | | Ident | 0 | 2 | 1| | |
| 749 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 750 | | length | Comment .. | |
| 751 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 752 | .. Comment .. | |
| 753 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 754 | .. Comment | | |
| 755 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 756 | ||
| 757 | Figure 8: Comment Packet | |
| 758 | ||
| 759 | The 2-byte length field is necessary since this packet could be | |
| 760 | fragmented. | |
| 761 | ||
| 762 | 5. Frame Packetization | |
| 763 | ||
| 764 | Each RTP payload contains either one Vorbis packet fragment or an | |
| 765 | integer number of complete Vorbis packets (up to a maximum of 15 | |
| 766 | packets, since the number of packets is defined by a 4-bit value). | |
| 767 | ||
| 768 | Any Vorbis data packet that is less than path MTU SHOULD be bundled | |
| 769 | in the RTP payload with as many Vorbis packets as will fit, up to a | |
| 770 | maximum of 15, except when such bundling would exceed an | |
| 771 | application's desired transmission latency. Path MTU is detailed in | |
| 772 | [RFC1191] and [RFC1981]. | |
| 773 | ||
| 774 | A fragmented packet has a zero in the last four bits of the payload | |
| 775 | header. The first fragment will set the Fragment type to 1. Each | |
| 776 | fragment after the first will set the Fragment type to 2 in the | |
| 777 | payload header. The consecutive fragments MUST be sent without any | |
| 778 | other payload being sent between the first and the last fragment. | |
| 779 | The RTP payload containing the last fragment of the Vorbis packet | |
| 780 | will have the Fragment type set to 3. To maintain the correct | |
| 781 | sequence for fragmented packet reception, the timestamp field of | |
| 782 | fragmented packets MUST be the same as the first packet sent, with | |
| 783 | ||
| 784 | ||
| 785 | ||
| 786 | Barbato Standards Track [Page 14] | |
| 787 | ||
| 788 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 789 | ||
| 790 | ||
| 791 | the sequence number incremented as normal for the subsequent RTP | |
| 792 | payloads; this will affect the RTCP jitter measurement. The length | |
| 793 | field shows the fragment length. | |
| 794 | ||
| 795 | 5.1. Example Fragmented Vorbis Packet | |
| 796 | ||
| 797 | Here is an example of a fragmented Vorbis packet split over three RTP | |
| 798 | payloads. Each of them contains the standard RTP headers as well as | |
| 799 | the 4-octet Vorbis headers. | |
| 800 | ||
| 801 | Packet 1: | |
| 802 | ||
| 803 | 0 1 2 3 | |
| 804 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 805 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 806 | |V=2|P|X| CC |M| PT | 1000 | | |
| 807 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 808 | | 12345 | | |
| 809 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 810 | | synchronization source (SSRC) identifier | | |
| 811 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| 812 | | contributing source (CSRC) identifiers | | |
| 813 | | ... | | |
| 814 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 815 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 816 | | Ident | 1 | 0 | 0| | |
| 817 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 818 | | length | vorbis data .. | |
| 819 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 820 | .. vorbis data | | |
| 821 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 822 | ||
| 823 | Figure 9: Example Fragmented Packet (Packet 1) | |
| 824 | ||
| 825 | In this payload, the initial sequence number is 1000 and the | |
| 826 | timestamp is 12345. The Fragment type is set to 1, the number of | |
| 827 | packets field is set to 0, and as the payload is raw Vorbis data, the | |
| 828 | VDT field is set to 0. | |
| 829 | ||
| 830 | ||
| 831 | ||
| 832 | ||
| 833 | ||
| 834 | ||
| 835 | ||
| 836 | ||
| 837 | ||
| 838 | ||
| 839 | ||
| 840 | ||
| 841 | ||
| 842 | Barbato Standards Track [Page 15] | |
| 843 | ||
| 844 | RFC 5215 Vorbis RTP Payload Format August 2008 | |
| 845 | ||
| 846 | ||
| 847 | Packet 2: | |
| 848 | ||
| 849 | 0 1 2 3 | |
| 850 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
| 851 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| 852 | |V=2|P|X| CC |