音视频点播为什么要用 HLS？ HTTP 不是也有 Range 请求头？

[yodhcn]

用 Nginx 作为静态资源服务器，访问音频/视频资源时，Nginx 会处理 Range 请求头，不是也能实现拖拽进度条的功能吗？而且读取文件的第 xxx 字节的数据造成的延迟也不高。

那么，HLS 又为什么要提前切片？是因为磁盘上的大文件随机读取慢吗？

[leaflxh]

以及不要在本地测试。非要测试你可以选择把视频放在 U 盘上

[fgodt]

hls 切片对点播来说还有个优点是可以秒开，mp4 大文件 Meta 头都要读很久

你 wav 是未编码的 pcm 格式没有代表性，你试一试 aac+264 组合 seek 就麻烦了

[yodhcn]

@nevermoreluo #15
音视频封装了解的少，请教一下老哥：

1. 本地播放器在播放本地视频，拖拽进度条时，是怎么根据播放进度，定位应该从文件的哪个字节开始播放的？
理论上，网页端播放器与本地播放器，二者的差别应该只有网络传输上的延迟，是 <audio> <video> 的实现逻辑太简单的吗？

2. 您提到的“解复用”具体是指什么？ <audio> <video> 在播放某些特殊格式的媒体时，不能直接根据播放进度计算出 range ，字节的 bytedance/xgplayer 是怎么解决这个问题的？

3. 测试了常用的音频编码：wav ，mp3 都可以无延迟拖进度条，flac 就不行。
是编码层面上的什么差异，导致了这样的结果？ 同样是压缩编码，mp3 可以，而 flac 不行？

[nevermoreluo]

叠甲，以下是曾经断续看过两周各种奇怪资料的个人理解，如有不对还请大佬指正:

1. 差别是网络延迟、缓存、编解码(甚至转码，有的时候软解还要组回去喂给 canvas 或者 mse)。因为这些问题会导致视频甚至无法在 video 标签里面播放，例如 avi 。定位文件从那个字节播放有点想当然了，视频编码不是平铺直叙的，文件指针 seek 到相应位置并不一定等于视频播放 seek 到对应位置。举个例子，音频流和视频流是两组信息，就算你强行 seek 过去大概率会在视频上。夫人，你也不想播放光渲染画面，没有声音吧。。。

2. 解复用是把封装在容器文件中的音视频流分离出来，就像上面说的特例，假设就只有一个视频流和一个音频流，实际可能有很多。字节的 range 也是依赖 mp4 特定格式的 meta 信息，解析出索引和时间戳找到对应的数据组回 mse 播放的。也就是说限定 mp4 支持了 range

3. 这个我也不太了解，就不强答了。

[edotac]

1.HLS 有成熟的加密安全解决方案，mp4 不好做或者我还没了解到，这块在付费业务有用。
2.HLS 的多码率适应在海外复杂网络环境好用？
3.HLS 的整体卡顿率、失败率比 MP4 低？这个我没测过，但是听说是这样。

[hesetiema]

我也觉得是不同格式的音视频问题，之前遇到过：有的音频能拖拽到指定位置快速正常播放，有的却不能，即浏览器进度条是定位到指定位置的，但实际播放的音频确是文件流的开端不是指定位置的音频片段。可能提前切片能减少音视频内容的缓冲和加载时间。当用户请求播放某一段音视频时，服务器可以立即提供已经切片好的片段，而不需要等待整个音视频文件加载完成吧，这样应该是最好的。

[yodhcn]

@hesetiema #26

看我这篇帖子，我在 flac 音频播放时就遇到过这个问题，flac 的元数据中可以放一个 SEEKTABLE 用来加速 seek 。

https://www.v2ex.com/t/996058

[hesetiema]

@yodhcn 破案了，原来是这样

[lovelylain]

> 音视频点播为什么要用 HLS ？
因为源视频文件不一定是单个文件，可能包含多个文件，所以需要一项能支持分片文件连续播放的技术；从技术的角度，MSE 比 HLS 要好，但是 iPhone 只支持 HLS ，为了能在 iPhone 上播放所以要用 HLS ；为什么 iPhone 不肯支持 MSE 你去问 Apple 。