Lines Matching full:packet
91 codebooks as well as indicate if the following packet contains fragmented
175 The sequence number increments by one for each RTP data packet sent, and may be
176 used by the receiver to detect packet loss and to restore the packet sequence. This
184 Vorbis packet in the RTP payload. The clock frequency MUST be set to the sample
239 This field specifies the kind of Vorbis data stored in this RTP packet. There
240 are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis packet (e.g., you must not aggregate configuration and comment packets in the same RTP payload).
265 likely define a practical limit. Typical Vorbis packet sizes range from very
269 RTP context, to avoid fragmentation, the Vorbis data packet size SHOULD be kept
271 complete RTP packet is smaller than the path MTU.
279 | length | vorbis packet data ..
285 Each Vorbis payload packet starts with a two octet length header, which is used
293 of the packet length followed by the packet data for each of the Vorbis packets
298 The Vorbis packet length header is the length of the Vorbis data block only and
304 set out in <xref target="RFC3551"></xref>, where the oldest Vorbis packet occurs
305 immediately after the RTP packet header. Subsequent Vorbis packets, if any, MUST
316 <section anchor="Example RTP Packet" title="Example RTP Packet">
322 <figure anchor="Example Raw Vorbis Packet" title="Example Raw Vorbis Packet">
343 | length | next vorbis packet data ..
353 The payload data section of the RTP packet begins with the 24-bit Ident field
356 length field. The Packet Type and Fragment Type are set to 0. The Configuration
379 requires the presence of a comment header packet that gives simple
417 decode a packet. When the Ident field changes, it indicates that a change in
428 sent in-band with the packet type bits set to match the Vorbis Data Type.
431 The RTP timestamp value MUST reflect the transmission time of the first data packet for which this configuration applies.
514 packet bears the full Packed configuration. The number of the packet is set to 1.</t>
521 The following packet definition MUST be used when Configuration is inside
606 Vorbis Data Type flag set to 2 indicates that the packet contains
612 <figure anchor="Comment Packet Figure" title="Comment Packet">
639 The 2-byte length field is necessary since this packet could be fragmented.
646 Each RTP payload contains either one Vorbis packet fragment or an integer
652 Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP
659 A fragmented packet has a zero in the last four bits of the payload header.
664 Vorbis packet will have the Fragment type set to 3. To maintain the correct
665 sequence for fragmented packet reception, the timestamp field of fragmented
666 packets MUST be the same as the first packet sent, with the sequence number
671 <section anchor="Example Fragmented Vorbis Packet" title="Example Fragmented Vorbis Packet">
674 Here is an example of a fragmented Vorbis packet split over three RTP payloads.
679 <figure anchor="Example Fragmented Packet (Packet 1)" title="Example Fragmented Packet (Packet 1)">
681 Packet 1:
710 <figure anchor="Example Fragmented Packet (Packet 2)" title="Example Fragmented Packet (Packet 2)">
712 Packet 2:
739 The maximum packet size SHOULD be no greater than the path MTU,
744 <figure anchor="Example Fragmented Packet (Packet 3)" title="Example Fragmented Packet (Packet 3)">
746 Packet 3:
772 packet count remains set to 0. As in the previous payloads, the timestamp remains
778 <section anchor="Packet Loss" title="Packet Loss">
781 As there is no error correction within the Vorbis stream, packet loss will
782 result in a loss of signal. Packet loss is more of an issue for fragmented
785 remaining Vorbis fragments and decode the incomplete packet. If we use the
786 fragmented Vorbis packet example above and the first RTP payload is lost, the
787 client MUST detect that the next RTP payload has the packet count field set
789 The next RTP payload, which is the final fragmented packet, MUST be dropped
792 kept and the incomplete Vorbis packet decoded.
797 Configuration packet with the result detailed in the <xref target="Loss of Configuration Headers">Loss of Configuration Headers</xref> section.
841 Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://xiph.org/
987 advance, the Configuration Packet for each file SHOULD be passed to the client
1004 configuration packet is inside the SDP; other configurations could be
1077 as soon as it discovers a Configuration packet got lost in-band, or use
1155 <title>Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://xiph.org/vorbis/doc/Vorbis_I_spec.html</title>
