diff options
Diffstat (limited to 'doc/rfc/rfc7741.txt')
| -rw-r--r-- | doc/rfc/rfc7741.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7741.txt b/doc/rfc/rfc7741.txt new file mode 100644 index 0000000..dd247e6 --- /dev/null +++ b/doc/rfc/rfc7741.txt @@ -0,0 +1,1515 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Westin +Request for Comments: 7741 H. Lundin +Category: Standards Track Google +ISSN: 2070-1721 M. Glover + Twitter + J. Uberti + F. Galligan + Google + March 2016 + + + RTP Payload Format for VP8 Video + +Abstract + + This memo describes an RTP payload format for the VP8 video codec. + The payload format has wide applicability, as it supports + applications from low-bitrate peer-to-peer usage to high-bitrate + video conferences. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7741. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Westin, et al. Standards Track [Page 1] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions, Definitions, and Abbreviations .....................3 + 3. Media Format Description ........................................4 + 4. Payload Format ..................................................5 + 4.1. RTP Header Usage ...........................................6 + 4.2. VP8 Payload Descriptor .....................................7 + 4.3. VP8 Payload Header ........................................11 + 4.4. Aggregated and Fragmented Payloads ........................12 + 4.5. Example Algorithms ........................................13 + 4.5.1. Frame Reconstruction Algorithm .....................13 + 4.5.2. Partition Reconstruction Algorithm .................13 + 4.6. Examples of VP8 RTP Stream ................................14 + 4.6.1. Key Frame in a Single RTP Packet ...................14 + 4.6.2. Non-discardable VP8 Interframe in a Single + RTP Packet; No PictureID ...........................14 + 4.6.3. VP8 Partitions in Separate RTP Packets .............15 + 4.6.4. VP8 Frame Fragmented across RTP Packets ............16 + 4.6.5. VP8 Frame with Long PictureID ......................18 + 5. Using VP8 with RPSI and SLI Feedback ...........................18 + 5.1. RPSI ......................................................18 + 5.2. SLI .......................................................19 + 5.3. Example ...................................................19 + 6. Payload Format Parameters ......................................21 + 6.1. Media Type Definition .....................................21 + 6.2. SDP Parameters ............................................23 + 6.2.1. Mapping of Media Subtype Parameters to SDP .........23 + 6.2.2. Offer/Answer Considerations ........................23 + 7. Security Considerations ........................................24 + 8. Congestion Control .............................................24 + 9. IANA Considerations ............................................24 + 10. References ....................................................25 + 10.1. Normative References .....................................25 + 10.2. Informative References ...................................26 + Authors' Addresses ................................................28 + + + + + + + + + + + + + + + +Westin, et al. Standards Track [Page 2] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +1. Introduction + + This memo describes an RTP payload specification applicable to the + transmission of video streams encoded using the VP8 video codec + [RFC6386]. The format described in this document can be used both in + peer-to-peer and video-conferencing applications. + + VP8 is based on the decomposition of frames into square sub-blocks of + pixels known as "macroblocks" (see Section 2 of [RFC6386]). + Prediction of such sub-blocks using previously constructed blocks, + and adjustment of such predictions (as well as synthesis of + unpredicted blocks) is done using a discrete cosine transform + (hereafter abbreviated as DCT). In one special case, however, VP8 + uses a "Walsh-Hadamard" transform (hereafter abbreviated as WHT) + instead of a DCT. An encoded VP8 frame is divided into two or more + partitions, as described in [RFC6386]. The first partition + (prediction or mode) contains prediction mode parameters and motion + vectors for all macroblocks. The remaining partitions all contain + the quantized DCT/WHT coefficients for the residuals. There can be + 1, 2, 4, or 8 DCT/WHT partitions per frame, depending on encoder + settings. + + In summary, the payload format described in this document enables a + number of features in VP8, including: + + o Taking partition boundaries into consideration, to improve loss + robustness and facilitate efficient packet-loss concealment at the + decoder. + + o Temporal scalability. + + o Advanced use of reference frames to enable efficient error + recovery. + + o Marking of frames that have no impact on the decoding of any other + frame, so that these non-reference frames can be discarded in a + server or media-aware network element if needed. + +2. Conventions, Definitions, and Abbreviations + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + + +Westin, et al. Standards Track [Page 3] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + This document uses the definitions of [RFC6386]. In particular, the + following terms are used. + + Key frames: Frames that are decoded without reference to any other + frame in a sequence (also called intraframes and I-frames). + + Interframes: Frames that are encoded with reference to prior frames, + specifically all prior frames up to and including the most recent + key frame (also called prediction frames and P-frames). + + Golden and altref frames: alternate prediction frames. Blocks in an + interframe may be predicted using blocks in the immediately + previous frame as well as the most recent golden frame or altref + frame. Every key frame is automatically golden and altref, and + any interframe may optionally replace the most recent golden or + altref frame. + + Macroblock: a square array of pixels whose Y (luminance) dimensions + are 16x16 pixels and whose U and V (chrominance) dimensions are + 8x8 pixels. + + Two definitions from [RFC4585] are also used in this document. + + RPSI: Reference picture selection indication. A feedback message to + let the encoder know that the decoder has correctly decoded a + certain frame. + + SLI: Slice loss indication. A feedback message to let a decoder + inform an encoder that it has detected the loss or corruption of + one or several macroblocks. + +3. Media Format Description + + The VP8 codec uses three different reference frames for interframe + prediction: the previous frame, the golden frame, and the altref + frame. Blocks in an interframe may be predicted using blocks in the + immediately previous frame as well as the most recent golden frame or + altref frame. Every key frame is automatically golden and altref, + and any interframe may optionally replace the most recent golden or + altref frame. Golden frames and altref frames may also be used to + increase the tolerance to dropped frames. The payload specification + in this memo has elements that enable advanced use of the reference + frames, e.g., for improved loss robustness. + + One specific use case of the three reference frame types is temporal + scalability. By setting up the reference hierarchy in the + appropriate way, up to five temporal layers can be encoded. (How to + set up the reference hierarchy for temporal scalability is not within + + + +Westin, et al. Standards Track [Page 4] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + the scope of this memo.) Support for temporal scalability is + provided by the optional TL0PICIDX and TID/Y/KEYIDX fields described + in Section 4.2. For a general description of temporal scalability + for video coding, see [Sch07]. + + Another property of the VP8 codec is that it applies data + partitioning to the encoded data. Thus, an encoded VP8 frame can be + divided into two or more partitions, as described in "VP8 Data Format + and Decoding Guide" [RFC6386]. The first partition (prediction or + mode) contains prediction mode parameters and motion vectors for all + macroblocks. The remaining partitions all contain the transform + coefficients for the residuals. The first partition is decodable + without the remaining residual partitions. The subsequent partitions + may be useful even if some part of the frame is lost. Accordingly, + this document RECOMMENDS that the frame be packetized by the sender + with each data partition in a separate packet or packets. This may + be beneficial for decoder-side error concealment, and the payload + format described in Section 4 provides fields that allow the + partitions to be identified even if the first partition is not + available. The sender can, alternatively, aggregate the data + partitions into a single data stream and, optionally, split it into + several packets without consideration of the partition boundaries. + The receiver can use the length information in the first partition to + identify the partitions during decoding. + + The format specification is described in Section 4. In Section 5, a + method to acknowledge receipt of reference frames using RTCP + techniques is described. + + The payload partitioning and the acknowledging method both serve as + motivation for three of the fields included in the payload format: + the "PID", "1st partition size", and "PictureID" fields. The ability + to encode a temporally scalable stream motivates the "TL0PICIDX" and + "TID" fields. + +4. Payload Format + + This section describes how the encoded VP8 bitstream is encapsulated + in RTP. To handle network losses, usage of RTP/AVPF [RFC4585] is + RECOMMENDED. All integer fields in the specifications are encoded as + unsigned integers in network octet order. + + + + + + + + + + +Westin, et al. Standards Track [Page 5] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +4.1. RTP Header Usage + + The general RTP payload format for VP8 is depicted below. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P|X| CC |M| PT | sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | timestamp | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronization source (SSRC) identifier | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | contributing source (CSRC) identifiers | + | .... | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | VP8 payload descriptor (integer #octets) | + : : + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | : VP8 payload header (3 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | VP8 pyld hdr : | + +-+-+-+-+-+-+-+-+ | + : Octets 4..N of VP8 payload : + | | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | : OPTIONAL RTP padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The VP8 payload descriptor and VP8 payload header will be described + in Sections 4.2 and 4.3. OPTIONAL RTP padding MUST NOT be included + unless the P bit is set. The figure specifically shows the format + for the first packet in a frame. Subsequent packets will not contain + the VP8 payload header and will have later octets in the frame + payload. + + Figure 1 + + Marker bit (M): MUST be set for the very last packet of each encoded + frame in line with the normal use of the M bit in video formats. + This enables a decoder to finish decoding the picture, where it + otherwise may need to wait for the next packet to explicitly know + that the frame is complete. + + Payload type (PT): The assignment of an RTP payload type for this + packet format is outside the scope of this document and will not + be specified here. + + + + +Westin, et al. Standards Track [Page 6] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + Timestamp: The RTP timestamp indicates the time when the frame was + sampled. The granularity of the clock is 90 kHz, so a delta of 1 + represents 1/90,000 of a second. + + The remaining RTP Fixed Header Fields (V, P, X, CC, sequence + number, SSRC, and CSRC identifiers) are used as specified in + Section 5.1 of [RFC3550]. + +4.2. VP8 Payload Descriptor + + The first octets after the RTP header are the VP8 payload descriptor, + with the following structure. The single-octet version of the + PictureID is illustrated to the left (M bit set to 0), while the + dual-octet version (M bit set to 1) is shown to the right. + + 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + |X|R|N|S|R| PID | (REQUIRED) |X|R|N|S|R| PID | (REQUIRED) + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + X: |I|L|T|K| RSV | (OPTIONAL) X: |I|L|T|K| RSV | (OPTIONAL) + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + I: |M| PictureID | (OPTIONAL) I: |M| PictureID | (OPTIONAL) + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + L: | TL0PICIDX | (OPTIONAL) | PictureID | + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + T/K: |TID|Y| KEYIDX | (OPTIONAL) L: | TL0PICIDX | (OPTIONAL) + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + T/K: |TID|Y| KEYIDX | (OPTIONAL) + +-+-+-+-+-+-+-+-+ + Figure 2 + + X: Extended control bits present. When set to 1, the extension octet + MUST be provided immediately after the mandatory first octet. If + the bit is zero, all optional fields MUST be omitted. Note: this + X bit is not to be confused with the X bit in the RTP header. + + R: Bit reserved for future use. MUST be set to 0 and MUST be ignored + by the receiver. + + N: Non-reference frame. When set to 1, the frame can be discarded + without affecting any other future or past frames. If the + reference status of the frame is unknown, this bit SHOULD be set + to 0 to avoid discarding frames needed for reference. + + Informative note: This document does not describe how to + determine if an encoded frame is non-reference. The reference + status of an encoded frame is preferably provided from the + encoder implementation. + + + +Westin, et al. Standards Track [Page 7] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + S: Start of VP8 partition. SHOULD be set to 1 when the first payload + octet of the RTP packet is the beginning of a new VP8 partition, + and MUST NOT be 1 otherwise. The S bit MUST be set to 1 for the + first packet of each encoded frame. + + PID: Partition index. Denotes to which VP8 partition the first + payload octet of the packet belongs. The first VP8 partition + (containing modes and motion vectors) MUST be labeled with PID = + 0. PID SHOULD be incremented by 1 for each subsequent partition, + but it MAY be kept at 0 for all packets. PID cannot be larger + than 7. If more than one packet in an encoded frame contains the + same PID, the S bit MUST NOT be set for any packet other than the + first packet with that PID. + + When the X bit is set to 1 in the first octet, the Extended Control + Bits field octet MUST be provided as the second octet. If the X bit + is 0, the Extended Control Bits field octet MUST NOT be present, and + no extensions (I, L, T, or K) are permitted. + + I: PictureID present. When set to 1, the PictureID MUST be present + after the extension bit field and specified as below. Otherwise, + PictureID MUST NOT be present. + + L: TL0PICIDX present. When set to 1, the TL0PICIDX MUST be present + and specified as below, and the T bit MUST be set to 1. + Otherwise, TL0PICIDX MUST NOT be present. + + T: TID present. When set to 1, the TID/Y/KEYIDX octet MUST be + present. The TID|Y part of the octet MUST be specified as below. + If K (below) is set to 1 but T is set to 0, the TID/Y/KEYIDX octet + MUST be present, but the TID field MUST be ignored. If neither T + nor K is set to 1, the TID/Y/KEYIDX octet MUST NOT be present. + + K: KEYIDX present. When set to 1, the TID/Y/KEYIDX octet MUST be + present. The KEYIDX part of the octet MUST be specified as below. + If T (above) is set to 1 but K is set to 0, the TID/Y/KEYIDX octet + MUST be present, but the KEYIDX field MUST be ignored. If neither + T nor K is set to 1, the TID/Y/KEYIDX octet MUST NOT be present. + + RSV: Bits reserved for future use. MUST be set to 0 and MUST be + ignored by the receiver. + + + + + + + + + + +Westin, et al. Standards Track [Page 8] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + After the extension bit field follow the extension data fields that + are enabled. + + The PictureID extension: If the I bit is set to 1, the PictureID + extension field MUST be present, and it MUST NOT be present + otherwise. The field consists of two parts: + + M: The most significant bit of the first octet is an extension + flag. If M is set, the remainder of the PictureID field MUST + contain 15 bits, else it MUST contain 7 bits. Note: this M bit + is not to be confused with the M bit in the RTP header. + + PictureID: 7 or 15 bits (shown left and right, respectively, in + Figure 2) not including the M bit. This is a running index of + the frames, which MAY start at a random value, MUST increase by + 1 for each subsequent frame, and MUST wrap to 0 after reaching + the maximum ID (all bits set). The 7 or 15 bits of the + PictureID go from most significant to least significant, + beginning with the first bit after the M bit. The sender + chooses a 7- or 15-bit index and sets the M bit accordingly. + The receiver MUST NOT assume that the number of bits in + PictureID stays the same through the session. Having sent a + 7-bit PictureID with all bits set to 1, the sender may either + wrap the PictureID to 0 or extend to 15 bits and continue + incrementing. + + The TL0PICIDX extension: If the L bit is set to 1, the TL0PICIDX + extension field MUST be present, and it MUST NOT be present + otherwise. The field consists of one part: + + TL0PICIDX: 8 bits temporal level zero index. TL0PICIDX is a + running index for the temporal base layer frames, i.e., the + frames with TID set to 0. If TID is larger than 0, TL0PICIDX + indicates on which base-layer frame the current image depends. + TL0PICIDX MUST be incremented when TID is 0. The index MAY + start at a random value, and it MUST wrap to 0 after reaching + the maximum number 255. Use of TL0PICIDX depends on the + presence of TID. Therefore, it is RECOMMENDED that the TID be + used whenever TL0PICIDX is. + + The TID/Y/KEYIDX extension: If either of the T or K bits are set to + 1, the TID/Y/KEYIDX extension field MUST be present. It MUST NOT + be present if both T and K are zero. The field consists of three + parts: + + TID: 2 bits temporal-layer index. The TID field MUST be ignored + by the receiver when the T bit is set equal to 0. The TID + field indicates which temporal layer the packet represents. + + + +Westin, et al. Standards Track [Page 9] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + The lowest layer, i.e., the base layer, MUST have the TID set + to 0. Higher layers SHOULD increment the TID according to + their position in the layer hierarchy. + + Y: 1 layer sync bit. The Y bit SHOULD be set to 1 if the current + frame depends only on the base layer (TID = 0) frame with + TL0PICIDX equal to that of the current frame. The Y bit MUST + be set to 0 if the current frame depends on any other frame + than the base layer (TID = 0) frame with TL0PICIDX equal to + that of the current frame. Additionally, the Y bit MUST be set + to 0 if any frame following the current frame depends on a non- + base-layer frame older than the base-layer frame with TL0PICIDX + equal to that of the current frame. If the Y bit is set when + the T bit is equal to 0, the current frame MUST only depend on + a past base-layer (TID=0) key frame as signaled by a change in + the KEYIDX field. Additionally, this frame MUST NOT depend on + any of the three codec buffers (as defined by [RFC6386]) that + have been updated since the last time the KEYIDX field was + changed. + + Informative note: This document does not describe how to + determine the dependency status for a frame; this information + is preferably provided from the encoder implementation. In the + case of unknown status, the Y bit can safely be set to 0. + + KEYIDX: 5 bits temporal key frame index. The KEYIDX field MUST + be ignored by the receiver when the K bit is set equal to 0. + The KEYIDX field is a running index for key frames. KEYIDX MAY + start at a random value, and it MUST wrap to 0 after reaching + the maximum number 31. When in use, the KEYIDX SHOULD be + present for both key frames and interframes. The sender MUST + increment KEYIDX for key frames that convey parameter updates + critical to the interpretation of subsequent frames, and it + SHOULD leave the KEYIDX unchanged for key frames that do not + contain these critical updates. If the KEYIDX is present, a + receiver SHOULD NOT decode an interframe if it has not received + and decoded a key frame with the same KEYIDX after the last + KEYIDX wraparound. + + Informative note: This document does not describe how to + determine if a key frame updates critical parameters; this + information is preferably provided from the encoder + implementation. A sender that does not have this information + may either omit the KEYIDX field (set K equal to 0) or + increment the KEYIDX on every key frame. The benefit with the + latter is that any key-frame loss will be detected by the + receiver, which can signal for re-transmission or request a new + key frame. + + + +Westin, et al. Standards Track [Page 10] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + Informative note: Implementations doing splicing of VP8 streams will + have to make sure the rules for incrementing TL0PICIDX and KEYIDX + are obeyed across the splice. This will likely require rewriting + values of TL0PICIDX and KEYIDX after the splice. + +4.3. VP8 Payload Header + + The beginning of an encoded VP8 frame is referred to as an + "uncompressed data chunk" in Section 9.1 of [RFC6386], and it also + serves as a payload header in this RTP format. The codec bitstream + format specifies two different variants of the uncompressed data + chunk: a 3-octet version for interframes and a 10-octet version for + key frames. The first 3 octets are common to both variants. In the + case of a key frame, the remaining 7 octets are considered to be part + of the remaining payload in this RTP format. Note that the header is + present only in packets that have the S bit equal to one and the PID + equal to zero in the payload descriptor. Subsequent packets for the + same frame do not carry the payload header. + + The length of the first partition can always be obtained from the + first partition-size parameter in the VP8 payload header. The VP8 + bitstream format [RFC6386] specifies that if multiple DCT/WHT + partitions are produced, the location of each partition start is + found at the end of the first (prediction or mode) partition. In + this RTP payload specification, the location offsets are considered + to be part of the first partition. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |Size0|H| VER |P| + +-+-+-+-+-+-+-+-+ + | Size1 | + +-+-+-+-+-+-+-+-+ + | Size2 | + +-+-+-+-+-+-+-+-+ + | Octets 4..N of| + | VP8 payload | + : : + +-+-+-+-+-+-+-+-+ + | OPTIONAL RTP | + | padding | + : : + +-+-+-+-+-+-+-+-+ + + Figure 3 + + + + + + +Westin, et al. Standards Track [Page 11] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + A packetizer needs access to the P bit. The other fields are defined + in [RFC6386], Section 9.1, and their meanings do not influence the + packetization process. None of these fields are modified by the + packetization process. + + P: Inverse key frame flag. When set to 0, the current frame is a key + frame. When set to 1, the current frame is an interframe. + Defined in [RFC6386] + +4.4. Aggregated and Fragmented Payloads + + An encoded VP8 frame can be divided into two or more partitions, as + described in Section 1. It is OPTIONAL for a packetizer implementing + this RTP specification to pay attention to the partition boundaries + within an encoded frame. If packetization of a frame is done without + considering the partition boundaries, the PID field MAY be set to 0 + for all packets and the S bit MUST NOT be set to 1 for any other + packet than the first. + + If the preferred usage suggested in Section 3 is followed, with each + packet carrying data from exactly one partition, the S bit and PID + fields described in Section 4.2 SHOULD be used to indicate what the + packet contains. The PID field should indicate to which partition + the first octet of the payload belongs and the S bit indicates that + the packet starts on a new partition. + + If the packetizer does not pay attention to the partition boundaries, + one packet can contain a fragment of a partition, a complete + partition, or an aggregate of fragments and partitions. There is no + explicit signaling of partition boundaries in the payload, and the + partition lengths at the end of the first partition have to be used + to identify the boundaries. Partitions MUST be aggregated in + decoding order. Two fragments from different partitions MAY be + aggregated into the same packet along with one or more complete + partitions. + + In all cases, the payload of a packet MUST contain data from only one + video frame. Consequently, the set of packets carrying the data from + a particular frame will contain exactly one VP8 Payload Header (see + Section 4.3) carried in the first packet of the frame. The last, or + only, packet carrying data for the frame MUST have the M bit set in + the RTP header. + + + + + + + + + +Westin, et al. Standards Track [Page 12] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +4.5. Example Algorithms + +4.5.1. Frame Reconstruction Algorithm + + Example of frame reconstruction algorithm. + + 1: Collect all packets with a given RTP timestamp. + + 2: Go through packets in order, sorted by sequence numbers, if + packets are missing, send NACK as defined in [RFC4585] or decode + with missing partitions, see Section 4.5.2 below. + + 3: A frame is complete if the frame has no missing sequence numbers, + the first packet in the frame contains S=1 with partId=0 and the + last packet in the frame has the marker bit set. + +4.5.2. Partition Reconstruction Algorithm + + Example of partition reconstruction algorithm. The algorithm only + applies for the RECOMMENDED use case with partitions in separate + packets. + + 1: Scan for the start of a new partition; S=1. + + 2: Continue scan to detect end of partition; hence, a new S=1 + (previous packet was the end of the partition) is found or the + marker bit is set. If a loss is detected before the end of the + partition, abandon all packets in this partition and continue the + scan repeating from step 1. + + 3: Store the packets in the complete partition, continue the scan + repeating from step 1 until end of frame is reached. + + 4: Send all complete partitions to the decoder. If no complete + partition is found discard the whole frame. + + + + + + + + + + + + + + + + +Westin, et al. Standards Track [Page 13] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +4.6. Examples of VP8 RTP Stream + + A few examples of how the VP8 RTP payload can be used are included + below. + +4.6.1. Key Frame in a Single RTP Packet + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 1 | + +-+-+-+-+-+-+-+-+ + |1|0|0|1|0|0 0 0| X = 1; S = 1; PID = 0 + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0 0 0 0| I = 1 + +-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 0 1| PictureID = 17 + +-+-+-+-+-+-+-+-+ + |Size0|1| VER |0| P = 0 + +-+-+-+-+-+-+-+-+ + | Size1 | + +-+-+-+-+-+-+-+-+ + | Size2 | + +-+-+-+-+-+-+-+-+ + | VP8 payload | + +-+-+-+-+-+-+-+-+ + +4.6.2. Non-discardable VP8 Interframe in a Single RTP Packet; No + PictureID + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 1 | + +-+-+-+-+-+-+-+-+ + |0|0|0|1|0|0 0 0| X = 0; S = 1; PID = 0 + +-+-+-+-+-+-+-+-+ + |Size0|1| VER |1| P = 1 + +-+-+-+-+-+-+-+-+ + | Size1 | + +-+-+-+-+-+-+-+-+ + | Size2 | + +-+-+-+-+-+-+-+-+ + | VP8 payload | + +-+-+-+-+-+-+-+-+ + + + + + + +Westin, et al. Standards Track [Page 14] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +4.6.3. VP8 Partitions in Separate RTP Packets + + First RTP packet; complete first partition. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 0 | + +-+-+-+-+-+-+-+-+ + |1|0|0|1|0|0 0 0| X = 1; S = 1; PID = 0 + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0 0 0 0| I = 1 + +-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 0 1| PictureID = 17 + +-+-+-+-+-+-+-+-+ + |Size0|1| VER |1| P = 1 + +-+-+-+-+-+-+-+-+ + | Size1 | + +-+-+-+-+-+-+-+-+ + | Size2 | + +-+-+-+-+-+-+-+-+ + | Octets 4..L of| + | first VP8 | + | partition | + : : + +-+-+-+-+-+-+-+-+ + + Second RTP packet; complete second partition. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 1 | + +-+-+-+-+-+-+-+-+ + |1|0|0|1|0|0 0 1| X = 1; S = 1; PID = 1 + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0 0 0 0| I = 1 + +-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 0 1| PictureID = 17 + +-+-+-+-+-+-+-+-+ + | Remaining VP8 | + | partitions | + : : + +-+-+-+-+-+-+-+-+ + + + + + + + +Westin, et al. Standards Track [Page 15] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +4.6.4. VP8 Frame Fragmented across RTP Packets + + First RTP packet; complete first partition. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 0 | + +-+-+-+-+-+-+-+-+ + |1|0|0|1|0|0 0 0| X = 1; S = 1; PID = 0 + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0 0 0 0| I = 1 + +-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 0 1| PictureID = 17 + +-+-+-+-+-+-+-+-+ + |Size0|1| VER |1| P = 1 + +-+-+-+-+-+-+-+-+ + | Size1 | + +-+-+-+-+-+-+-+-+ + | Size2 | + +-+-+-+-+-+-+-+-+ + | Complete | + | first | + | partition | + : : + +-+-+-+-+-+-+-+-+ + + Second RTP packet; first fragment of second partition. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 0 | + +-+-+-+-+-+-+-+-+ + |1|0|0|1|0|0 0 1| X = 1; S = 1; PID = 1 + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0 0 0 0| I = 1 + +-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 0 1| PictureID = 17 + +-+-+-+-+-+-+-+-+ + | First fragment| + | of second | + | partition | + : : + +-+-+-+-+-+-+-+-+ + + + + + + +Westin, et al. Standards Track [Page 16] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + Third RTP packet; second fragment of second partition. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 0 | + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0|0 0 1| X = 1; S = 0; PID = 1 + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0 0 0 0| I = 1 + +-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 0 1| PictureID = 17 + +-+-+-+-+-+-+-+-+ + | Mid fragment | + | of second | + | partition | + : : + +-+-+-+-+-+-+-+-+ + + Fourth RTP packet; last fragment of second partition. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 1 | + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0|0 0 1| X = 1; S = 0; PID = 1 + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0 0 0 0| I = 1 + +-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 0 1| PictureID = 17 + +-+-+-+-+-+-+-+-+ + | Last fragment | + | of second | + | partition | + : : + +-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + +Westin, et al. Standards Track [Page 17] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +4.6.5. VP8 Frame with Long PictureID + + PictureID = 4711 = 001001001100111 binary (first 7 bits: 0010010, + last 8 bits: 01100111). + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | RTP header | + | M = 1 | + +-+-+-+-+-+-+-+-+ + |1|0|0|1|0|0 0 0| X = 1; S = 1; PID = 0 + +-+-+-+-+-+-+-+-+ + |1|0|0|0|0 0 0 0| I = 1; + +-+-+-+-+-+-+-+-+ + |1 0 0 1 0 0 1 0| Long PictureID flag = 1 + |0 1 1 0 0 1 1 1| PictureID = 4711 + +-+-+-+-+-+-+-+-+ + |Size0|1| VER |1| + +-+-+-+-+-+-+-+-+ + | Size1 | + +-+-+-+-+-+-+-+-+ + | Size2 | + +-+-+-+-+-+-+-+-+ + | Octets 4..N of| + | VP8 payload | + : : + +-+-+-+-+-+-+-+-+ + +5. Using VP8 with RPSI and SLI Feedback + + The VP8 payload descriptor defined in Section 4.2 contains an + optional PictureID parameter. This parameter is included mainly to + enable use of reference picture selection indication (RPSI) and slice + loss indication (SLI), both defined in [RFC4585]. + +5.1. RPSI + + The RPSI is a payload-specific feedback message defined within the + RTCP-based feedback format. The RPSI message is generated by a + receiver and can be used in two ways. Either it can signal a + preferred reference picture when a loss has been detected by the + decoder -- preferably then a reference that the decoder knows is + perfect -- or it can be used as positive feedback information to + acknowledge correct decoding of certain reference pictures. The + positive-feedback method is useful for VP8 used for point-to-point + (unicast) communication. The use of RPSI for VP8 is preferably + combined with a special update pattern of the codec's two special + reference frames -- the golden frame and the altref frame -- in which + + + +Westin, et al. Standards Track [Page 18] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + they are updated in an alternating leapfrog fashion. When a receiver + has received and correctly decoded a golden or altref frame, and that + frame has a PictureID in the payload descriptor, the receiver can + acknowledge this simply by sending an RPSI message back to the + sender. The message body (i.e., the "native RPSI bit string" in + [RFC4585]) is simply the PictureID of the received frame. + +5.2. SLI + + The SLI is another payload-specific feedback message defined within + the RTCP-based feedback format. The SLI message is generated by the + receiver when a loss or corruption is detected in a frame. The + format of the SLI message is as follows [RFC4585]: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | First | Number | PictureID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4 + + Here, First is the macroblock address (in scan order) of the first + lost block and Number is the number of lost blocks, as defined in + [RFC4585]. PictureID is the six least significant bits of the codec- + specific picture identifier in which the loss or corruption has + occurred. For VP8, this codec-specific identifier is naturally the + PictureID of the current frame, as read from the payload descriptor. + If the payload descriptor of the current frame does not have a + PictureID, the receiver MAY send the last received PictureID+1 in the + SLI message. The receiver MAY set the First parameter to 0, and the + Number parameter to the total number of macroblocks per frame, even + though only part of the frame is corrupted. When the sender receives + an SLI message, it can make use of the knowledge from the latest + received RPSI message. Knowing that the last golden or altref frame + was successfully received, it can encode the next frame with + reference to that established reference. + +5.3. Example + + The use of RPSI and SLI is best illustrated in an example. In this + example, the encoder may not update the altref frame until the last + sent golden frame has been acknowledged with an RPSI message. If an + update is not received within some time, a new golden frame update is + sent instead. Once the new golden frame is established and + acknowledged, the same rule applies when updating the altref frame. + + + + + +Westin, et al. Standards Track [Page 19] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + +-------+-------------------+-------------------------+-------------+ + | Event | Sender | Receiver | Established | + | | | | reference | + +-------+-------------------+-------------------------+-------------+ + | 1000 | Send golden frame | | | + | | PictureID = 0 | | | + | | | | | + | | | Receive and decode | | + | | | golden frame | | + | | | | | + | 1001 | | Send RPSI(0) | | + | | | | | + | 1002 | Receive RPSI(0) | | golden | + | | | | | + | ... | (sending regular | | | + | | frames) | | | + | | | | | + | 1100 | Send altref frame | | | + | | PictureID = 100 | | | + | | | | | + | | | Altref corrupted or | golden | + | | | lost | | + | | | | | + | 1101 | | Send SLI(100) | golden | + | | | | | + | 1102 | Receive SLI(100) | | | + | | | | | + | 1103 | Send frame with | | | + | | reference to | | | + | | golden | | | + | | | | | + | | | Receive and decode | golden | + | | | frame (decoder state | | + | | | restored) | | + | | | | | + | ... | (sending regular | | | + | | frames) | | | + | | | | | + | 1200 | Send altref frame | | | + | | PictureID = 200 | | | + | | | | | + | | | Receive and decode | golden | + | | | altref frame | | + | | | | | + | 1201 | | Send RPSI(200) | | + | | | | | + | 1202 | Receive RPSI(200) | | altref | + | | | | | + + + +Westin, et al. Standards Track [Page 20] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + | ... | (sending regular | | | + | | frames) | | | + | | | | | + | 1300 | Send golden frame | | | + | | PictureID = 300 | | | + | | | | | + | | | Receive and decode | altref | + | | | golden frame | | + | | | | | + | 1301 | | Send RPSI(300) | altref | + | | | | | + | 1302 | RPSI lost | | | + | | | | | + | 1400 | Send golden frame | | | + | | PictureID = 400 | | | + | | | | | + | | | Receive and decode | altref | + | | | golden frame | | + | | | | | + | 1401 | | Send RPSI(400) | | + | | | | | + | 1402 | Receive RPSI(400) | | golden | + +-------+-------------------+-------------------------+-------------+ + + Table 1: Example Signaling between Sender and Receiver + + Note that the scheme is robust to loss of the feedback messages. If + the RPSI is lost, the sender will try to update the golden (or + altref) again after a while, without releasing the established + reference. Also, if an SLI is lost, the receiver can keep sending + SLI messages at any interval allowed by the RTCP sending timing + restrictions as specified in [RFC4585], as long as the picture is + corrupted. + +6. Payload Format Parameters + + This payload format has two optional parameters. + +6.1. Media Type Definition + + This registration is done using the template defined in [RFC6838] and + following [RFC4855]. + + Type name: video + + Subtype name: VP8 + + Required parameters: None. + + + +Westin, et al. Standards Track [Page 21] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + Optional parameters: + + These parameters are used to signal the capabilities of a receiver + implementation. If the implementation is willing to receive + media, both parameters MUST be provided. These parameters MUST + NOT be used for any other purpose. + + max-fr: The value of max-fr is an integer indicating the maximum + frame rate in units of frames per second that the decoder is + capable of decoding. + + max-fs: The value of max-fs is an integer indicating the maximum + frame size in units of macroblocks that the decoder is capable + of decoding. + + The decoder is capable of decoding this frame size as long as + the width and height of the frame in macroblocks are less than + int(sqrt(max-fs * 8)). For instance, a max-fs of 1200 (capable + of supporting 640x480 resolution) will support widths and + heights up to 1552 pixels (97 macroblocks). + + Encoding considerations: + This media type is framed in RTP and contains binary data; see + Section 4.8 of [RFC6838]. + + Security considerations: See Section 7 of RFC 7741. + + Interoperability considerations: None. + + Published specification: VP8 bitstream format [RFC6386] and RFC + 7741. + + Applications that use this media type: + For example: Video over IP, video conferencing. + + Fragment identifier considerations: N/A. + + Additional information: None. + + Person & email address to contact for further information: + Patrik Westin, patrik.westin@gmail.com + + Intended usage: COMMON + + Restrictions on usage: + This media type depends on RTP framing, and hence it is only + defined for transfer via RTP [RFC3550]. + + + + +Westin, et al. Standards Track [Page 22] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + + Author: Patrik Westin, patrik.westin@gmail.com + + Change controller: + IETF Payload Working Group delegated from the IESG. + +6.2. SDP Parameters + + The receiver MUST ignore any fmtp parameter unspecified in this memo. + +6.2.1. Mapping of Media Subtype Parameters to SDP + + The media type video/VP8 string is mapped to fields in the Session + Description Protocol (SDP) [RFC4566] as follows: + + o The media name in the "m=" line of SDP MUST be video. + + o The encoding name in the "a=rtpmap" line of SDP MUST be VP8 (the + media subtype). + + o The clock rate in the "a=rtpmap" line MUST be 90000. + + o The parameters "max-fs" and "max-fr" MUST be included in the + "a=fmtp" line if the SDP is used to declare receiver capabilities. + These parameters are expressed as a media subtype string, in the + form of a semicolon-separated list of parameter=value pairs. + +6.2.1.1. Example + + An example of media representation in SDP is as follows: + + m=video 49170 RTP/AVPF 98 + a=rtpmap:98 VP8/90000 + a=fmtp:98 max-fr=30; max-fs=3600; + +6.2.2. Offer/Answer Considerations + + The VP8 codec offers a decode complexity that is roughly linear with + the number of pixels encoded. The parameters "max-fr" and "max-fs" + are defined in Section 6.1, where the macroblock size is 16x16 pixels + as defined in [RFC6386], the max-fs and max-fr parameters MUST be + used to establish these limits. + + + + + + + + + + +Westin, et al. Standards Track [Page 23] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +7. Security Considerations + + RTP packets using the payload format defined in this specification + are subject to the security considerations discussed in the RTP + specification [RFC3550], and in any applicable RTP profile such as + RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ + SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: + Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] + discusses, it is not an RTP payload format's responsibility to + discuss or mandate what solutions are used to meet the basic security + goals like confidentiality, integrity, and source authenticity for + RTP in general. This responsibility lays on anyone using RTP in an + application. They can find guidance on available security mechanisms + and important considerations in "Options for Securing RTP Sessions" + [RFC7201]. Applications SHOULD use one or more appropriate strong + security mechanisms. The rest of this security consideration section + discusses the security impacting properties of the payload format + itself. + + This RTP payload format and its media decoder do not exhibit any + significant difference in the receiver-side computational complexity + for packet processing and, thus, are unlikely to pose a denial-of- + service threat due to the receipt of pathological data. Nor does the + RTP payload format contain any active content. + +8. Congestion Control + + Congestion control for RTP SHALL be used in accordance with RFC 3550 + [RFC3550] and with any applicable RTP profile; e.g., RFC 3551 + [RFC3551]. The congestion control mechanism can, in a real-time + encoding scenario, adapt the transmission rate by instructing the + encoder to encode at a certain target rate. Media-aware network + elements MAY use the information in the VP8 payload descriptor in + Section 4.2 to identify non-reference frames and discard them in + order to reduce network congestion. Note that discarding of non- + reference frames cannot be done if the stream is encrypted (because + the non-reference marker is encrypted). + +9. IANA Considerations + + The IANA has registered a media type as described in Section 6.1. + + + + + + + + + + +Westin, et al. Standards Track [Page 24] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <http://www.rfc-editor.org/info/rfc3550>. + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and + Video Conferences with Minimal Control", STD 65, RFC 3551, + DOI 10.17487/RFC3551, July 2003, + <http://www.rfc-editor.org/info/rfc3551>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <http://www.rfc-editor.org/info/rfc4566>. + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, + DOI 10.17487/RFC4585, July 2006, + <http://www.rfc-editor.org/info/rfc4585>. + + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, + <http://www.rfc-editor.org/info/rfc4855>. + + [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., + Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding + Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, + <http://www.rfc-editor.org/info/rfc6386>. + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + <http://www.rfc-editor.org/info/rfc6838>. + + + + + + + + + +Westin, et al. Standards Track [Page 25] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +10.2. Informative References + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + <http://www.rfc-editor.org/info/rfc3711>. + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for + Real-time Transport Control Protocol (RTCP)-Based Feedback + (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February + 2008, <http://www.rfc-editor.org/info/rfc5124>. + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + <http://www.rfc-editor.org/info/rfc7201>. + + [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP + Framework: Why RTP Does Not Mandate a Single Media + Security Solution", RFC 7202, DOI 10.17487/RFC7202, April + 2014, <http://www.rfc-editor.org/info/rfc7202>. + + [Sch07] Schwarz, H., Marpe, D., and T. Wiegand, "Overview of the + Scalable Video Coding Extension of the H.264/AVC + Standard", IEEE Transactions on Circuits and Systems for + Video Technology, Volume 17: Issue 9, + DOI 10.1109/TCSVT.2007.905532, September 2007, + <http://dx.doi.org/10.1109/TCSVT.2007.905532>. + + + + + + + + + + + + + + + + + + + + + + + + +Westin, et al. Standards Track [Page 26] + +RFC 7741 RTP Payload Format for VP8 March 2016 + + +Authors' Addresses + + Patrik Westin + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States + + Email: patrik.westin@gmail.com + + + Henrik F Lundin + Google, Inc. + Kungsbron 2 + Stockholm 11122 + Sweden + + Email: hlundin@google.com + + + Michael Glover + Twitter Boston + 10 Hemlock Way + Durham, NH 03824 + United States + + Email: michaelglover262@gmail.com + + + Justin Uberti + Google, Inc. + 747 6th Street South + Kirkland, WA 98033 + United States + + Email: justin@uberti.name + + + Frank Galligan + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States + + Email: fgalligan@google.com + + + + + + +Westin, et al. Standards Track [Page 27] + |