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

2023-11-28 15:10:34 +08:00
 yodhcn
用 Nginx 作为静态资源服务器,访问音频/视频资源时,Nginx 会处理 Range 请求头,不是也能实现拖拽进度条的功能吗?而且读取文件的第 xxx 字节的数据造成的延迟也不高。

那么,HLS 又为什么要提前切片?是因为磁盘上的大文件随机读取慢吗?
3063 次点击
所在节点    程序员
29 条回复
hahasong
2023-11-28 15:12:39 +08:00
CDN 了解下
bestsanmao
2023-11-28 15:13:47 +08:00
因为有些片是新生成的吧
比如直播
wy315700
2023-11-28 15:16:18 +08:00
因为你拖拽进度条的时候,播放器并不知道要请求第几个字节。他只知道请求第几秒的视频。


@bestsanmao
OP 说的是点播
GeekGao
2023-11-28 15:19:19 +08:00
最大优势:HLS 自带多码率自适应啊…
mscststs
2023-11-28 15:23:21 +08:00
DASH 了解一下
flyqie
2023-11-28 15:31:41 +08:00
好做 cache ?
nothingistrue
2023-11-28 15:42:33 +08:00
第一,提高下载门槛。不要小看这一点门槛,防盗版本来就是防小白不防高人,只要把小白阻挡了就已经成功了。

第二,越简单粗暴,可用性越差,大文件是真不行。就别说网络视频了,本地一个单文件视频,你拖进度条试试。视频定位,快进、快退是跳固定帧,很快,但是点击进度条定位,就要先算基准帧,慢的一匹。HLS 可能原本不是给定位用的,但它顺便就给进度条定位加了一个缓存。
yodhcn
2023-11-28 16:13:13 +08:00
@nothingistrue #7
"视频定位,快进、快退是跳固定帧,很快,但是点击进度条定位,就要先算基准帧,慢的一匹。"

是指拖拽进度条吗?实测拖拽进度条几乎没有延迟
yodhcn
2023-11-28 16:19:14 +08:00
@yodhcn #8

后端:SpringBoot 实现的 /stream 接口,返回 ResponseEntity<Resource> responseEntity = ResponseEntity.ok().headers(headers).body(new FileSystemResource(filePath))

前端:html5 <audio>

测试音频文件:wav 封装格式,大小 1.5G ,时长 1 小时 40 分钟

实测拖拽进度条几乎没有延迟
flyqie
2023-11-28 16:38:26 +08:00
@yodhcn #9

h264 试过吗?

IPB 帧确实得定位。。定位到最近的 I 帧然后再解码后面的 PB 帧
jsboy
2023-11-28 16:43:27 +08:00
貌似和视频格式有关吧?之前处理过类似的功能,mp4 是可以通过视频进度计算对应的字节偏移量,但是有些视频格式是无法通过视频进度计算对应的字节偏移量。所以我的觉得转成 hls 是一种统一的做法。如果原视频需要支持很多格式,那么我会选择统一转成 hls 。
chaxus
2023-11-28 16:45:08 +08:00
hls 协议自带标准加密,码率自适应,分片加载等等,功能比较完备。用其他方式确实也能实现,但是,何必呢?
ttvast
2023-11-28 16:47:49 +08:00
HLS=HTTP Live Streaming

本来就是针对直播设计的。你们都过度解读了。

对于点播来说。hls 相比 mp4 没有什么优势和区别
wy315700
2023-11-28 16:48:45 +08:00
@yodhcn
wav 是固定码率的,进度条和文件位置是等价的。
你找个 FLV 看看
nevermoreluo
2023-11-28 16:52:03 +08:00
1. 多数音视频格式是无法通过头上一段字节推断流内容的,mp4 除外
2. hls 有现有库支持浏览器播放,video 标签支持 mp4
3. H265 解码问题,浏览器多数还不支持硬解,软解实现操蛋,流媒体在服务器上就解决了
4. 即使 range 也要再经过一系列的解复用才可以拖进度条,不过有现成的库,例如字节的 https://github.com/bytedance/xgplayer
nothingistrue
2023-11-28 16:54:00 +08:00
@yodhcn #8 换个 h264 视频再试试,你还可以试试去掉硬解用软解。还没看出来,就再弄个 h265 的。如果你买的是品牌机,有些会内置优化硬解,这东西你要在自己组装机器上会体验的很明显。
Goat121
2023-11-28 17:03:00 +08:00
我还真用 range 做过,你自己测试是没用的,我们当时测试也没问题
但是上线问题就来了,因为视频点播必须上 CDN 的,CDN 不支持 range 获取视频
即使真有 CDN 支持,每次回源必须拉取整个视频资源,不管是用户响应时间还是流量成本,都比 hls 高太多了。
特别是对于长视频,用户往往不会看完,越长的视频越浪费。当时我们调研过市面上主要 app 的视频格式,只有抖音用的 mp4 ,没考虑到抖音是最长 15 秒的,灰度测试紧急改成 hls 了
nevermoreluo
2023-11-28 17:16:59 +08:00
laqow
2023-11-28 17:25:01 +08:00
video 控件的 range 每次都是从节点直接到结尾的,意味着会重新下载很多次原始视频
leaflxh
2023-11-28 17:29:08 +08:00
搞个视频放在服务器上,本地用<video src="视频地址" /> 试一下就知道了

你看看能不能流畅的拖动进度条,甚至能不能加载显示出来

以及可供的测试项:

视频为 h265 格式
视频为 h264 格式,但关键帧间隔不固定
视频为 mkv 格式

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

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

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX