HEVC RTP打包详解：NAL单元封装策略

需积分: 34 169 浏览量更新于2024-07-21 收藏 161KB PDF 举报

本资源主要探讨了HEVC（High Efficiency Video Coding）码流在RTP（Real-Time Transport Protocol）中的打包策略。HEVC是一种高效的视频编码标准，其编解码器能够提供比H.264更高的压缩效率，适用于各种网络传输环境。RTP是网络上实时数据传输的标准协议，用于诸如音频、视频等多媒体通信。该文档由NetworkWorkingGroup的T.Schierl等人共同编写，来自Fraunhofer HHU、Vidyo、Qualcomm、Nokia和Fraunhofer HHI的专家参与，旨在为HEVC视频编码的RTP封装提供详细的指导。文档标题"RTPPayloadFormatforHighEfficiencyVideoCoding"表明了其核心内容：设计一个适配HEVC的RTP负载格式，确保在实际网络传输过程中，视频数据能够被正确地分包和解包，同时考虑到实时性和带宽效率。文章指出，这份草案处于"Standardstrack"阶段，即已经进入标准化流程，但可能在六个月内根据需要更新或被其他文档替代，因此不宜作为最终参考材料引用。读者可以在指定的IETF网站上查看当前互联网草案列表和阴影目录，以获取最新的更新信息。文章详细介绍了如何对HEVC的NAL（Non-Access Unit）单元进行打包，NAL单元是HEVC编码的基本单位，包含了视频编码的所有信息。打包过程涉及到数据拆分、序列号管理、时间戳分配以及RTP头部的设置，这些都是为了保证视频帧的正确顺序和同步播放。此外，文档还关注了如何处理HEVC特有的码率适应、帧率变化、自适应码率控制等特性，并考虑了网络丢包、延时等问题，以确保视频质量在有限的网络条件下依然能得到良好呈现。总结来说，这份文档为开发基于HEVC的实时视频应用提供了一套关键的技术指南，对于从事视频编码、传输和网络优化的工程师具有很高的实用价值。

Internet-Draft RTP Payload Format for HEVC June 11, 2013

a picture, consisting of all reference pictures that are prior to

the associated picture in decoding order, that may be used for inter

prediction of the associated picture or any picture following the

associated picture in decoding order. The reference picture set

consists of five lists of reference pictures; RefPicSetStCurrBefore,

RefPicSetStCurrAfter, RefPicSetStFoll, RefPicSetLtCurr and

RefPicSetLtFoll. RefPicSetStCurrBefore, RefPicSetStCurrAfter and

RefPicSetLtCurr contains all reference pictures that may be used in

inter prediction of the current picture and that may be used in

inter prediction of one or more of the pictures following the

current picture in decoding order. RefPicSetStFoll and

RefPicSetLtFoll consists of all reference pictures that are not used

in inter prediction of the current picture but may be used in inter

prediction of one or more of the pictures following the current

picture in decoding order. RPS provides an "intra-coded" signaling

of the DPB status, instead of an "inter-coded" signaling, mainly for

improved error resilience. The RPLC process in HEVC is based on the

RPS, by signaling an index to an RPS subset for each reference

index. The RPLC process has been simplified compared to that in

H.264, by removal of the reference picture list modification (also

referred to as reference picture list reordering) process.

Ultra low delay support

HEVC specifies a sub-picture-level HRD operation, for support of the

so-called ultra-low delay. The mechanism specifies a standard-

compliant way to enable delay reduction below one picture interval.

Sub-picture-level coded picture buffer (CPB) and DPB parameters may

be signaled, and utilization of these information for the derivation

of CPB timing (wherein the CPB removal time corresponds to decoding

time) and DPB output timing (display time) is specified. Decoders

are allowed to operate the HRD at the conventional access-unit-

level, even when the sub-picture-level HRD parameters are present.

New SEI messages

HEVC inherits many H.264 SEI messages with changes in syntax and/or

semantics making them applicable to HEVC. The active parameter sets

SEI message includes the IDs of the active video parameter set and

the active sequence parameter set and can be used to activate VPSs

and SPSs. In addition, the SEI message includes the following

Schierl, et al Expires December 11, 2013 [Page 12]

Internet-Draft RTP Payload Format for HEVC June 11, 2013

indications: 1) An indication of whether "full random accessibility"

is supported (when supported, all parameter sets needed for decoding

of the remaining of the bitstream when random accessing from the

beginning of the current coded video sequence by completely

discarding all access units earlier in decoding order are present in

the remaining bitstream and all coded pictures in the remaining

bitstream can be correctly decoded); 2) An indication of whether

there is any parameter set within the current coded video sequence

that updates another parameter set of the same type preceding in

decoding order. An update of a parameter set refers to the use of

the same parameter set ID but with some other parameters changed.

If this property is true for all coded video sequences in the

bitstream, then all parameter sets can be sent out-of-band before

session start. The region refresh information SEI message can be

used together with the recovery point SEI message (present in both

H.264 and HEVC) for improved support of gradual decoding refresh

(GDR). This supports random access from inter-coded pictures,

wherein complete pictures can be correctly decoded or recovered

after an indicated number of pictures in output/display order.

1.1.3 Parallel Processing Support

The reportedly significantly higher computational demand of HEVC

over H.264 (especially with respect to encoders, where a complexity

increase of a factor of ten has often been reported), in conjunction

with the ever increasing video resolution (both spatially and

temporally) required by the market, led to the adoption of VCL

coding tools specifically targeted to allow for parallelization on

the sub-picture level. That is, parallelization occurs, at the

minimum, at the granularity of an integer number of CTUs. The

targets for this type of high-level parallelization are multicore

CPUs and DSPs as well as multiprocessor systems. In a system

design, to be useful, these tools require signaling support, which

is provided in

Section 7 of this memo. This section provides a

brief overview of the tools available in [

HEVC].

Many of the tools incorporated in HEVC were designed keeping in mind

the potential parallel implementations in multi-core/multi-processor

architectures. Specifically, for parallelization, four picture

partition strategies are available.

Schierl, et al Expires December 11, 2013 [Page 13]

Internet-Draft RTP Payload Format for HEVC June 11, 2013

Slices are segments of the bitstream that can be reconstructed

independently from other slices within the same picture (though

there may still be interdependencies through loop filtering

operations). Slices are the only tool that can be used for

parallelization that is also available, in virtually identical form,

in H.264. Slices based parallelization does not require much inter-

processor or inter-core communication (except for inter-processor or

inter-core data sharing for motion compensation when decoding a

predictively coded picture, which is typically much heavier than

inter-processor or inter-core data sharing due to in-picture

prediction), as slices are designed to be independently decodable.

However, for the same reason, slices can require some coding

overhead. Further, slices (in contrast to some of the other tools

mentioned below) also serve as the key mechanism for bitstream

partitioning to match Maximum Transfer Unit (MTU) size requirements,

due to the in-picture independence of slices and the fact that each

regular slice is encapsulated in its own NAL unit. In many cases,

the goal of parallelization and the goal of MTU size matching can

place contradicting demands to the slice layout in a picture. The

realization of this situation led to the development of the more

advanced tools mentioned below. This payload format does not

contain any specific mechanisms aiding parallelization through

slices.

Dependent slice segments allow for fragmentation of a coded slice

into fragments at CTU boundaries without breaking any in-picture

prediction mechanism. They are complementary to the fragmentation

mechanism described in this memo in that they need the cooperation

of the encoder. As a dependent slice segment necessarily contains

an integer number of CTUs, a decoder using multiple cores operating

on CTUs can process a dependent slice segment without communicating

parts of the slice segment’s bitstream to other cores.

Fragmentation, as specified in this memo, in contrast, does not

guarantee that a fragment contains an integer number of CTUs.

In wavefront parallel processing (WPP), the picture is partitioned

into rows of CTUs. Entropy decoding and prediction are allowed to

use data from CTUs in other partitions. Parallel processing is

possible through parallel decoding of CTU rows, where the start of

the decoding of a row is delayed by two CTUs, so to ensure that data

related to a CTU above and to the right of the subject CTU is

Schierl, et al Expires December 11, 2013 [Page 14]

剩余68页未读，继续阅读

learner_hevc

粉丝: 1
资源: 1

HEVC RTP打包详解：NAL单元封装策略

HEVC码流的RTP打包

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

从网络抓包中提取RTP包，RTP解包为HEVC/H265裸流

RTP_HEVC_HEADERS_SIZE

h264和h265封装rtp的区别

elecard hevc analyzer .rar

H265初始化RTP头

hevc视频扩展 免费

h265的rtp_payload_size是怎么设置的 也是RTP_MAX_PKT_SIZE - RTP_HEADER_SIZE么

hevc-scc测试序列

最新资源

hevc视频扩展免费

h265的rtp_payload_size是怎么设置的也是RTP_MAX_PKT_SIZE - RTP_HEADER_SIZE么