Lines Matching full:packet
72 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8
81 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15
82 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
163 following packet contains fragmented Vorbis data and/or the number of
243 The sequence number increments by one for each RTP data packet sent,
244 and may be used by the receiver to detect packet loss and to restore
245 the packet sequence. This field is detailed further in [RFC3550].
250 first Vorbis packet in the RTP payload. The clock frequency MUST be
305 packet. There are currently three different types of Vorbis
306 payloads. Each packet MUST contain only a single type of Vorbis
307 packet (e.g., you must not aggregate configuration and comment
328 profiles will likely define a practical limit. Typical Vorbis packet
333 fragmentation, the Vorbis data packet size SHOULD be kept
335 the complete RTP packet is smaller than the path MTU.
352 | length | vorbis packet data ..
357 Each Vorbis payload packet starts with a two octet length header,
365 data consists of the packet length followed by the packet data for
368 The Vorbis packet length header is the length of the Vorbis data
372 guidelines set out in [RFC3551], where the oldest Vorbis packet
373 occurs immediately after the RTP packet header. Subsequent Vorbis
406 2.4. Example RTP Packet
429 | length | next vorbis packet data ..
436 Figure 4: Example Raw Vorbis Packet
438 The payload data section of the RTP packet begins with the 24-bit
441 prefixed by the two octets length field. The Packet Type and
467 header packet that gives simple metadata about the stream, but this
494 used to decode a packet. When the Ident field changes, it indicates
504 the packet type bits set to match the Vorbis Data Type. Clients MUST
507 reflect the transmission time of the first data packet for which this
621 set to 0 because the packet bears the full Packed configuration. The
622 number of the packet is set to 1.
636 The following packet definition MUST be used when Configuration is
733 Vorbis Data Type flag set to 2 indicates that the packet contains the
770 Figure 8: Comment Packet
772 The 2-byte length field is necessary since this packet could be
777 Each RTP payload contains either one Vorbis packet fragment or an
781 Any Vorbis data packet that is less than path MTU SHOULD be bundled
787 A fragmented packet has a zero in the last four bits of the payload
792 The RTP payload containing the last fragment of the Vorbis packet
794 sequence for fragmented packet reception, the timestamp field of
795 fragmented packets MUST be the same as the first packet sent, with
809 5.1. Example Fragmented Vorbis Packet
811 Here is an example of a fragmented Vorbis packet split over three RTP
815 Packet 1:
837 Figure 9: Example Fragmented Packet (Packet 1)
862 Packet 2:
884 Figure 10: Example Fragmented Packet (Packet 2)
888 these types of payloads. The maximum packet size SHOULD be no
919 Packet 3:
941 Figure 11: Example Fragmented Packet (Packet 3)
944 to 3 and the packet count remains set to 0. As in the previous
948 5.2. Packet Loss
950 As there is no error correction within the Vorbis stream, packet loss
951 will result in a loss of signal. Packet loss is more of an issue for
955 incomplete packet. If we use the fragmented Vorbis packet example
957 the next RTP payload has the packet count field set to 0 and the
959 final fragmented packet, MUST be dropped in the same manner. If the
961 kept and the incomplete Vorbis packet decoded.
964 the full Configuration packet with the result detailed in the Loss of
1011 Ogg Vorbis I specification: Codec setup and packet decode.
1161 known in advance, the Configuration Packet for each file SHOULD be
1176 configuration packet is inside the SDP; other configurations could be
1249 source as soon as it discovers a Configuration packet got lost in-
1361 packet decode. Available from the Xiph website,
