2、常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议,这二种基本是完全不同的东西,目前比较方便又好用的是用 HTTP 渐进下载方法。在这个中 apple 公司的 HTTP Live Streaming 是这个方面的代表。它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流.现在见到在桌面也有很多应用了,HTML5 是直接支持这个。
3、但是HLS协议的小切片方式会生成大量的文件,存储或处理这些文件会造成大量资源浪费。如果要实现数天的时移,索引量将会是个巨额数字,并明显影响请求速度。因此,HLS协议对存储I/O要求相当苛刻。对此,也有公司提出了非常好的解决方案。
4、新型点播服务器系统,独创了内存缓存数据实时切片技术,颠覆了这种传统实现方法,从根本上解决了大量切片的碎片问题,使得单台服务器的切片与打包能力不再是瓶颈。
LL-HLS 即:Low-Latency HLS。相比较于HLS,延迟更低,官方说明,最低延迟在3s左右。
延迟是指某一特定视频帧被设备(摄像机、播放机、编码器等)捕获的时间与该帧在终端用户显示器上播放的时间之间的时间差
1.各个环节的缓存区
2.服务端的GOP缓存
3.带宽和传输距离
4.网络抖动和拥塞控制
HLS的一个分片大概5-10s,一般加载3个分片播放。所以延迟大概15-30s.
使用EXT-X-PART标签来表示更小的分片,一个分片的最小持续时间为200毫秒。
下面HLS文件中可以看到第271分片被分割成11部分,每部分333ms。
通过HTTP/2推送模式节省两次RTT:
不发送完整的播放列表,而是发送播放列表的增量(默认的播放列表被保存,然后只在出现时发送增量,而不是发送完整的播放列表);
服务器的责任是保留请求(阻塞),直到包含新片段的播放列表版本可用。阻断播放列表的重新加载消除了轮询;
通过在客户端请求中,增加参数来表明需要哪个位置的数据:
_HLS_msn=<M>: 序列号
_HLS_part=<N>: part号
_HLS_skip=YES|v2 可以跳过
例如:
对请求: https://example.com/2M/waitForMSN.php?_HLS_msn=273&_HLS_part=3 &_HLS_skip=YES 的响应如下:
通过EXT-X-PRELOAD-HINT标签,来声明即将产生的片段。
客户端可以提前发起请求,当该片段生成时立即回复给客户端。
LL-HLS围绕影响延时的几个因素,进行优化。
更小的分片划分,相当于减少的服务端的缓存, PRELOAD标签减少网络建联耗时的影响,服务器阻塞,减少建联耗时和轮询消耗。
参考地址:
https://developer.apple.com/documentation/http_live_streaming/enabling_low-latency_http_live_streaming_hls
https://zhuanlan.zhihu.com/p/358492414
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)