HLS网络直播技术

一、现状

全民直播时代，任何人在任何地方都可以拿起手中身设备进行现场直播，直播给给一群人带来工作职位，给各大直播平台带来巨大收益，在巨大的市场面前要拥有高质量，低成本的直播技术才能在竞争中脱颖而出，成为直播界的大佬。视频直播的5个关键的流程：1.录制2.编码3.网络传输4.解码5.播放。其中的每一环节都会影响直播的质量和延迟时间等，下面我们会主要是讲一下在第三点优化延迟的方案。

现在直播技术一般采用的协议为，RTMP、HLS、HDL（HTTP-FLV）、RTP，在这些协议中比较常见的协议就是rtmp协议，现在国内很多的直播平台还在使用，还有就是HLS用的也是非常多的一种协议。针对上述协议做一些简单的介绍。

二、协议

RTMP协议

是Adobe的专利协议，现在大部分国外的CDN已不支持。在国内流行度很高。原因有几个方面：

1、开源软件和开源库的支持稳定完整。如斗鱼主播常用的OBS软件，开源的librtmp库，服务端有nginx-rtmp插件。

2、播放端安装率高。只要浏览器支持FlashPlayer就能非常简易的播放RTMP的直播，协议详解可以Google了解。相对其他协议而言，RTMP协议初次建立连接的时候握手过程过于复杂（底层基于TCP，这里说的是RTMP协议本身的交互），视不同的网络状况会带来给首开带来100ms以上的延迟。基于RTMP的直播一般内容延迟在2~5秒。

HTTP-FLV协议

即使用HTTP协议流式的传输媒体内容。相对于RTMP，HTTP更简单和广为人知，而且不担心被Adobe的专利绑架。内容延迟同样可以做到2~5秒，打开速度更快，因为HTTP本身没有复杂的状态交互。所以从延迟角度来看，HTTP-FLV要优于RTMP。

HLS 协议

HLS即Http Live Streaming，是由苹果提出基于HTTP的流媒体传输协议。HLS有一个非常大的优点：HTML5可以直接打开播放；这个意味着可以把一个直播链接通过微信等转发分享，不需要安装任何独立的APP，有浏览器即可，所以流行度很高。社交直播APP，HLS可以说是刚需，下来我们分析下其原理 。 
       HLS 的基本原理就是当采集推流端将视频流推送到流媒体服务器时，服务器将收到的流信息每缓存一段时间就封包成一个新的 ts 文件，同时服务器会建立一个 m3u8 的索引文件来维护最新几个 ts 片段的索引。当播放端获取直播时，它是从 m3u8 索引文件获取最新的 ts 视频文件片段来播放，从而保证用户在任何时候连接进来时都会看到较新的内容，实现近似直播的体验。相对于常见的流媒体直播协议，例如 RTMP 协议、RTSP 协议等，HLS 最大的不同在于直播客户端获取到的并不是一个完整的数据流，而是连续的、短时长的媒体文件，客户端不断的下载并播放这些小文件。这种方式的理论最小延时为一个 ts 文件的时长，一般情况为 2-3 个 ts 文件的时长。HLS 的分段策略，基本上推荐是 10 秒一个分片

RTP协议

RTP即Real-time Transport Protocol，用于Internet上针对多媒体数据流的一种传输层协议。实际应用场景下经常需要RTCP（RTP Control Protocol）配合来使用，可以简单理解为RTCP传输交互控制的信令，RTP传输实际的媒体数据。 
RTP在视频监控、视频会议、IP电话上有广泛的应用，因为视频会议、IP电话的一个重要的使用体验：内容实时性强。

对比与上述3种或实际是2种协议，RTP和它们有一个重要的区别就是默认是使用UDP协议来传输数据，而RTMP和HTTP是基于TCP协议传输。为什么UDP 能做到如此实时的效果呢？关于TCP和UDP差别的分析文章一搜一大把，这里不在赘述，简单概括： 
UDP：单个数据报，不用建立连接，简单，不可靠，会丢包，会乱序； 
TCP：流式，需要建立连接，复杂，可靠 ，有序。 
实时音视频流的场景不需要可靠保障，因此也不需要有重传的机制，实时的看到图像声音，网络抖动时丢了一些内容，画面模糊和花屏，完全不重要。TCP为了重传会造成延迟与不同步，如某一截内容因为重传，导致1秒以后才到，那么整个对话就延迟了1秒，随着网络抖动，延迟还会增加成2秒、3秒，如果客户端播放是不加以处理将严重影响直播的体验。 
总结一下：在直播协议的选择中，如果选择是RTMP或HTTP-FLV则意味着有2~5秒的内容延迟，但是就打开延迟开，HTTP-FLV 要优于RTMP。HLS则有5~7秒的内容延迟。选择RTP进行直播则可以做到1秒内的直播延迟。但就目前所了解，各大CDN厂商没有支持基于RTP直播的，所以目前国内主流还是RTMP或HTTP-FLV，还有兴起的HLS。

HLS与RTMP的对比

HLS

 HLS 的缺点：

• 通常 HLS 直播延时会达到 20-30s，而高延时对于需要实时互动体验的直播来说是不可接受的。
• HLS 基于短连接 HTTP，HTTP 是基于 TCP 的，这就意味着 HLS 需要不断地与服务器建立连接，TCP 每次建立连接时的三次握手、慢启动过程、断开连接时的四次挥手都会产生消耗。

 HLS 它的优点：

• 数据通过 HTTP 协议传输，所以采用 HLS 时不用考虑防火墙或者代理的问题。
• 使用短时长的分片文件来播放，客户端可以平滑的切换码率，以适应不同带宽条件下的播放。
• HLS 是苹果推出的流媒体协议，在 iOS 平台上可以获得天然的支持，采用系统提供的 AVPlayer 就能直接播放，不用自己开发播放器。

RTMP

相对于 HLS 来说，采用 RTMP 协议时，从采集推流端到流媒体服务器再到播放端是一条数据流，因此在服务器不会有落地文件。这样 RTMP 相对来说就有这些优点：

• 延时较小，通常为 1-3s。
• 基于 TCP 长连接，不需要多次建连。

因此业界大部分直播业务都会选择用 RTMP 作为流媒体协议。通常会将数据流封装成 FLV 通过 HTTP 提供出去。但是这样也有一些问题需要解决：

• iOS 平台没有提供原生支持 RTMP 或 HTTP-FLV 的播放器，这就需要开发支持相关协议的播放器。

HLS延迟优化

hls的延时主要由以下三个部分组成：

（1）服务器端的编码器和流分割器生成TS文件的时间

（2）客户端下载TS文件的时间，而通常要求下载完两个TS媒体文件

（3）客户端解码并播放时间

这三个方面里面，前两个方面我们是可以控制调节的，对于第三个方面只能取决于客户端的性能。

具体优化方法

　　由于服务器端生成TS流段需要时间，那么我们可以调节每段TS文件的大小，让其小些，那么服务器生成它的速度就加快，时间缩短。这样一来，客户端下载第一段或者前两段的时间就会减少，延时就会降低。根据上述的方式可以更改HLS的分段大小，方法是修改nginx配置文件nginx.conf，默认情况下nginx.conf文件的hls配置部分如下：

rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        application live {
                live on;
        }
        hls on;
        hls_fragment  1s;//将每段的长度限定为1s
        hls_path /tmp/hls;
    }
}

       将每段的长度限定为1s，HLS官方推荐的是10s，但是在我这里10s延时太大。但是段的时长越短，服务器的负载越大，延时越少。对于这句话我不是十分理解，至少我并没有发现服务器负载增加。当每段的长度固定之后，播放列表的长度也会影响延时时间，而且会对再次播放时的开始时间产生影响，非首次播放时，客户端会在播放列表的开头开始播放，所以总的延时时间等于播放列表长度加上上述的延时时间。所以将播放列表长度不要设置太大：

hls_playlist_length 3s;

这样设置完之后的配置文件RTMP模块配置部分为：

rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        application live {
                live on;
        }
        hls on;
        hls_path /tmp/hls;
        hls_fragment 1s;//将每段的长度限定为1s
        hls_playlist_length 3s;
    }
}