RTP协议全解(H264码流和PS流)-2015-4-22
RTP协议分析
RTP协议分析协议名称：RTP协议分析一、引言RTP（Real-time Transport Protocol）是一种用于实时传输音频和视频数据的协议。
该协议提供了一种标准化的方式，用于在多媒体应用程序之间传输实时数据。
本协议旨在分析RTP协议的基本原理、功能和特点，并提供相应的标准格式。
二、协议概述RTP协议是一个基于UDP的传输协议，用于在互联网上传输实时数据。
它提供了一种可靠的、实时的数据传输机制，适用于音频、视频和其他多媒体数据的传输。
RTP协议通过将数据分割成小的数据包（称为RTP包）并添加头部信息来实现数据的传输和同步。
三、协议结构1. RTP包头部RTP包头部包含以下字段：- 版本（V）：标识RTP协议的版本号。
- 填充（P）：指示是否在RTP包的末尾添加了额外的填充字节。
- 扩展（X）：指示是否在RTP包中包含了扩展头部。
- CSRC计数（CC）：指示后续包头中CSRC标识符的数量。
- 标记（M）：用于指示RTP包是否为一个帧的最后一个包。
- 负载类型（PT）：指示RTP包中负载的类型，例如音频或视频。
- 序列号（Sequence Number）：用于标识RTP包的顺序。
- 时间戳（Timestamp）：提供了RTP包中数据的时间信息。
- 同步源（SSRC）：用于唯一标识RTP流的源。
- CSRC列表（CSRC List）：包含了参与混合的媒体流的CSRC标识符的列表。
2. RTP包负载RTP包的负载部分包含了实时传输的音频、视频或其他多媒体数据。
四、协议功能1. 实时传输RTP协议提供了实时传输数据的功能，适用于音频和视频等多媒体数据的传输。
它通过将数据分割成小的数据包，并在每个包中添加时间戳信息，以确保接收方可以按照正确的顺序和时间重建数据。
2. 数据同步RTP协议通过使用时间戳字段来实现数据的同步。
接收方可以根据时间戳信息将多个数据包按照正确的顺序进行播放，从而实现音视频的同步。
流媒体技术 RTP协议分析及H.264视频传输
翻译器和混合器
1. RTP概述
1.1 RTP是什么 1.2 RTP的应用环境 1.3 相关概念
1.3 相关概念
在发送端，为降低延迟，往往对传输数据进行预处理（降低质量 和高效压缩）；
1
A
8000
1
A
8000
1
A
8000
1
A
16000
1
A
8000
1
A
8000
1
A
8000
1
A
44100
2
载荷类型（PT）
PT
26
31 32 33 34 35-71 72-76 77-95 96-127
Encoding Name
Audio/Video (A/V)
Clock Rate (Hz)
……
JPEG
2.3 RTCP的封装
RTCP为RTP提供服务质量保证。主要功能是：服务质量的监 视与反馈、媒体间的同步，以及多播组中成员的标识。
RTCP包中含有已发送的数据包的数量、丢失的数据包的数量 等统计资料。
也是用UDP来提供传送。
RTCP封装的仅仅是一些控 制信息，因而分组很短， 所以可以将多个RTCP分组 封装在一个UDP包中。
RTP协议分析及H.264视频传输
主要内容
1 RTP概述 2 RTP详细分析 3 H.264 4 H.264 流媒体传输系统的实现
1. RTP概述
1.1 RTP是什么 1.2 RTP的应用环境 1.3 相关概念
RTP协议详解实时传输协议的音视频数据传输机制
RTP协议详解实时传输协议的音视频数据传输机制实时传输协议(RTP)是一种专门用于音视频数据传输的协议。
它通过提供时间戳、序列号和同步源等机制，以确保音视频数据能够实时、有序、可靠地传输。
本文将详细讲解RTP协议的音视频数据传输机制。
一、RTP协议概述RTP协议是由IETF(Internet Engineering Task Force)制定的，在音视频通信领域得到了广泛应用。
它通过在音视频数据上附加头信息的方式，实现对数据的分组、传输和重组。
二、RTP报文结构RTP报文采用二进制的格式进行传输，一般由固定长度的头部和可变长度的有效载荷组成。
头部包含了报文的一些关键信息，如版本号、序列号、时间戳等，而有效载荷部分则存放着音视频数据。
三、RTP序列号与时间戳1. 序列号：RTP序列号是一个16位的无符号整数，用于标识RTP报文的顺序。
发送者在每发送一个RTP报文时，将序列号递增1并附加在报文头部，接收者通过对序列号进行排序，可以还原出音视频数据的正确顺序。
2. 时间戳：RTP时间戳用于标识音视频数据的播放时间，以毫秒为单位。
发送者在每发送一个RTP报文时，会将当前时间戳附加在报文头部，接收者可以根据时间戳信息对音视频数据进行同步。
四、RTP同步源(SSRC)RTP同步源标识了一路音视频数据的来源，它是一个32位的无符号整数。
通过SSRC，接收者可以确定音视频数据所属的流，并将不同流的数据进行分离与重组。
五、RTP报文传输流程RTP协议的音视频数据传输可以简要分为以下几个步骤：1. 数据封装：发送端将音视频数据打包成RTP报文，包括头部和有效载荷两部分。
2. 报文传输：发送端通过UDP(User Datagram Protocol)将RTP报文传输给接收端。
3. 报文接收：接收端通过UDP接收RTP报文，并对数据进行解析，提取出音视频数据和报文头部的各项信息。
4. 数据解封：接收端根据解析得到的信息，将收到的RTP报文解封得到音视频数据。
RTP协议分析
RTP协议分析协议名称：实时传输协议（RTP）分析协议一、背景介绍实时传输协议（RTP）是一种用于在互联网上传输音频、视频和其他实时数据的协议。
它是由IETF（互联网工程任务组）制定的，并且被广泛应用于音视频通信、流媒体和实时数据传输领域。
本协议旨在对RTP协议进行分析，以便更好地理解其工作原理、性能特点和应用场景。
二、协议分析1. 协议定义RTP协议定义了一种标准的数据包格式，用于在互联网上传输实时数据。
它包括头部和有效载荷两部分。
头部包含了一些必要的信息，如版本号、序列号、时间戳等，用于数据包的重组和同步。
有效载荷部分则用于携带实际的音视频数据。
2. 协议特点RTP协议具有以下特点：- 实时性：RTP协议被设计用于传输实时数据，如音频和视频。
它采用UDP协议作为传输层协议，以提供较低的延迟和更好的实时性能。
- 可扩展性：RTP协议支持扩展头部，可以根据具体的应用需求添加自定义的扩展字段。
这使得RTP协议适用于各种不同的应用场景。
- 容错性：RTP协议支持重传和抗丢包机制，以提高数据传输的可靠性。
同时，它还支持前向纠错技术，可以在一定程度上修复数据包的丢失和损坏。
3. 协议应用RTP协议广泛应用于以下领域：- 音视频通信：RTP协议被用于实现音频和视频的实时传输，如VoIP（网络电话）、视频会议等。
- 流媒体：RTP协议是流媒体传输的基础，通过将音视频数据打包成RTP数据包进行传输，实现了高效的流媒体传输。
- 实时数据传输：RTP协议也可以用于传输其他实时数据，如传感器数据、实时游戏数据等。
4. 协议性能分析为了评估RTP协议的性能，可以从以下几个方面进行分析：- 延迟：RTP协议采用UDP传输，相比于TCP，具有较低的传输延迟。
但是，由于网络的不确定性，RTP协议仍然可能面临一定的延迟问题。
可以通过测量数据包的传输时间来评估延迟性能。
- 丢包率：RTP协议支持重传和抗丢包机制，但是在网络条件较差的情况下，仍然可能发生数据包丢失的情况。
RTP协议实时传输协议解析
RTP协议实时传输协议解析RTP协议（Real-time Transport Protocol）是一种用于在计算机网络中实时传输音频和视频数据的协议。
它提供了传输数据包的机制以及解决拥塞控制和时钟同步等问题的方法。
本文将对RTP协议的结构、特点和工作原理进行详细解析。
一、RTP协议的结构RTP协议由报头和有效载荷组成。
报头包含了版本、负载类型、时间戳等信息，而有效载荷则用于携带音频、视频等实时数据。
1. 报头（Header）RTP报头由12个字节组成，包括以下字段：- 版本（Version）：占2位，用于指定RTP协议的版本号。
- 填充位（Padding）：占1位，用于指示报头末尾是否有额外的填充字节。
- 扩展位（Extension）：占1位，用于指示是否存在扩展报头。
- CSRC计数（CSRC Count）：占4位，用于指示报头后面跟随的CSRC标识符（Contributing Sources）的数量。
- 标志位（Marker）：占1位，用于标示有效载荷的特殊条件。
- 负载类型（Payload Type）：占7位，用于标识有效载荷的编码格式。
- 序列号（Sequence Number）：占16位，用于指示报文的顺序。
- 时间戳（Timestamp）：占32位，用于指示接收端播放音频或视频的时钟信息。
- 同步源（Synchronization Source）：占32位，用于唯一标识一个同步源。
- CSRC列表（CSRC List）：包含0个或多个32位的CSRC标识符。
2. 有效载荷（Payload）RTP协议的有效载荷用于传输实时的音频、视频或其他实时数据。
有效载荷的具体格式和编码方式根据不同的应用而不同。
二、RTP协议的特点RTP协议具有以下几个特点，使其适用于实时传输应用：1. 无连接性：RTP协议在传输过程中不建立连接，这样可以降低传输时延。
2. 实时性：RTP协议被设计用于传输实时数据，提供了时间戳和时钟同步机制，确保数据的及时传输和正确播放。
RTP的H.264视频传输技术的探究
RTP的H.264视频传输技术的探究随着高清视频和网络直播的普及，视频传输技术也在不断发展和完善。
RTP的H.264视频传输技术成为了当今常用的一种视频传输技术。
本文将从RTP的概念和H.264视频编码标准入手，探究RTP的H.264视频传输技术的原理、优势和应用。
一、 RTP的概念RTP（Real-time Transport Protocol）是一种应用层协议，用于实时传输音频和视频数据。
它具有数据报传输、实时性要求、传输速度要求和相对较弱的可靠性的特点。
RTP 通常和RTCP（Real-time Control Protocol）一起使用，RTCP用于实时的控制和反馈信息，确保数据传输的质量和稳定性。
二、 H.264视频编码标准H.264是由国际电信联盟（ITU）和国际标准化组织（ISO）联合制定的高级视频编码标准，也被称为MPEG-4 Part 10或AVC（Advanced Video Coding）。
H.264采用了先进的压缩技术，在保证高清画质的前提下，大大减小了视频文件的体积，使得视频传输更加高效和经济合算。
H.264编码标准主要包含了帧内预测、帧间预测、变换和量化、熵编码等技术。
三、 RTP的H.264视频传输原理RTP的H.264视频传输基本原理是将H.264编码的音视频数据打包成RTP数据包，并通过网络传输到接收端，接收端再将RTP数据包还原成音视频数据进行解码播放。
具体的步骤包括：1.音视频数据编码：将音频和视频信号通过H.264编码标准进行压缩编码，生成压缩后的数据流。
2.RTP数据包封装：将压缩后的音视频数据流进行RTP数据包的封装，包括RTP头部和压缩后的音视频数据。
3.RTP数据包传输：通过网络传输RTP数据包到接收端。
4.RTP数据包解封装：接收端接收到RTP数据包后，将其进行解封装，得到压缩后的音视频数据。
5.音视频数据解码：通过H.264解码器进行解码，得到原始音频和视频信号。
RTP协议分析
RTP协议分析协议名称：RTP协议分析一、背景介绍RTP（Real-time Transport Protocol）是一种用于实时传输音视频数据的协议。
它被广泛应用于互联网电话、视频会议、流媒体等领域。
RTP协议的设计目标是提供实时传输的低延迟、高带宽利用率和可扩展性。
二、协议目标RTP协议的主要目标是提供以下功能：1. 实时传输：RTP协议能够将音视频数据以实时方式传输，保证传输的即时性。
2. 数据分包：RTP协议将音视频数据分成多个小包进行传输，以便在传输过程中能够更好地应对丢包和网络拥塞等问题。
3. 时序和时间戳：RTP协议通过序列号和时间戳来维护音视频数据的时序关系，确保接收端能够正确还原音视频数据。
4. 流同步：RTP协议通过同步源标识符（SSRC）来实现多个媒体流的同步播放。
5. 媒体传输：RTP协议支持传输多种媒体数据，包括音频、视频和其他自定义数据。
三、协议结构RTP协议的结构如下：1. RTP头部：RTP头部包含协议版本、填充位、扩展位、CSRC计数器、标记位、有效载荷类型、序列号、时间戳和同步源标识符等字段。
2. RTP有效载荷：RTP有效载荷是实际的音视频数据，可以是压缩或非压缩格式。
3. RTP扩展头部：RTP扩展头部是可选的，用于传输额外的信息。
四、协议流程RTP协议的传输流程如下：1. 发送端将音视频数据分包，并在每个包的RTP头部填充相应的字段，如序列号、时间戳和同步源标识符等。
2. 发送端通过网络将RTP包发送给接收端。
3. 接收端根据RTP头部的信息，对接收到的数据进行解析和处理。
4. 接收端根据序列号和时间戳等信息，还原音视频数据，并进行播放或处理。
五、协议优点RTP协议具有以下优点：1. 低延迟：RTP协议通过数据分包和实时传输等机制，能够实现低延迟的音视频传输。
2. 高带宽利用率：RTP协议通过将音视频数据分成小包进行传输，能够更好地利用网络带宽。
3. 可扩展性：RTP协议支持多种媒体数据的传输，并可以通过扩展头部传输额外的信息，具有良好的可扩展性。
RTP协议分析
RTP协议分析协议名称：RTP协议分析一、背景介绍RTP（Real-time Transport Protocol）是一种用于在互联网上传输音频和视频数据的协议。
它被广泛应用于实时通信领域，如音视频会议、流媒体等。
本协议分析旨在深入了解RTP协议的工作原理、数据格式和相关特性，以便更好地理解和应用该协议。
二、协议目标本协议分析旨在：1. 解释RTP协议的基本原理和工作机制；2. 描述RTP协议的数据格式和相关头部信息；3. 分析RTP协议的特性和功能；4. 探讨RTP协议的应用场景和优缺点。
三、协议内容1. RTP协议基本原理和工作机制RTP协议是一种面向实时应用的传输协议，它通过将实时音视频数据分割成多个小的数据包，并为每个数据包添加头部信息，实现对数据的传输和同步。
RTP协议通常与RTCP（RTP Control Protocol）一起使用，RTCP用于传输控制信息和反馈机制。
2. RTP协议数据格式和头部信息RTP协议的数据格式包括RTP头部和有效载荷。
RTP头部包含以下信息：- 版本号：指示RTP协议的版本；- 填充位：用于对齐RTP数据包的边界；- 扩展位：用于指示是否包含RTP头部扩展；- CSRC计数器：指示CSRC标识符的数量；- 标志位：用于指示RTP数据包的特殊属性；- 序列号：用于标识RTP数据包的顺序；- 时间戳：用于同步音视频数据；- SSRC标识符：用于标识RTP数据包的源；- CSRC标识符：用于标识RTP数据包的参考源。
3. RTP协议特性和功能RTP协议具有以下特性和功能：- 实时性：RTP协议适用于实时音视频数据传输，具有低延迟和高可靠性的特点；- 可扩展性：RTP协议支持多种编码和传输方式，可根据需要进行扩展和定制；- 容错性：RTP协议具有容错机制，可以处理丢包和网络抖动等问题；- 压缩支持：RTP协议支持对音视频数据进行压缩和解压缩；- 多媒体同步：RTP协议通过时间戳和同步源标识符实现多媒体数据的同步。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
RTP协议全解（H264码流和PS流）写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。
互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。
原创不易，转载请附上链接，谢谢/chen495810242/article/details/392073051、RTP Header解析图11) V：RTP协议的版本号，占2位，当前协议版本号为22) P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
3) X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头4) CC：CSRC计数器，占4位，指示CSRC 标识符的个数5) M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
6) PT: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。
7) 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。
这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。
同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。
8) 时戳(Timestamp)：占32位，必须使用90 kHz 时钟频率。
时戳反映了该RTP报文的第一个八位组的采样时刻。
接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
9) 同步信源(SSRC)标识符：占32位，用于标识同步信源。
该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
10) 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。
每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。
注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理取一段码流如下：80 e0 00 1e 00 00 d2 f0 00 00 00 0041 9b 6b 49 €?....??....A?kIe1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|?f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q??cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ????其中，80 是V_P_X_CC 1000 0000e0 是M_PT 1110 000000 1e 是SequenceNum 0000 0000 0001 111000 00 d2 f0 是Timestamp 0000 0000 1101 0010 1111 000000 00 00 00是SSRC 0000 0000 0000 0000 0000 0000 0000 0000把前两字节换成二进制如下1000 0000 1110 0000按顺序解释如下：10 是V；0 是P；0 是X；0000 是CC；1 是M；110 0000 是PT；排版不如word看的清晰，大家凑合着看吧。
原创不易，转载请附上链接，谢谢/chen495810242/article/details/392073052、RTP荷载H264码流图2荷载格式定义三个不同的基本荷载结构，接收者可以通过RTP荷载的第一个字节后5位（如图2）识别荷载结构。
1) 单个NAL单元包：荷载中只包含一个NAL单元。
NAL头类型域等于原始NAL单元类型,即在范围1到23之间2) 聚合包：本类型用于聚合多个NAL单元到单个RTP荷载中。
本包有四种版本,单时间聚合包类型A (STAP-A)，单时间聚合包类型B (STAP-B)，多时间聚合包类型(MTAP)16位位移(MTAP16), 多时间聚合包类型(MTAP)24位位移(MTAP24)。
赋予STAP-A, STAP-B, MTAP16, MTAP24的NAL单元类型号分别是24,25, 26, 273) 分片单元：用于分片单个NAL单元到多个RTP包。
现存两个版本FU-A，FU-B,用NAL单元类型28，29标识常用的打包时的分包规则是：如果小于MTU采用单个NAL单元包，如果大于MTU就采用FUs分片方式。
因为常用的打包方式就是单个NAL包和FU-A方式，所以我们只解析这两种。
2.1、单个NAL单元包图3定义在此的NAL单元包必须只包含一个。
这意味聚合包和分片单元不可以用在单个NAL 单元包中。
并且RTP序号必须符合NAL单元的解码顺序。
NAL单元的第一字节和RTP荷载头第一个字节重合。
如图3。
打包H264码流时，只需在帧前面加上12字节的RTP头即可。
2.2、分片单元（FU-A）图4分片只定义于单个NAL单元不用于任何聚合包。
NAL单元的一个分片由整数个连续NAL单元字节组成。
每个NAL单元字节必须正好是该NAL单元一个分片的一部分。
相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包）。
相似，NAL单元必须按照RTP顺序号的顺序装配。
当一个NAL单元被分片运送在分片单元(FUs)中时，被引用为分片NAL单元。
STAPs,MTAPs不可以被分片。
FUs不可以嵌套。
即, 一个FU 不可以包含另一个FU。
运送FU的RTP时戳被设置成分片NAL单元的NALU时刻。
图4 表示FU-A的RTP荷载格式。
FU-A由1字节的分片单元指示（如图5），1字节的分片单元头（如图6），和分片单元荷载组成。
S: 1 bit 当设置成1,开始位指示分片NAL单元的开始。
当跟随的FU荷载不是分片NAL单元荷载的开始，开始位设为0。
E: 1 bit 当设置成1, 结束位指示分片NAL单元的结束，即, 荷载的最后字节也是分片NAL单元的最后一个字节。
当跟随的FU 荷载不是分片NAL单元的最后分片,结束位设置为0。
R: 1 bit 保留位必须设置为0，接收者必须忽略该位打包时，原始的NAL头的前三位为FU indicator的前三位，原始的NAL头的后五位为FU header的后五位。
取一段码流分析如下：80 60 01 0f 00 0e 10 00 00 0000 00 7c 85 88 82 €`..........|???00 0a 7f ca 94 05 3b7f 3e 7f fe 14 2b 27 26 f8 ...??.;.>.?.+'&?89 88 dd 85 62 e1 6dfc 33 01 38 1a 10 35 f2 14 ????b?m?3.8..5?.84 6e 21 24 8f 72 62f0 51 7e 10 5f 0d 42 71 12 ?n!$?rb?Q~._.Bq.17 65 62 a1 f1 44 dc df 4b 4a 38 aa 96 b7 dd 24 .eb??D??KJ8????$前12字节是RTP Header7c是FU indicator85是FU HeaderFU indicator（0x7C）和FU Header（0x85）换成二进制如下0111 1100 1000 0101按顺序解析如下：0 是F11 是NRI11100 是FU Type，这里是28，即FU-A1 是S，Start，说明是分片的第一包0 是E，End，如果是分片的最后一包，设置为1，这里不是0 是R，Remain，保留位，总是000101 是NAl Type，这里是5，说明是关键帧（不知道为什么是关键帧请自行谷歌）打包时，FUindicator的F、NRI是NAL Header中的F、NRI，Type是28；FU Header的S、E、R分别按照分片起始位置设置，Type是NAL Header中的Type。
解包时，取FU indicator的前三位和FU Header的后五位，即0110 0101（0x65）为NAL类型。
3、RTP荷载PS流针对H264 做如下PS 封装：每个IDR NALU 前一般都会包含SPS、PPS 等NALU，因此将SPS、PPS、IDR 的NALU 封装为一个PS 包，包括ps 头，然后加上PS system header，PS system map，PES header+h264 raw data。
所以一个IDR NALU PS 包由外到内顺序是：PSheader| PS system header | PS system Map | PES header | h264 raw data。
对于其它非关键帧的PS 包，就简单多了，直接加上PS头和PES 头就可以了。
顺序为：PS header | PES header | h264raw data。
以上是对只有视频video 的情况，如果要把音频Audio也打包进PS 封装，也可以。
当有音频数据时，将数据加上PES header 放到视频PES 后就可以了。
顺序如下：PS 包=PS头|PES(video)|PES(audio)，再用RTP 封装发送就可以了。
GB28181 对RTP 传输的数据负载类型有规定（参考GB28181 附录B），负载类型中96-127RFC2250 建议96 表示PS 封装，建议97 为MPEG-4，建议98 为H264即我们接收到的RTP 包首先需要判断负载类型，若负载类型为96，则采用PS 解复用，将音视频分开解码。
若负载类型为98，直接按照H264 的解码类型解码。
注：此方法不一定准确，取决于打包格式是否标准PS 包中的流类型（stream type）的取值如下：1) MPEG-4 视频流：0x10；2) H.264 视频流：0x1B；3) SVAC 视频流：0x80；4) G.711 音频流：0x90；5) G.722.1 音频流：0x92；6) G.723.1 音频流：0x93；7) G.729 音频流：0x99；8) SVAC音频流：0x9B。
3.1、PS包头(起始码字段，值为0x000001BA)图71) Pack start code：包起始码字段，值为0x000001BA的位串，用来标志一个包的开始。