古狗公布新视频格式WebM VP9 同等画质比H.264编码小63%

mymy365

tkkk3 发表于 2013-5-16 15:26
这个和浏览器没关系吧，同一个video，VP8的buffer的速度要比flash慢的明显的多。

这种视频，如果服务器源相同，那么buffer速度只跟你的网速和浏览器有关。
我是说，YouTube切换到HTML5模式并非必定给你的是WebM视频，它也是根据浏览器的支持判断的，当然你也可以人为强行设定。如果同样是H.264视频，那么就不存在缓冲的区别。
如果视频格式不同，如你所说，可能是CDN结点不同，确实有一定的差异，但是仅仅在准备播放的时候才能看出来，只要你的网络没问题，那么CDN的影响并不大，无论服务器是在北美还是在荷兰或者德国。
而且，VP8的视频号称比H.264体积小，那么应该缓冲更快才对。我说VP8的性能差，主要是编码方面，要想达到它所号称的体积优势，需要比H.264的编码过程多花好几倍的时间。对于现在的字幕组，谁有心情去陪它慢慢耗。

moudy

mymy365 发表于 2013-5-16 15:10
比如RTMP服务器的多码率，最简单的，你看CNTV的许多电视剧的视频，还有搜狐的电影的视频，都是RTMP的，德 ...

这几种实现我知道的。它们的基本设定是服务器同时提供480p，720p，1080p等不同分辨率的流，客户端根据情况自己动态选择。这样对服务器压力较大(数据冗余好几份)。

我想的是服务器提供480p, 480->720补丁，720->1080补丁，三种流，那客户端根据情况自己决定是只接收480的数据，还是480+额外的补丁流，在客户端上综合成720或1080数据。好处是服务器减负，客户端完全自己决定怎么弄。如果把这几种流存成一个本地文件，那么改分辨率就是分分钟的remix，不需要transcoding。

不过这样把一个流拆成两个流，数据一致性，同步都是讨厌的问题。尤其是传输过程中掉包就乱套了。

mymy365

moudy 发表于 2013-5-16 16:06
这几种实现我知道的。它们的基本设定是服务器同时提供480p，720p，1080p等不同分辨率的流，客户端根据情况 ...

基本不牵涉到任何数据处理，对服务器基本不存在压力，现在最廉价的就是存储了。
你知道现在的YouTube这些视频的快进栏的缩略图是怎么实现的么？当然不可能是实时给你截取的。再次强调，现在最不值钱的就是存储。。。
至于你说的那种方式，基本没有意义，先不说各种编码格式下，这种所谓的补丁能否实现，就算能够实现，造成的硬件开销远比准备三份要高得多得多，效率也受影响。。。除非是无损视频传输，可能会有一些意义，但是如果都已经无损了，那么带宽就不是需要去考虑的问题了啊。

moudy

mymy365 发表于 2013-5-16 16:43
基本不牵涉到任何数据处理，对服务器基本不存在压力，现在最廉价的就是存储了。
你知道现在的YouTube这些 ...

存储是没有压力，数据冗余指的是带宽上的压力以及transcoding的压力。你看youtube上传个视频，先转240p，再转480，然后720，最后1080。一组task跑下来两个小时算快的。如果用这种办法可以直奔1080p去，然后剩下的各种格式都是附带产出。

mymy365

moudy 发表于 2013-5-16 17:33
存储是没有压力，数据冗余指的是带宽上的压力以及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该如何抉择？

mymy365

moudy 发表于 2013-5-16 17:33
存储是没有压力，数据冗余指的是带宽上的压力以及transcoding的压力。你看youtube上传个视频，先转240p， ...

现在的硬盘的价格你也知道， 甭管是RAID 012345，摊到每个G就那么一点钱。。。
CDN的价格也并非很高
如果是自己的服务器的话，比如说欧洲骨干网的带宽，今年价格又降了，1G的价格普遍在200欧以内，这是普通客户哦，对于Google这种客户，成本是低的多的多的，1G带宽，也就是说如果都是1M的高清，平均1000人同时在线毫无问题，如果这1000人平均同时在线都收不回来200欧的成本，那就别混了。。。
硬件方面，视频编码需要的成本并非很高。
所以主要的瓶颈就集中在了编码效率这一块。这个东西你还是没法并行作业的，现在所谓的并行，也就是比如能够把10分钟的视频，分成5个2分钟的，然后5个线程一起跑，但是你不能说一个线程跑第一遍的同时，另一个线程跑第二遍，这是做不到的，必须得等第一遍跑完了，数据都出来了，第二遍才能起跑。
所以说你说的东西，这个概念可能很丰满，而且类似的专利已经有很多很多，无论在欧洲还是美国，因为很多人也都专门研究网络视频流传输的。但是现实很骨感，VP8就是个例子。确实，你可能压缩率很高，但是你的效率不行呀，我不可能为了节约那么一丁点的带宽成本，却要搭上更多的硬件成本。

moudy

mymy365 发表于 2013-5-16 17:59
额，你可能把这个想简单了。。。
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几个版本的。但是后面是一堆的工程问题，都解决下来成本上肯定划不来。

mymy365

moudy 发表于 2013-5-17 11:06
youtube没有你说的这么挑剔，你上传高清视频，它就老老实实的做1080p版本。现在还有3D版，保不准3-5年后 ...

我什么时候说YouTube挑剔了。。。你上传高清，它也会编码低清晰度的版本的，对于网络视频，让用户等待的时间尽可能短，这是很重要的，哪怕是先出来一个低清晰度的版本。
至于编码，你说的也只是一种猜测，因为目前并没有这种算法，我们无法评估实际性能。我们姑且假设它的硬件开销会小于分开编码，那么最终意义何在？目的是什么？
- 如果是存储，这个说过了，这个不重要
- 如果是编码，这个有待考量
- 如果是带宽，你忽略了一点，无论是直接传1M的还是，450K+补丁，这两者没有区别。你想说你说的是240P，480P。。。但是回到根本，是比特率的区别。而比特率是固定的。所以对于节省带宽，并没有太大的帮助。

- 我能想到的好处，就是补丁可以通过第二个线程传输，但是这就需要客户端进行支持，而且增加了客户端的硬件开销，这显而易见是很难实现的。而且如果只是想多线程，现有的其他方式的多线程，性能或许会更好，所以并没有必要去弄这么个新东西。

- 我能想到的另外一个好处，就是降低缓冲等待的时间，也就是用户比如拖放或快进或换台，那么可以低比特率的数据先进来，然后高清晰度的补丁再过来。但是首先，如果以后都是千兆接入了，那么这个似乎又没有意义了。其次，最重要的一点，写到这里我想起来，去年查过，已经有了类似的专利。而且印象深刻比较有意思的是有看过一个中文的Paper，我不记得是国内的还是哪里的了，是一个多通道多关键帧的概念，也就是两个通道分别处理数据，比如480P的源，隔行分离，每个都是240P，如果你只需要240P的，那么随便哪一个通道的数据都可以，如果你想要480P的，那么两个通道的画面合成就行了。对于数据冗余等等，也有一些介绍。。。。是不是跟你的想法有点相似的感觉？

moudy

mymy365 发表于 2013-5-17 12:43
我什么时候说YouTube挑剔了。。。你上传高清，它也会编码低清晰度的版本的，对于网络视频，让用户等待的时 ...

你这第一点是对的，这样编码加快了高分辨率的速度，但是减慢了低分辨率的速度，也许还是严重减慢了。
第二个好处应该是主要好处。针对的是手机用户和低分辨率用户。他们用不到大码率，直接选基本流就是了。
至于多线程下载，说实话应该是缺点。万一带宽不够，补丁流把基本流给挤断了就好玩了。另外现在都是动态编码，两个流同步就够客户端喝一壶的了。

罢了罢了，说说玩算了。