RFC-7741RTPPayloadFormatforVP8Video(VP8)资源-CSDN文库

需积分: 1 80 浏览量 2023-08-07 10:44:26 上传评论收藏 37KB PDF 举报

资源推荐

资源详情

资源评论

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.

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]

剩余26页未读，继续阅读

评论收藏

内容反馈

毕加索解锁

粉丝: 2139
资源: 24

RFC-7741 RTP Payload Format for VP8 Video (VP8)

最新资源

RFC-7741 RTP Payload Format for VP8 Video (VP8)

RTP Payload Format for Scalable Video Coding

RTP_Payload_Format_for_H.264_Video

RFC-4749 RTP Payload Format for the G.729.1 Audio Codec (G.729)

RFC-3640 RTP Payload Format for Transport of MPEG-4 Elementary S

RFC-2032 RTP Payload Format for H.261 Video Streams (FIR)

RFC-7798 RTP Payload Format for High Efficiency Video Coding

RFC-6184 RTP Payload Format for H.264 Video (H.264)

RFC-7587 RTP Payload Format for the Opus Speech and Audio Codec

RFC-5404 RTP Payload Format for G.719 (G.719)

RFC-7655 RTP Payload Format for G.711.0 (G.711)

RFC3984 RTP Payload Format for H264 Video

RFC 3984 - RTP Payload Format for H_264 Video

RTP Payload Format for H.264 Video

RFC-3550 RTP中英文版

RFC-4585 Extended RTP Profile for RTCP - Based Feedback (RTCP-FB

RFC1889-(RTP)-协议中文概要

RFC-8285 A General Mechanism for RTP Header Extensions

RTP Payload Format for H.264&amp;H.265 Video

RFC-3550 A Transport Protocol for Real-Time Applications (RTP)

RFC-3550-RTP协议-中文版.pdf

RTP发送H265(HEVC) RFC文档

RFC3550-RTP框架 RTCP1

落雪音乐-六音音源 sixyin-music-source-v1.1.0.js

markdown配套文件，使用前先解压

喜马拉雅xm文件解密工具

OCPP协议解析 代码+代码含义详解

最新资源

RTP Payload Format for H.264&H.265 Video

OCPP协议解析代码+代码含义详解