如果你做过直播相关视频流的选择，会遇到m3u8和flv，遇到的现象是：m3u8的直播流比flv的要慢一些，多延时可能达到几十秒。
那么为什么产生这种问题？如果网速好是不是可以避免这种问题？
1、m3u8的由来
M3U8 是 HLS（HTTP Live Streaming）协议中的一种播放列表文件格式。HLS 是由 Apple 开发的用于通过基于 HTTP 的网络来传输直播和点播视频流的协议。
1.1、m3u8的优点
1、兼容性好： 既然是http的，也就表明他的兼容性很好，在多平台都可以使用。直播时，直播源头的画面通过H263（H264）编码、声音通过AAC编码之后，会打包到TS（Transport Stream）容器之中
2、流畅性好： 把编码好的 TS 文件等长切分成后缀为 ts 的小文件，并生成一个 .m3u8 的纯文本索引文件；也就是说m3u8 就是包含多个 ts 文件的播放列表。播放器按顺序逐个播放，全部放完再请求一下 m3u8 文件，获得包含最新 ts 文件的播放列表继续播，周而复始。整个直播过程就是依靠一个不断更新的 m3u8 和一堆小的 ts 文件组成。
客户端可以在播放当前视频段的同时下载后续段，这有助于维持流畅的观看体验，即使在网络波动的情况下，也能有效减少卡顿，带来更流畅的体验。
看一下直播过程中的所谓分割，代码是怎么设置的（也就是切片）
1.2、m3u8优点也决定了缺点
如果每个 ts 按照 5 秒来切分，一个 m3u8 放 6 个 ts 索引，那么至少就会带来 30 秒的延迟。
如果减少每个 ts 的长度，减少 m3u8 中的索引数，延时确实会减少，但会带来更频繁的请求，对服务端的请求压力也会成倍增加。所以只能根据实际情况找到一个折中的点。最好的切片折中效果，可以做到2-3秒的低延时
1.3、简单聊下flv
flv是以数据块的形式进行数据编码传递的，是一种持续的过程，不像hls，严格按照切片的形式进行，所以延时会好些，但是仍然存在延时的问题，并且兼容性会差些，比如就不用用在iOS，除非借助一些第三方的播放器
看代码可以确认flv没有切片的概念
到这里，上面的疑问都有答案了，flv延时会比m3u8好些，但是不管是m3u8还是flv，再好的网络，也没办法做到无延时，这是本身的实现原理决定的
2、聊点其他的
2.1 延时相关
RTC协议做直播，可以做到毫秒级延时， 比如大家常听说的webRTC，可以做到延时200-500ms。总结下使用场景，可以这么理解
1、小规模、简易部署：若需要快速部署且已有 HTTP 基础设施支持，HLS 可以经济高效地利用现有资源。
用在H5页面进行直播，使用简单高效，一行代码搞定，像官网正在使用的H5页面新品发布会直播
<video src="devimages.apple.com/iphone/samp…"height="300" width="400">
2、传统稳定使用：在特殊、支持环境下 RTMP/FLV 仍然提供了一些成本效益优势。
比如年会直播的直播流
3、低延时及互动：RTC 被更适合需要极低延时和实时互动环境。
比如腾讯会议，实时性、互动性要求较高的直播
2.2 不同分辨率直播流相关
1、HLS直播流，在网络不好的情况下，可以自动切换低码率的视频，比如1080p到480p的直播流，做到播放流畅，但是会牺牲视频质量
2、FLV直播流，如果你选择了一种分辨率的直播流播放，即使网络不好，都会一直保持相同分辨率的直播流播放，即使卡在那（SDK做的特殊处理不算）
