HTTP应用流媒体分析
来源:互联网 发布:股票价格统计软件 编辑:程序博客网 时间:2024/06/16 09:10
HTTP应用流媒体分析
严格意义上,基于HTTP的VOD不算是真的流媒体,英文称为“progressive downloading”或者“pseudo streaming”,为什么这样呢?因为HTTP缺乏流媒体基本的流控,由此基于HTTP协议很难实现媒体播放的快进,快退,暂停。那么,通常的媒体播放器又是如何利用HTTP来实现这样的功能呢?
我们都知道,不管媒体文件有多大,HTTP都只是视它为一个HTTP的元素,可以只需要发送一个HTTP请求,WEB Server就会源源不断地将媒体流推送给客户端,而不管客户端是否接受,这就是HTTP协议本身没有流控的原因,那这样会带来什么后果呢?
如果服务器的推流速度和客户端同步, 那么基本不会出现什么大问题;如果小于客户端的接收流的速度,那么播放就会一卡一卡的;如果大于或者远大于客户端的接收速度,那又会是怎么样的结果呢?很不幸,在我们所有的ISTV项目中,只要是基于HTTP的VOD,都无一例外是第三种情况。因为我们VOD是基于局域网的,大家都知道,局域网的带宽资源是很丰富的,服务器的推流的速度肯定大于播放器的播放速度,那么在这么速度极端不协调的情况下,服务器的推流速度究竟由谁来限制呢?
答案是:TCP协议栈。我们的VOD点播是基于TCP的HTTP协议。TCP是安全的,可靠的,包肯定不会丢,服务器检测到客户端的接收缓冲区满了,就会减小发送数据滑动窗口的大小。所以HTTP的流控是通过TCP协议栈来调节的,不是HTTP本身。试想,这样对服务器造成的压力有多大!!!
下面就分析基于HTTP协议如何实现SEEK,PAUSE等操作。
1)SEEK(快进和快退)
先关闭之前的tcp连接,重新连接,发送http请求,该请求带了媒体的偏移位置。由此可见,每一次的快进和快退,都等于是重新开始播放,只是每次开始播放的位置不一样。
2)PAUSE
该操作就更有意思了,客户端暂停了播放,也就是不从缓冲区读取数据了,但是服务器不知道客户端停止了播放,依然不停地发送数据给客户端,直到客户端的接收缓冲区已满,然后服务器的数据发送不出去了,理论上是服务器端的滑动窗口的大小估计就是0了,然后协议栈还在不停在尝试发送数据,因为是基于tcp,这些数据还不能丢。nnd,这种方式实现暂停,协议栈都哭了。很不幸,MPLAYER就是这么干的。所以暂停的时间长了,就容易出现问题。
虽然HTTP没有PAUSE的支持,但是针对PAUSE是可以优化的,优化的方法是,将媒体文件分片,分片的大小以稍小于TCP协议栈的缓冲区大小为宜。HTTP请求一次只请求一个分片的大小,暂停播放后,就不在发送分片请求了。这样可以保证让服务器运行的时间长一些,播放器暂停理论上可以无限长了。
严格意义上,基于HTTP的VOD不算是真的流媒体,英文称为“progressive downloading”或者“pseudo streaming”,为什么这样呢?因为HTTP缺乏流媒体基本的流控,由此基于HTTP协议很难实现媒体播放的快进,快退,暂停。那么,通常的媒体播放器又是如何利用HTTP来实现这样的功能呢?
我们都知道,不管媒体文件有多大,HTTP都只是视它为一个HTTP的元素,可以只需要发送一个HTTP请求,WEB Server就会源源不断地将媒体流推送给客户端,而不管客户端是否接受,这就是HTTP协议本身没有流控的原因,那这样会带来什么后果呢?
如果服务器的推流速度和客户端同步, 那么基本不会出现什么大问题;如果小于客户端的接收流的速度,那么播放就会一卡一卡的;如果大于或者远大于客户端的接收速度,那又会是怎么样的结果呢?很不幸,在我们所有的ISTV项目中,只要是基于HTTP的VOD,都无一例外是第三种情况。因为我们VOD是基于局域网的,大家都知道,局域网的带宽资源是很丰富的,服务器的推流的速度肯定大于播放器的播放速度,那么在这么速度极端不协调的情况下,服务器的推流速度究竟由谁来限制呢?
答案是:TCP协议栈。我们的VOD点播是基于TCP的HTTP协议。TCP是安全的,可靠的,包肯定不会丢,服务器检测到客户端的接收缓冲区满了,就会减小发送数据滑动窗口的大小。所以HTTP的流控是通过TCP协议栈来调节的,不是HTTP本身。试想,这样对服务器造成的压力有多大!!!
下面就分析基于HTTP协议如何实现SEEK,PAUSE等操作。
1)SEEK(快进和快退)
先关闭之前的tcp连接,重新连接,发送http请求,该请求带了媒体的偏移位置。由此可见,每一次的快进和快退,都等于是重新开始播放,只是每次开始播放的位置不一样。
2)PAUSE
该操作就更有意思了,客户端暂停了播放,也就是不从缓冲区读取数据了,但是服务器不知道客户端停止了播放,依然不停地发送数据给客户端,直到客户端的接收缓冲区已满,然后服务器的数据发送不出去了,理论上是服务器端的滑动窗口的大小估计就是0了,然后协议栈还在不停在尝试发送数据,因为是基于tcp,这些数据还不能丢。nnd,这种方式实现暂停,协议栈都哭了。很不幸,MPLAYER就是这么干的。所以暂停的时间长了,就容易出现问题。
虽然HTTP没有PAUSE的支持,但是针对PAUSE是可以优化的,优化的方法是,将媒体文件分片,分片的大小以稍小于TCP协议栈的缓冲区大小为宜。HTTP请求一次只请求一个分片的大小,暂停播放后,就不在发送分片请求了。这样可以保证让服务器运行的时间长一些,播放器暂停理论上可以无限长了。
阅读全文
0 0
- HTTP应用流媒体分析
- HTTP应用流媒体分析
- 分析http应用层
- 自适应 Adapter http live streaming 流媒体实例分析
- 流媒体服务器分析及一般点播应用架构图
- SDP网络流媒体会话信息描述及应用分析二
- hls流媒体、传统流媒体、http流媒体、adobe流媒体
- 应用层协议分析-HTTP
- 流媒体协议—HTTP
- 流媒体技术应用分类
- 流媒体技术及其应用
- 流媒体应用指南
- RTSP流媒体播放分析
- RTSP流媒体播放分析
- OGG流媒体文件格式分析
- RTSP流媒体播放分析
- 流媒体平台分析
- HTTP实现流媒体的原理
- hduBillboard
- android多媒体框架之流媒体框架----base on jellybean(九)
- android多媒体框架之流媒体AHandler消息机制----base on jellybean(十)
- android多媒体框架之流媒体具体流程篇1----base on jellybean(十一)
- android多媒体框架之流媒体具体流程篇3----base on jellybean(十三)
- HTTP应用流媒体分析
- android 视频录像流程[原创]
- 数字版权管理 (DRM)
- MySQL的IF函数
- 数字版权管理 (DRM) 续
- 让android4.0可以通过代理看流媒体 proxy
- 查看安卓(Android)设备处理器(CPU)架构(Architecture)信息
- LeetCode刷题记录 Single Element in A Sorted Array
- Linux动态频率调节系统CPUFreq之二:核心(core)架构与API