文章目录
- 前言
- hls配置
- m3u8
- 单码流
- 1.开始进入播放页,默认是暂停态
- 2.等几十秒后的状态
- 3.开始播放后的状态
- 其他
- 多码流
前言
hls配置
backBufferLength:60 // 默认无限制 缓存媒体播放后要保留的最长持续时间(以秒为单位)。
liveSyncDurationCount:3 // 默认值3 播放将从片段 N-3 开始,N 是实时播放列表的最后一个片段。即开始播放时提前下载最后三个。
maxBufferLength: 30 // 默认30s 如果缓冲区长度小于此值,将加载一个新片段。跟maxBufferSize有关系可能打印30s单不能大于maxBufferSize。
maxMaxBufferLength: 600 // 默认600s 兜底方案最大只能存储这么多。
maxBufferSize: 60000000 // 默认值:60 MB 如果缓冲区大小大于此值,则不会加载任何片段。
// 根据级别比特率计算我们可以从这个负载级别获得的最大缓冲区长度。
// 最后都会转换为时间,缓冲区不超过60 MB
// 可能超过30秒
protected getMaxBufferLength(levelBitrate?: number): number {
let maxBufLen;
if (levelBitrate) {
maxBufLen = Math.max(
(8 * config.maxBufferSize) / levelBitrate,
config.maxBufferLength
);
} else {
maxBufLen = config.maxBufferLength;
}
return Math.min(maxBufLen, config.maxMaxBufferLength);
}
// 当前buffer的时间长度 单位秒
const bufferLen = bufferInfo.len;
// 计算出的最大buffer时间长度 单位秒
const maxBufLen = this.getMaxBufferLength(levelInfo.maxBitrate);
if (bufferLen >= maxBufLen) {
return;
}
上面的结果是如果单码流就是配置的maxBufferLength: 30,没有入参levelBitrate
如果是多码流,会根据码流的levelBitrate计算,例如 比特率 8247438 bit/s = 1Mb/s
约等于58秒
m3u8
每个TS
6秒
有20个TS
每个TS大约
55.9MB/10
=5.59
MB
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:3396240
#EXTINF:6.000000,
segment_4_20230211_1676110830.ts
#EXTINF:6.000000,
segment_4_20230211_1676110836.ts
#EXTINF:6.000000,
segment_4_20230211_1676110842.ts
#EXTINF:6.000000,
segment_4_20230211_1676110848.ts
#EXTINF:6.000000,
segment_4_20230211_1676110854.ts
#EXTINF:6.000000,
segment_4_20230211_1676110860.ts
#EXTINF:6.000000,
segment_4_20230211_1676110866.ts
#EXTINF:6.000000,
segment_4_20230211_1676110872.ts
#EXTINF:6.000000,
segment_4_20230211_1676110878.ts
#EXTINF:6.000000,
segment_4_20230211_1676110884.ts
#EXTINF:6.000000,
segment_4_20230211_1676110890.ts
#EXTINF:6.000000,
segment_4_20230211_1676110896.ts
#EXTINF:6.000000,
segment_4_20230211_1676110902.ts
#EXTINF:6.000000,
segment_4_20230211_1676110908.ts
#EXTINF:6.000000,
segment_4_20230211_1676110914.ts
#EXTINF:6.000000,
segment_4_20230211_1676110920.ts
#EXTINF:6.000000,
segment_4_20230211_1676110926.ts
#EXTINF:6.000000,
segment_4_20230211_1676110932.ts
#EXTINF:6.000000,
segment_4_20230211_1676110938.ts
#EXTINF:6.000000,
segment_4_20230211_1676110944.ts
单码流
我用的最后一个level(level4)。
1.开始进入播放页,默认是暂停态
实际如下图,分析一下 1:42/2:00
说明什么?
2:00
说明当前一个Media Playlist 有20个Ts
*每个TS 6秒
=120S
,即从我下载这个Media Playlist,最少已经直播了2分钟了。1:42
说明我要从倒数第三个TS文件播放120S - 3个TS * 6秒 = 1:42
,即我比直播最少延迟了18 s
这里的初始下载并缓存3个ts取决于配置liveSyncDurationCount:3
2.等几十秒后的状态
图中的1:42
代表我们还是没有播放还是上面的初始状态。
2:30
: 代表直播流媒体服务器已经直播到相对2:30
秒了,即实际上我们大概等了30秒了,延迟了48秒。
下图看到我们的播放轴还在1:42
,下载了6个ts,缓存了6个ts,也就是我们等了30s,按理说应该多下载5个ts,为什么这里只多下载了3个呢,最后面的2个没有下载?
这里跟maxBufferLength = 30
有关系,小于30s将下载新片段。
往前最多下载多少个ts数,取决于能最多的缓存ts数,所以一共下了6个ts,后边就不下了。
3.开始播放后的状态
按照上面一样的分析方式,下图为播放了一会儿后的状态。
视频播放到2:06,流媒体实时播放到3:00
,对比上面我们从1:42开始播的,即播放了24s,延迟了54秒。
Buffer了10个ts,即大约60s,其中有播放过的16s。即往前buffer6个ts 36s,往后buffer了4个ts 16s。
播放一段时间后
总共缓存了16个ts,其中播放完的缓存了10个 = 60s,这取决于配置backBufferLength:60,往前缓存了6个取决于配置maxBufferLength = 30
,针对单码流是这样的。多码流的话去看下配置中的解析。
其他
暂停长时间不播,或者模拟中间网速不好没下载到ts的情况,然后再继续播放。
**补个刚好的图,**即将跳跃到最新位置
跳跃后的状态
立马发出3个请求取决于配置liveSyncDurationCount:3
,并且往前的缓存基本上也都是3了
多码流
基本跟单码流差不多。具体看截图哈。
往前最多缓存了10ts = 60秒,因为这是多码流所以是按照60M/ level的比特率 与配置的30s取最大值,这里为58s。所以大约是10个ts。
看下跳跃情况