关于视频分段下载的疑问?

最近看youku的视频发现很多大的视频是分段下载的,我想知道的是flash是不是开多个线程同时下载,而且在服务端是否把一个大视频分割成多个小文件才能段下载?而且这种分段下载有什么好处?因为网速就那么快,视频分段和顺序下载相比有什么优势?

Geo5
Geo5
463
编辑于2012-05-07
评论 (0)链接2012-02-15 

视频分段的目的并非是为了让用户多线程下载,恰恰是为了不让用户过快地下载。HTTP协议毕竟不是流媒体协议,很难控制视频传输的速度,设想一个用户在看了整部视频的1/3的时候,决定不看了,可是由于用户的网速很可能快于视频的码流,这时整部视频也许已经全部下载完毕了,那么多下载的2/3流量就被浪费了,这对于目前带宽是主要成本的视频网站来讲显然是不可接受的。因此把视频分段,并在一个视频片段快看完的时候,再去下载下一段视频,是一种简便并且高效的流控手段。

另外一个作用是为了CDN缓存的需要。视频文件普遍比较大,在缓存进内存的时候,会消耗大量的资源,如果缓存节点有多个不同视频文件在被观看,那么把这些文件全部读进内存有可能使系统资源耗尽。只把那些正在被观看的片段缓存起来显然效率更好。

视频服务一般不允许多线程下载,他们的CDN节点遍布全国,带宽和延迟都很有保障,所以没有必要使用多线程下载。把大文件分成多段也不是分段下载的必要条件,保持一个大文件,同时分段请求不同的文件位置也是可以的,只是flash能不能实现就不知了。

补充@邵辉评论

关于视频分段提高CDN缓存效率,还可以设想这样一个简单的模型:一部热播电影上线,视频文件尺寸有1G,装载到一个10台服务器的CDN节点上,有数百个用户同时线观看,由于视频网站大都采用了点播的模式,每个用户观看的进度都是不一样的,如果不采用分段的模式,那么你可能需要把视频文件分发到10台服务器上以均摊负载,每个文件都需要被全部缓存,总共消耗10G的内存。如果把视频分成10段,分别放到10台服务器上来均摊负载,总共就只需要1G内存,差别是9倍。考虑到视频网站同时会有多部影片在被用户观看,不可能所有的视频文件全都装载到内存中,会有大部分视频文件保存在磁盘上,在需要时才被load进内存,那么内存的成倍节省就意味着Memory Hit Ratio的大幅提升,这是一个Cache Server的最重要指标,也是所有CDN系统运行效率的关键。上面只是模型,实际的视频CDN系统未必是这样,有些解决方案不再使用Cache Server,而改用Web Server+Page Cache的方式,效率可能更好,但是分段仍然是提高系统整体效率的有效办法。

Geo5
Geo5
463
编辑于 2012-05-09
该答案已被锁定,无法对其进行评论,编辑及投票。
()
评论 (2)链接 • 2012-05-07
  • 0 支持
    邵辉是亲自架构了iqiyi.com的人,做过和没做过区别可大了,实践中的隐性知识啊。:) – Geo5 2012-05-07
  • 4 支持
    不能这么说,只是认识一些做视频网站的朋友,多少了解一点他们的需求,以前也参与过几个CDN的设计。
    关于视频分段提高CDN缓存效率,还可以设想这样一个简单的模型:一部热播电影上线,视频文件尺寸有1G,装载到一个10台服务器的CDN节点上,有数百个用户同时线观看,由于视频网站大都采用了点播的模式,每个用户观看的进度都是不一样的,如果不采用分段的模式,那么你可能需要把视频文件分发到10台服务器上以均摊负载,每个文件都需要被全部缓存,总共消耗10G的内存。如果把视频分成10段,分别放到10台服务器上来均摊负载,总共就只需要1G内存,差别是9倍。考虑到视频网站同时会有多部影片在被用户观看,不可能所有的视频文件全都装载到内存中,会有大部分视频文件保存在磁盘上,在需要时才被load进内存,那么内存的成倍节省就意味着Memory Hit Ratio的大幅提升,这是一个Cache Server的最重要指标,也是所有CDN系统运行效率的关键。
    上面只是模型,实际的视频CDN系统未必是这样,有些解决方案不再使用Cache Server,而改用Web Server+Page Cache的方式,效率可能更好,但是分段仍然是提高系统整体效率的有效办法。
    – 邵辉 2012-05-08

视频服务器一般不只一个,在后台有很多视频服务器,而同一个视频在服务器上也不可能只有一份,一般会有多个备份。后台服务器一般是按分布式系统分布的,文件在服务器上的存储可以采用云存储。视频分段,可以使同一视频的不同段来自不同的服务器,一方面可以使服务器之间负载均衡,一方面也可以提高下载速度(可以多个分段同时下载)。对服务器而言也相当于进行了数据冗余,提高了数据的安全性和可靠性。

该答案已被锁定,无法对其进行评论,编辑及投票。
()
评论 (4)链接 • 2012-02-15
  • 0 支持
    后端是可以进行分布式存储,但是不分段也是一样可以分布存储,也同样可以进行负载均衡,而至于加快速度,对于前端来说,用户的网速也就那么多,如何提高下载速度? – 浪际天涯 2012-02-15
  • 1 支持
    用户前端的网速是有限,但服务器端也有网速限制呀,你不能保证用户的网速就一定就会被一条视频流占满吧?至于负载均衡,不分段是能分布存储,也可以负载均衡,但分段后可以更好的存储。比如一个刚上传的视频,如果分段的话,可以先把最先的那段放在边缘服务器上,在有用户请求其他段时,在从中心服务器或其他服务器拉数据过来,热门视频就可以慢慢拉到边缘服务器,这样可以提高响应速度,也可以节省一定的空间。当然这样实现起来相对就会复杂些 – donny 2012-02-15
  • 0 支持
    说得很详细,对于前端flash播放器是否可以同时开启多线程下载?我对flash不太了解 – 浪际天涯 2012-02-15
  • 0 支持
    这个当然可以,只是会提高难度,我接触的服务器多点,前端的播放器不是很清楚,可以明天给你问问。 – donny 2012-02-15

将一个大的视频文件分割成若干小文件有诸多的好处,但是首先我们要搞清楚的,是这种做法跟以前的HTTP progressive download本质上的区别是什么。
HTTP progressive download是使用HTTP的断点续传,或者说分段下载功能,在HTTP请求头中用Range指定要下载目标文件的某一段,通过这样的分段下载,在HTTP协议的基础上实现了类似流媒体的边下载边播放。也就是说,在HTTP progressive download里,目标文件的分段是客户端决定的,客户端希望每次请求下载16KB,或是1MB,就按照这样的分段尺寸去请求,服务器就按照这样的尺寸将指定的一段从目标文件读出来发给客户端。
@邵辉所提到的好处,如客户端不过多下载,以及CDN的更好支持,HTTP progressive download就已经具备。所以我们还需要看到,在服务器端把视频文件分割成若干小文件,具体来说也就是Apple的HTTP Live Streaming技术,相对于HTTP progressive download又有哪些进步,为什么要这样做呢?
首先我认为流媒体里一个重要的概念是“粒度”,即传输和处理的最小颗粒是多大。在多数流媒体观念里,传输的粒度通常都是以字节为单位,HTTP progressive download在极限情况下也是有可能以字节为单位进行内容的分段下载。而这显然不是最适合的粒度。因为下载粒度太小,后面解码器无法解码;而下载粒度太大,就失去了流媒体的灵活性。HTTP Live Streaming技术的前提就是认为流媒体传输和处理的粒度应当以GOP为单位,也就是最小粒度为一个GOP,因为GOP是能够在客户端独立进行解码的最小粒度。当用户做seek操作后,客户端请求下来的新的分段如果正好是一个完整的GOP,就可以直接开始解码播放,而不需要额外的等待。
HTTP progressive download中,客户端并不知道目标文件的每个GOP有多大,因此无法实现每次请求正好一个完整的GOP。因此,在服务器端将目标文件预先做好分段,并生成一个列表文件,客户端就可以实现每次按照GOP的粒度进行媒体文件的分段下载。
事实上,在服务器端的文件分割,也并非绝对必须。Adobe公司的HTTP Dynamic Streaming,是在MP4文件头中,将整个文件的分段表内置进去,播放器下载文件头之后就可以获知整个文件的GOP分段偏移,并在接下来的分段请求中做到以GOP为单位。

该答案已被锁定,无法对其进行评论,编辑及投票。
()
评论 (1)链接 • 2012-05-09
  • 1 支持
    从功能上来看,是没有什么必需的理由一定把视频文件切分的,播放器有按GOP来seek的需求,但是只需要把每个GOP在视频文件中的偏移作为metadata发给播放器就可以解决问题了,跟发送play list没有多少区别,并不需要把文件切分。切分文件更多是从效率方面考虑,除了要保持CDN平台的效率,还得考虑在web环境下,保持客户端尽量简单,不用实现太复杂的逻辑。 – 邵辉 2012-05-09

不是您所需,查看更多相关问题与答案

德问是一个专业的编程问答社区,请 登录注册 后再提交答案