古狗公布新视频格式WebM VP9 同等画质比H.264编码小63%
转：#Google I/O大会#Google公布新的网络视频格式WebM VP9，同等画质比H.264编码小63%，感觉比H265靠谱啊，H265目前还必须要客户端和很牛B的配置的电脑支持。人家浏览器已经可以跑vp9了，还开源。看来2M带宽流畅播放1080P的时代应该不远了.
http://ww2.sinaimg.cn/bmiddle/67f02417jw1e4pi3y8yahj20g40an0tl.jpg 去年IBC上就有不少公司在弄编码了，2M的高清很轻松
可未来始终是4K接班。。 编码好弄，推广真是太吃力了。 新技术的推广是大问题，Youtube自己的html5都渣到没法用的程度，这些噱头就随便看看，别当真。 瓶颈两个：
- 服务器编码效率
- 浏览器的解码支持
两者不能都解决，那就无法取代H.264 mymy365 发表于 2013-5-16 09:33 static/image/common/back.gif
瓶颈两个：
- 服务器编码效率
- 浏览器的解码支持
瓶颈其实就只有一个，钱。。
yyets压片的童鞋又新苦了
劈马甲 发表于 2013-5-16 12:19 static/image/common/back.gif
yyets压片的童鞋又新苦了
我一直琢磨有没有人做一种压片格式，同一个stream里同时有240p, 480p, 720p, 1080p几种信息，根据带宽和喜好传输，类似jpeg progress那种。这样做出一个文件来，移动上网的下头1/10就可以了，有htpc选择全部下载。 moudy 发表于 2013-5-16 13:05 static/image/common/back.gif
我一直琢磨有没有人做一种压片格式，同一个stream里同时有240p, 480p, 720p, 1080p几种信息，根据带宽和喜 ...
理论上应该是可行的，一个文件相当于是一个container，大装小呗
反正都是2进制，它只要知道哪里去抓它需要的部分就可以了。
快研究弄出来好造福大家 {:5_342:}
moudy 发表于 2013-5-16 12:05 static/image/common/back.gif
我一直琢磨有没有人做一种压片格式，同一个stream里同时有240p, 480p, 720p, 1080p几种信息，根据带宽和喜 ...
致富信息，先把专利注册了吧 劈马甲 发表于 2013-5-16 13:15 static/image/common/back.gif
理论上应该是可行的，一个文件相当于是一个container，大装小呗
反正都是2进制，它只要知道哪里去抓它 ...
理论也不简单吧，关键要没有冗余啊。就是片子以240p打底，480p是240p+补丁，720p是480p+补丁…………
jpeg这么弄好办，反正一副静止画面愿意怎么切怎么切。视频编码各种预测，各种补偿一弄，这补丁真不好打的说。估计能弄个博士学位了吧。 moudy 发表于 2013-5-16 13:05 static/image/common/back.gif
我一直琢磨有没有人做一种压片格式，同一个stream里同时有240p, 480p, 720p, 1080p几种信息，根据带宽和喜 ...
视频格式里做带宽侦测应该是很麻烦，还是把带宽侦测放到单独的module里写代码更灵活，然后发给客户端相应码率的视频流，目前Youtube的HTML5 Video感觉不给力的原因不在于视频格式的大小，可能是因为被调用的几率太低，CDN分布不够给力。VP9的优势就是能帮助大流量的网站节省流量成本。 moudy 发表于 2013-5-16 13:30 static/image/common/back.gif
理论也不简单吧，关键要没有冗余啊。就是片子以240p打底，480p是240p+补丁，720p是480p+补丁…………
jp ...
那肯定的不会简单，人家一个编码就那么多人研究那么些年呢
你这个全揉一块儿随意缩放，弄一个博士都不算多啊 {:2_232:}
moudy 发表于 2013-5-16 13:05 static/image/common/back.gif
我一直琢磨有没有人做一种压片格式，同一个stream里同时有240p, 480p, 720p, 1080p几种信息，根据带宽和喜 ...
各种流媒体服务器都可以实现这个功能。 VP8的瓶颈之一就在于编码时间过长，所以这是很不讨好的。
这就导致了，该格式无法用于直播，按照目前的用户体验，延迟在30秒-1分钟是撑死了，如果你弄一个直播，结果延迟达到3分钟，那是10年前的直播标准，放到今天就没有意义了。
而客户端浏览器不支持，那么再怎么折腾都没戏，你不能要求用户全部都安装某一个特定的浏览器。
即使是YouTube这种视频网站，如果客户上传一个视频，编码需要超过几个小时，这是跟时代潮流背道而驰了。 weltall 发表于 2013-5-16 13:29 static/image/common/back.gif
致富信息，先把专利注册了吧
类似的专利已经有很多，欧洲或者美国。 tkkk3 发表于 2013-5-16 13:34 static/image/common/back.gif
视频格式里做带宽侦测应该是很麻烦，还是把带宽侦测放到单独的module里写代码更灵活，然后发给客户端相应 ...
你换个浏览器就行了，YouTube的HTML5视频格式并不是只有WebM，H.264是同样被支持的，所以不存在不给力之说。 mymy365 发表于 2013-5-16 13:52 static/image/common/back.gif
各种流媒体服务器都可以实现这个功能。
求科普
moudy 发表于 2013-5-16 14:47 static/image/common/back.gif
求科普
比如RTMP服务器的多码率，最简单的，你看CNTV的许多电视剧的视频，还有搜狐的电影的视频，都是RTMP的，德国的话好像ZDF的也是。（这是前几年的研究，今年没把重心放在这个上面，所以可能会有些更改。）
这些视频都支持动态码率切换，也就是你在流畅/高清/超清之间的实时随意切换。而这个应用最简单的实现原理，就是分别生成比如450K，700K，1500K的三个文件，然后编写目录文件，把他们打包导入服务器，即可，当用户选择或者更改清晰度时，就能够无缝即时切换。此外，很多客户端的播放器软件，比如JW Player就支持实时带宽测侦测并调整码率（- 这个播放器目前算是使用最广泛的了，作者有点能力，YouTube最早的播放器就是他写的。）
而更复杂的一些的呢，包括已经基本淘汰的Windows Media Server以及Real的Server服务，都支持实时的编码转换。也就是说，一个1500K的文件源，可以给你实时转成450K的流输出，当然这个硬件开销比较大，现在很少有人再干这种事情了。
一些相关内容你可以根据关键字：flash media server multi bitrate 搜索，或者搜索 HTTP动态流
mymy365 发表于 2013-5-16 14:04 static/image/common/back.gif
你换个浏览器就行了，YouTube的HTML5视频格式并不是只有WebM，H.264是同样被支持的，所以不存在不给力之说 ...
这个和浏览器没关系吧，同一个video，VP8的buffer的速度要比flash慢的明显的多。 tkkk3 发表于 2013-5-16 15:26 static/image/common/back.gif
这个和浏览器没关系吧，同一个video，VP8的buffer的速度要比flash慢的明显的多。
这种视频，如果服务器源相同，那么buffer速度只跟你的网速和浏览器有关。
我是说，YouTube切换到HTML5模式并非必定给你的是WebM视频，它也是根据浏览器的支持判断的，当然你也可以人为强行设定。如果同样是H.264视频，那么就不存在缓冲的区别。
如果视频格式不同，如你所说，可能是CDN结点不同，确实有一定的差异，但是仅仅在准备播放的时候才能看出来，只要你的网络没问题，那么CDN的影响并不大，无论服务器是在北美还是在荷兰或者德国。
而且，VP8的视频号称比H.264体积小，那么应该缓冲更快才对。我说VP8的性能差，主要是编码方面，要想达到它所号称的体积优势，需要比H.264的编码过程多花好几倍的时间。对于现在的字幕组，谁有心情去陪它慢慢耗。 mymy365 发表于 2013-5-16 15:10 static/image/common/back.gif
比如RTMP服务器的多码率，最简单的，你看CNTV的许多电视剧的视频，还有搜狐的电影的视频，都是RTMP的，德 ...
这几种实现我知道的。它们的基本设定是服务器同时提供480p，720p，1080p等不同分辨率的流，客户端根据情况自己动态选择。这样对服务器压力较大(数据冗余好几份)。
我想的是服务器提供480p, 480->720补丁，720->1080补丁，三种流，那客户端根据情况自己决定是只接收480的数据，还是480+额外的补丁流，在客户端上综合成720或1080数据。好处是服务器减负，客户端完全自己决定怎么弄。如果把这几种流存成一个本地文件，那么改分辨率就是分分钟的remix，不需要transcoding。
不过这样把一个流拆成两个流，数据一致性，同步都是讨厌的问题。尤其是传输过程中掉包就乱套了。 moudy 发表于 2013-5-16 16:06 static/image/common/back.gif
这几种实现我知道的。它们的基本设定是服务器同时提供480p，720p，1080p等不同分辨率的流，客户端根据情况 ...
基本不牵涉到任何数据处理，对服务器基本不存在压力，现在最廉价的就是存储了。
你知道现在的YouTube这些视频的快进栏的缩略图是怎么实现的么？当然不可能是实时给你截取的。再次强调，现在最不值钱的就是存储。。。
至于你说的那种方式，基本没有意义，先不说各种编码格式下，这种所谓的补丁能否实现，就算能够实现，造成的硬件开销远比准备三份要高得多得多，效率也受影响。。。除非是无损视频传输，可能会有一些意义，但是如果都已经无损了，那么带宽就不是需要去考虑的问题了啊。 mymy365 发表于 2013-5-16 16:43 static/image/common/back.gif
基本不牵涉到任何数据处理，对服务器基本不存在压力，现在最廉价的就是存储了。
你知道现在的YouTube这些 ...
存储是没有压力，数据冗余指的是带宽上的压力以及transcoding的压力。你看youtube上传个视频，先转240p，再转480，然后720，最后1080。一组task跑下来两个小时算快的。如果用这种办法可以直奔1080p去，然后剩下的各种格式都是附带产出。 moudy 发表于 2013-5-16 17:33 static/image/common/back.gif
存储是没有压力，数据冗余指的是带宽上的压力以及transcoding的压力。你看youtube上传个视频，先转240p， ...
额，你可能把这个想简单了。。。
YouTube的这个首先是要追求效率，H.264的视频，转换对硬件开销并不高。
你看YouTube的做法也是先出一个一般清晰度的，然后再出高清晰度的。其实对于一些热门视频，那么服务器会在接下来的几天，对各种清晰度再做个优化。
因为现在带宽和存储成本都不高，你别看YouTube天天嚷着说带宽好贵，其实他们的带宽成本很低很低很低的。。。
瓶颈就在速度和硬件开销上面，所以说，像YouTube这样是一个比较平衡的做法，先粗略的出一个版本，让大家能看着，然后再慢慢的出高清版本，对于非热门资源，那么是不需要回炉重造的，因为这个成本不值得，只有热门资源，通过二次回路，无论在用户体验，还是各种方面才值得这么去干。
我们打个通俗的比方，如果要速度，那么1-Pass编码就行了，具体的编码时间我现在忘记了，因为有年头没搞这个东西了，但是可以告诉你很快很快，这也是为什么现在的视频网站都选择H.264做直播编码，因为这个必须要达到1:1的速度，就是说1分钟的视频，最多只需要1分钟编码处理完毕。
但是如果追求一个速度/质量最佳化，那么就需要2-Pass编码或者更高，那么这样一来，就无法做直播视频了。
操蛋的VP8编码效率很低很低，你1分钟的视频，5分钟也搞不定，这种慢工出细活的事情，在网络应用当中就不可取，YouTube如果每分钟上传1000分钟的视频，那么如果我真的弄5000个线程去做这个事情，这硬件成本忒高了。。。
而你说的那个也一样，你说的那种模式即使能够实现，短期内是不可能做到1:1的，甚至1:10都不够。那么好了，同样每分钟1000分钟的上传，我用H.264，三种码率，只需要2000到3000个线程，用你说的这种自适应多码率加补丁，我得10000个线程，你说YouTube该如何抉择？ moudy 发表于 2013-5-16 17:33 static/image/common/back.gif
存储是没有压力，数据冗余指的是带宽上的压力以及transcoding的压力。你看youtube上传个视频，先转240p， ...
现在的硬盘的价格你也知道， 甭管是RAID 012345，摊到每个G就那么一点钱。。。
CDN的价格也并非很高
如果是自己的服务器的话，比如说欧洲骨干网的带宽，今年价格又降了，1G的价格普遍在200欧以内，这是普通客户哦，对于Google这种客户，成本是低的多的多的，1G带宽，也就是说如果都是1M的高清，平均1000人同时在线毫无问题，如果这1000人平均同时在线都收不回来200欧的成本，那就别混了。。。
硬件方面，视频编码需要的成本并非很高。
所以主要的瓶颈就集中在了编码效率这一块。这个东西你还是没法并行作业的，现在所谓的并行，也就是比如能够把10分钟的视频，分成5个2分钟的，然后5个线程一起跑，但是你不能说一个线程跑第一遍的同时，另一个线程跑第二遍，这是做不到的，必须得等第一遍跑完了，数据都出来了，第二遍才能起跑。
所以说你说的东西，这个概念可能很丰满，而且类似的专利已经有很多很多，无论在欧洲还是美国，因为很多人也都专门研究网络视频流传输的。但是现实很骨感，VP8就是个例子。确实，你可能压缩率很高，但是你的效率不行呀，我不可能为了节约那么一丁点的带宽成本，却要搭上更多的硬件成本。 mymy365 发表于 2013-5-16 17:59 static/image/common/back.gif
额，你可能把这个想简单了。。。
YouTube的这个首先是要追求效率，H.264的视频，转换对硬件开销并不高。 ...
youtube没有你说的这么挑剔，你上传高清视频，它就老老实实的做1080p版本。现在还有3D版，保不准3-5年后还会有4K版本。transcoding和带宽是它的成本核心，前者是电费和机时费，后者是网费。在这两个方面能省5%就是不得了的数字了。
至于编码，我做过gpu加速的jpeg编码器，16x16 dct变换近似整数算法并行起来毫无压力。h264用的256block更是gpu的菜。如果搞出video progressive的算法，速度可能就比单独压1080p高一点点，把头两步downsample dct换成阶梯状dct downsample就可以了。总成本应该是胜过分开编240p 480p 720p 1080p几个版本的。但是后面是一堆的工程问题，都解决下来成本上肯定划不来。 moudy 发表于 2013-5-17 11:06 static/image/common/back.gif
youtube没有你说的这么挑剔，你上传高清视频，它就老老实实的做1080p版本。现在还有3D版，保不准3-5年后 ...
我什么时候说YouTube挑剔了。。。你上传高清，它也会编码低清晰度的版本的，对于网络视频，让用户等待的时间尽可能短，这是很重要的，哪怕是先出来一个低清晰度的版本。
至于编码，你说的也只是一种猜测，因为目前并没有这种算法，我们无法评估实际性能。我们姑且假设它的硬件开销会小于分开编码，那么最终意义何在？目的是什么？
- 如果是存储，这个说过了，这个不重要
- 如果是编码，这个有待考量
- 如果是带宽，你忽略了一点，无论是直接传1M的还是，450K+补丁，这两者没有区别。你想说你说的是240P，480P。。。但是回到根本，是比特率的区别。而比特率是固定的。所以对于节省带宽，并没有太大的帮助。
- 我能想到的好处，就是补丁可以通过第二个线程传输，但是这就需要客户端进行支持，而且增加了客户端的硬件开销，这显而易见是很难实现的。而且如果只是想多线程，现有的其他方式的多线程，性能或许会更好，所以并没有必要去弄这么个新东西。
- 我能想到的另外一个好处，就是降低缓冲等待的时间，也就是用户比如拖放或快进或换台，那么可以低比特率的数据先进来，然后高清晰度的补丁再过来。但是首先，如果以后都是千兆接入了，那么这个似乎又没有意义了。其次，最重要的一点，写到这里我想起来，去年查过，已经有了类似的专利。而且印象深刻比较有意思的是有看过一个中文的Paper，我不记得是国内的还是哪里的了，是一个多通道多关键帧的概念，也就是两个通道分别处理数据，比如480P的源，隔行分离，每个都是240P，如果你只需要240P的，那么随便哪一个通道的数据都可以，如果你想要480P的，那么两个通道的画面合成就行了。对于数据冗余等等，也有一些介绍。。。。是不是跟你的想法有点相似的感觉？ mymy365 发表于 2013-5-17 12:43 static/image/common/back.gif
我什么时候说YouTube挑剔了。。。你上传高清，它也会编码低清晰度的版本的，对于网络视频，让用户等待的时 ...
你这第一点是对的，这样编码加快了高分辨率的速度，但是减慢了低分辨率的速度，也许还是严重减慢了。
第二个好处应该是主要好处。针对的是手机用户和低分辨率用户。他们用不到大码率，直接选基本流就是了。
至于多线程下载，说实话应该是缺点。万一带宽不够，补丁流把基本流给挤断了就好玩了。另外现在都是动态编码，两个流同步就够客户端喝一壶的了。
罢了罢了，说说玩算了。
页:
[1]