RTP推流及验证

[时间：2018-07] [状态：Open]
[关键词：rtp,rtcp, ffmpeg,ffplay,sdp,h264,mp2,ts,推流]

近期在学习有关RTP/RTCP的资料，发现看了很多资料，还是不如搭建一个RTP推流端和接收端。这样可以加深些理解，

从我目前的获得信息来看，RTP是位于传输层的协议，其可以基于UDP、TCP等协议传输，通常使用较多的是UDP，主要为了降低延时等。

RTP支持的负载格式一般是分开的，也就是说音频和视频是通过独立的RTP协议传输的。RTP支持H264、HEVC、AAC等常见音视频的格式（更详细的RTP支持格式可参考RTP profile），其广泛应用于视频会议及IP电话中。

为了直观点，我们还是直接用FFmpeg模拟一个RTP推流端，然后用ffplay作为客户端播放之。

先说明下我用的FFmpeg版本是v4.0，我们全程将仅使用ffmpeg和ffplay两个可执行程序。

RTP推送h264流及验证方法

ffmpeg中的RTP muxer仅支持一个流作为输入，比如推送h264流可以使用下面命令：

./ffmpeg -re -stream_loop -1 -i zhen_h264+mp2.ts -vcodec copy -an -f rtp rtp://10.10.50.90:9999 > h264.sdp

可使用下面命令验证推流情况：

./ffplay -protocol_whitelist "file,rtp,udp" h264.sdp

实际上ffmpeg内部RTP默认使用UDP协议发送数据，所以可以指定单播或者组播地址。
上述命令生成的sdp文件内容如下：（对于RTP协议，sdp作为重要的流描述信息，是必须存在的）

SDP:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 10.10.50.90
t=0 0
a=tool:libavformat 58.11.100
m=video 9999 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z01AHpZWBaHpKEAAAPpAAB1MIQ==,aO48gAA=; profile-level-id=4D401E

这里解释下上述参数的意义：

• -re 该参数表示按照实际帧率发送，否则按照最快速度发送数据（视具体主机性能而定）
• -stream_loop -1表示循环播放，这里的是数字-1（不是字母L）,本地文件串流结束后直接从头开始
• -vcodec copy/-acodec copy表示复制视频或者音频，不做转码
• -vn/-an表示禁用视频或音频```````

RTP推送mp2流及验证方法

推送音频流命令如下：

./ffmpeg -re -stream_loop -1 -i zhen_h264+mp2.ts -acodec copy -vn -f rtp rtp://10.10.50.90:9999 > mp2.sdp

可使用下面命令验证推流情况：

./ffplay -protocol_whitelist "file,rtp,udp" mp2.sdp

所生成的sdp文件格式如下：

SDP:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 10.10.50.90
t=0 0
a=tool:libavformat 58.11.100
m=audio 9999 RTP/AVP 14
b=AS:128

RTP推送mpegts流及验证方法

参考了下wiki及ffmpeg源码发现，还有一个rtp_mpegts的muxer，可以支持推送mpeg-ts流（这也是我能找到的RTP唯一支持的容器格式）。
验证下命令如下，首先推流端：

./ffmpeg -re -stream_loop -1 -i zhen_h264+mp2.ts -vcodec copy -acodec copy -f rtp_mpegts rtp://127.0.0.1:9999

接收端就简单了，给个IP地址和端口就可以播放了：

./ffplay rtp://127.0.0.1:9999

小结

从上面三个实例可以看出，正常接收rtp需要一个sdp后缀的文件作为描述信息，否则客户端无法获知音频或视频信息。所以要学习并理解RTP协议，除了协议本分，还包括其负载的分包和sdp文件格式。

参考资料

1. leixiaohua-FFmpeg发送流媒体的命令（UDP，RTP，RTMP）
2. ffmpeg-doc-rtp
3. RTP audio video profile