流媒体传输和谈之TCP与UDP

一、TCP

  TCP是面向连接（连接导向） 的、靠得住的、基于字节俭的。局域网中应用TCP传输流斗劲靠谱，TCP在错杂互联网景象应用性斗劲窄，今朝都采取码流自适应来解决收集质量等外在身分对撒播输的影响。安防行业的收集摄像头（IPC）、DVR等设备一般会为一个通道供给多种码流，可设备不合是辨别率、码率、帧率来适应不合的收集带宽景象。RTP/RTSP、HLS均可基于TCP来传输码流，TCP传输流媒体一般用于收集景象较好的场景。

二、UDP

  UDP是OSI参考模型中一种无连接的传输层和谈，它首要用于不请求分组次序达到的传输中，供给面向事务的简单不成靠信息传送办事。在收集质量令人不十分合意的景象下，UDP和谈数据包丧失会斗劲严重。然则因为UDP的特点：它不属于连接型和谈，因而具有资料消费小，处理惩罚速度快的长处，所以凡是音频、视频和通俗数据在传送时应用UDP较多，因为它们即使无意丧失一两个数据包，也不会对接管成果产生太大影响。若是选择UDP传输流媒体，就必须得接管丢包乱序的题目，当然我们也可以在UDP上建树包序号搜检和超时重传机制，满足场景须要就行，若是这些机制做的过于严苛还不如直接用TCP来传输了。数字电视行业的转码器（例如envivio/思科）根蒂根基都是基于UDP传输TS封装的码流，可供给不合码率的码流，采集到转码器的流今后须要自行解复用，选择适应客户端收集传输的码流播放。

UDP丢包乱序题目解析：

UDP在局域网丢包不明显，在公网景象中丢包很广泛。UDP是无连接的传输和谈，与TCP比拟，会存在丢包和乱序的题目。

1.发送数据包太大或者太频繁

  经由过程把握报文大小来解决报文过大导致丢包，以太网的MTU凡是是1500 bytes，所以好把握发送报文长度在1000阁下，可按照景象恰当推敲。

  若是要发送的数据过多或者过大，那么在缓冲区满的那个刹时要发送的报文就很有可能被丧失。

  批改缓冲区大小可以恰当缓解丢包；在每个报文都加上报文编号，以报文编号断定丢包和乱序，RTP包头有sequence number、TS包头有continuity_counter，若是传输的数据没有明白的包序列号，可自定义报文包头，呈现丢包后可向对端发送重传消息。UDP的丢包和乱序是确确切实存在的，只能经由过程自行定义和谈做类TCP的重传机制和超机会制。

2.接管方处理惩罚时候太长，接管来不及

  重构数据接管和处理惩罚逻辑，不克不及让接管数据因为应用层的事务梗阻，接管数据模块和处理惩罚模块应当是异步的构建，共同保护一个数据队列，确保数据及时获取和处理惩罚。

三、对象介绍

  VLC media player是做流媒体开辟必不成少的对象，可做HLS、RTSP、UDP等常见和谈的收集播放和本地播放，亦可做流媒体推流办事器，将本地文件转码后推送到指定的收集地址。

四、场景介绍

下面就介绍下曾经做过的两种流媒体传输模式：

1.对接某国外安防监控品牌的DVR设备，RTCP over TCP用作设备经管把握号令和谈，RTSP over TCP作为撒播输把握号令和谈， RTP封装H.264 over TCP作为撒播输和谈。 

  设备端RTCP端标语一般为555，连接该端口，并进行登录设备、获取设备信息、注册权限验证、心跳机制;

  设备端RTSP端标语一般为554，连接该端口，并进行DESCRIBE、OPTI、SETUP、PLAY、PAUSE、TEARDOWN等撒播输把握号令;

  设备端RTP端标语一般为556，连接该端口，接管RTP和谈的码流数据传输。

  当时的功能需求是登录设备、获取信息、直播通道码流、按时候回放通道的录像以及暂停、开端、拖拽、停止等把握体式格式，就直接用非梗阻socket的模式做超机会制实现了RTCP/RTSP/RTP，当然也可引入jrtp这个开源库来实现。

2.面向广电运营商的流媒体办事器，转码器向网内组播多个频道多种码率的流数据TS Over UDP，从而须要采集这个多路复用的流，并按不合节目不合码率转发出去。

  bind组播端口5842，参加组播，采集UDP数据，解复用，遵守不合的program_map_PID（节目PID）解析不合的elementary_PID（音视频PID）。具体解析办法参照另一篇文章TS格局解析。然后遵守HLS和谈封装playlist.m3u8和多个ts文件切片，达到码流自适应。具体封装办法参照另一篇文章HTTP Live Streaming和谈。