博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
由想实现webview的flash跳转引发的优酷视频地址解析问题
阅读量:6555 次
发布时间:2019-06-24

本文共 1065 字,大约阅读时间需要 3 分钟。

 

vid后面换成任意视频的VID即可得到视频的m3u8地址,但是目前没有找到切换码流的地址

 

上面这个是HLS的协议说明

 

这是在知乎上偶然看到的,解释了为什么HLS相比mp4流的好处,我估计提问人的意思是为什么现在是解析m3u8而不是以前的直接播放流化后的mp4文件

 

你说的应该是 HTTP Live Streaming [1] 吧。这个是 Apple 为了提高流播效率开发的技术,特点是将流媒体切分为若干 TS 片段(比如每10秒一段),然后通过一个扩展的 m3u 列表文件将这些 TS 片段集中起来供客户端播放器接收。

这样做相比使用 RTSP 协议的好处在于,一旦切分完成,之后的分发过程完全不需要额外使用任何专门软件,普通的网络服务器即可,大大降低了 CDN 边缘服务器的配置要求,可以使用任何现成的 CDN。分发使用的协议是最常见 HTTP,代理服务器对这个协议的缓存优化相当成熟,而很少有代理服务器对 RTSP 的进行缓存优化。这对播放(软)实时视频有相当大的优势,因为这样分发后,对源服务器的负载压力小得多。

对于非实时视频,同样的好处也是存在的:如果你要在一段长达一小时的视频中跳转,如果使用单个 MP4 格式的视频文件,并且也是用 HTTP 协议,那么需要代理服务器支持 HTTP range request 以获取大文件中的一部分。不是所有的代理服务器都对此有良好的支持。而 HTTP Live Streaming 则只需要根据列表文件中的时间轴找出对应的 TS 片段下载即可,不需要 range request,对代理服务器的要求小很多。所有代理服务器都支持小文件的高效缓存。

此外,HTTP Live Streaming 还有一个巨大优势:自适应码率流播(adaptive streaming)。效果就是客户端会根据网络状况自动选择不同码率的视频流,条件允许的情况下使用高码率,网络繁忙的时候使用低码率,并且自动在二者间随意切换。这对移动设备网络状况不稳定的情况下保障流畅播放非常有帮助。实现方法是服务器端提供多码率视频流,并且在列表文件中注明,播放器根据播放进度和下载速度自动调整。

至于为什么要用 TS 而不是 MP4,这是因为两个 TS 片段可以无缝拼接,播放器能连续播放,而 MP4 文件由于编码方式的原因,两段 MP4 不能无缝拼接,播放器连续播放两个 MP4 文件会出现破音和画面间断,影响用户体验。

 

 

转载于:https://www.cnblogs.com/Xiegg/p/3330672.html

你可能感兴趣的文章
Flex创建带有空间信息的椭圆(Polygon)
查看>>
【转】参照protobuf,将json数据转换成二进制在网络中传输。
查看>>
wpf 输入停止一段时间后。执行事件
查看>>
享元模式
查看>>
Python中的str与bytes之间的转换的三种方法
查看>>
java异常常见面试问题
查看>>
课后作业5
查看>>
Centos7.1环境下搭建BugFree
查看>>
共用y轴的双图形绘制
查看>>
(错误) Eclipse使用Maven创建Web时错误
查看>>
第31讲 | 数字货币钱包服务
查看>>
P2073 送花
查看>>
iOS端项目注释规范附统一代码块
查看>>
c语言编程的限制,关于NOI系列赛编程语言使用限制的规定
查看>>
32个c语言关键字发音,C语言的32个关键字(读音、用法、注释)转来的,给刚接触C的...
查看>>
为煮酒新书《构建高可用Linux服务器》作序!
查看>>
Windows Azure中文博客 Windows Azure入门教学系列 (一): 创建第一个WebRole程序
查看>>
Linux学习之CentOS(四)----Linux各目录的介绍
查看>>
MySQL 跳过同步错误方法
查看>>
MySQL 清理slowlog方法
查看>>