全手打原创，转载请标明出处：https://www.cnblogs.com/dreamsqin/p/12557070.html，多谢，=。=~ （如果对你有帮助的话请帮我点个赞啦）

目前有一个需求是在移动端上内嵌h5实现点位的视频直播，直播项目采用Vue编写，后端主要输出 RTMP 和 HLS 协议的直播流，本文主要总结一下整体开发的技术选型以及开发过程中的思考与学习总结。

我的困惑： 什么是流媒体，以及其传输方式是怎样的？

流媒体是指采用流式传输方式在 Internet 上播放的媒体格式，例如音频、视频等多媒体文件。

流式传输方式是将多媒体文件经过特殊压缩后分成一个个压缩包，再由服务器向客户端连续、实时传送。用户不必像非流式传输那样等待整个文件全部下载完毕后才能播放，而是只需要经过几秒钟或几十秒的启动延时即可对压缩的音视频文件进行播放，剩余的部分将继续下载，直至播放完毕。

常用的流媒体传输协议主要有HTTP渐进式下载和实时流媒体协议两类。 HTTP渐进式下载：仅能传输完整的音视频文件，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的部分。HTTP边下载边播放，严格意义上讲，不是直播协议。他的原理是先下载文件的基本信息，音频视频的时间戳，再下载音视频数据，以播放mp4为例，先下载文件头，根据文件头指引下载文件尾，然后再下载文件的音视频数据。 实时流媒体协议：可用于实况直播，也可传输完整的音视频文件。例如RTSP/RTP、RTMP、HLS、HTTP-FLV。

既可以基于UDP传输也可以基于TCP传输，是纯粹的传输控制协议，它本身与它负载的媒体数据不相关，RTSP协议需要自定义客户端向服务器发送RTSP命令。其视频数据由RTP传输，视频质量由RTCP控制，视频控制（如播放、暂停等）由RTSP提供。

我的困惑： 哪些流媒体传输协议用于直播，不同类型之间又有什么区别？

协议比较全能，既可以用来推送，又可以用来直播。其核心理念是将大块的视频帧和音频帧“剁碎”，然后以小数据包的形式在互联网上进行传输，且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时容易出现一些不可预期的稳定性问题。

苹果推出的解决方案，将视频分成 5-10 秒的视频小分片，然后用 M3U8 索引表进行管理。由于客户端下载到的视频都是 5-10 秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS 的一般延迟在 10-30s 左右）。相比于 FLV，HLS 在iPhone 和大部分 Android 手机浏览器上的支持非常给力，所以常用于 QQ 和微信朋友圈的 URL 分享。

由 Adobe 公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种极致的简洁，在延迟表现和大规模并发方面都很成熟。唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端 APP 直播协议却异常合适。

RTMP、HLS、HTTP-FLV 协议对比如下图所示：

我的困惑： 想要实现直播，需要经历怎样的过程？

如果用一句话描述整体过程，其实就是直播时，主播端将直播流推向服务器，用户端发起请求从服务器拉视频流过来解码播放，流程如下图所示：

第一部分就是视频主播端的操作：视频采集处理后推流到流媒体服务器。

第二部分就是流媒体服务器：负责把从第一部分接收到的流进行处理并分发给用户。

流媒体服务器的主要功能是对流媒体内容进行采集（接收推流）、缓存、调度和传输播放（以流式协议实现用户分发）。

典型的流媒体服务器：

第三部分就是用户：只需要拥有支持对应流媒体传输协议的播放器即可。

这一部分其实就是我们前端需要实现的，如何在移动端的内嵌h5页面中实现直播流的播放。所以我们只需要关注后端是通过什么协议给我们返回直播流以及我们如何有效的播放就可以了~

我的困惑： 除了采用h5原生的