一、引言

网络传输H.264有多种方法，包括但不限于：1.通过RTP直接传输H.264；2.通过UDP传输TS流；3.通过RTP传输TS流；4.通过RTP传输PS流。本文对这些方法进行对比。

二、通过RTP直接传输H.264

这种方案就是RTP包（RTP packet）的payload直接携带H.264视频数据，也就是所谓的：RTP for H.264或H.264-NALU-over-RTP。FFmpeg命令支持生成和解析这种方案生成的RTP流（见：《音视频入门基础：RTP专题（2）——使用FFmpeg命令生成RTP流》）。网络摄像机的RTSP流也是通过这种方式传输H.264的（见：《音视频入门基础：RTP专题（21）——使用Wireshark分析海康网络摄像机RTSP的RTP流》）。

优点：跟下面的方案相比，使用这种方法进行网络传输音视频数据的开销是最小的，因为可以避免数据包的重复包头（比如MPEG2-TS中的TS Header、PES流中的PES packet header等）。

缺点（可能也不是缺点，算特性吧？）：

1.H.264这种负载类型由于诞生的较晚，在RTP header中没有具体的PT值（payload type），只能使用动态（dynamic）PT值，即96到127。所以播放器没法通过判断RTP header中的payload type值来确定该RTP包中payload的格式，必须要配合SDP等方式进行媒体协商。SDP会告诉播放器（RTP接收端），RTP payload携带的是哪种音视频压缩编码格式。

2.RTP中有多少路音视频流，就得让RTP接收端创建多少个UDP（RTP）接收端口（这里仅针对RTP不考虑RTCP）。比如RTP中有一路视频，一路音频，那接收端就得创建2个不同的端口来分别接收这两路音视频流。

三、通过UDP传输TS流

见《音视频入门基础：MPEG2-TS专题（25）——通过FFmpeg命令使用UDP发送TS流》。这种方案缺点很明显，就是不支持在接收端对数据包重新排序。

四、通过RTP传输TS流

这种方案就是把ES流（包括H.264）打包为PES流，PES流加上TS Header打包为TS流，TS流再封装为RTP流传输。见《音视频入门基础：MPEG2-TS专题（26）——通过FFmpeg命令使用RTP发送TS流》。这种方法是对“上述方法三”的优化。

优点：

1.这种方案，RTP包（RTP packet）的payload中携带的是TS流数据，TS流的TS包中才携带实际的音视频数据。MPEG2-TS的payload type值固定为33，所以播放器（RTP接收端）可以直接通过判断RTP header中的payload type值来确定该RTP payload的格式为MPEG2-TS，所以就不需要配合SDP等方式进行媒体协商了。

2.不管RTP中有多少路音视频流，RTP接收端只要创建一个UDP（RTP）端口接收音视频数据就可以了。

3.可以通过RTP header中的序列号检查同一个PID的TS包的连续性，从而判断TS包是否连续以及丢失。

4.可以对RTP header进行扩展，从而实现更多功能。比如IPTV系统通过RTP协议拓展的方式实现从节目的源头开始，对节目进行各种处理和分发，或者录制，并且保证处理、分发和录制的及时性、有效性，并能适应IP 网络条件将节目数据分发到不同的地域，分发到距离用户最近的服务器为用户提供服务，还能应付各种突发事件。具体可以参考：《RTP协议在IPTV系统中的应用》。

五、通过RTP传输PS流

这种方案就是把ES流（包括H.264）打包为PES流，PES流加上pack header（包括system header）打包为PS流，PS流再封装为RTP流传输。见《音视频入门基础：MPEG2-PS专题（8）——使用Wireshark分析GB28181的PS流》。国标GB28181传输的就是这种音视频流。

特性：

1.MPEG2-PS还是只能使用动态（dynamic）PT值，所以需要配合SDP等方式进行媒体协商。

2.国标国标，所谓国标就是我们国内的标准，所以国际上很多软件对这种流支持不太好。比如Wireshark抓包后无法直接显示PS流的pack header、system header；目前版本的FFmpeg还无法直接生成RTP封装的PS流；某些国际上的音视频播放器无法播放这种流。但也正因为如此，诞生了大量需求，才需要软件工程师来开发GB28181。