---

视频基础

我们平常笼统说的「视频格式」其实包含三个部分：视频编码、音频编码、容器格式。

我常所说的.mkv、.mp4、.webm指的是视频文件的容器格式。字面上理解就是他是一个存放视频编码、音频编码的一个容器，再通过特定的方式和规律组织起来，最后呈现给我们一个正常的音画同步的视频播放效果。比如说最常见的 .mp4 文件通常存放的就是H.264编码的视频流和 AAC 编码的音频流。通常，一个容器格式可以包含不同编码格式的音视频流；同样编码的音视频流也可以

VP8/9 与 H264/H265视频编码

VP8与 H264视频编码是目前webRTC支持的两种视频格式（VP9是VP8的最新标准，H265是H264的最新标准）。
VP8是google收购webRTC项目后获得的编码技术，也是google目前强推的编码格式。它常常会被拿来和H264来比较，公认的结果是，不论效率还是质量，VP8是略低于H264的。唯一的优势就是他开源、免费，但是可能存在潜艇专利问题；并且，google虽然开源了VP8，但是部分的相关文件和技术细节并没有公并，以致于Vp8还是一项死死握在google手中的技术。

H264是目前最优秀的视频编码技术。比起VP8不仅拥有效率上的天然优势，还拥有广大硬件厂商的支持。许多硬件只有H264解码器，这表示它们不支持VP8。而且大多硬件厂商也不会浪费成本再安装一个VP8的硬解，这表示未来这些硬件厂家也只支持H264的格式。并且，H264还分有baseline、extended、main、high等多个等级去适应从低端到高端的硬件设备，这也是VP8没有的。

webRTC中的VP8与H264

在webRTC的制定标准中，VP8和H264都应该是被强制支持的，但现实总有些出入。

VP8作为google的自家技术，在webRTC中是默认的视频编码格式。目前几乎主流的现代浏览器都支持VP8,除了apple公司。

由于webRTC支持vp8的最新规范vp9(webRTC还不支持h265)，如果采用vp9录制的同质量视频往往只有h264 20~30%左右的大小。这也是目前使用vp8的优势所在，虽然这代表着更多的cpu、电池消耗，但是这在某些弱网环境下是非常大的优势。但是，如果采用了vp8编码，就是意味着暂时放弃了safari设备。如果你的服务器实现没有实时转码功能的话。

目前来说，h264是唯一一个你不需要服务器转码就可以实现跨平台的编码格式。虽然安卓下的chrome并不支持h264的编码，可以折中的下载一个firefox浏览器。h264的优势不仅仅在于此。目前大部分的视频服务提供商支持的格式大多都是h264。这意味着你如果采用vp8编码，那么你需要另外再编码一个vp8并存储。这对大部分公司而言是可怕的成本。

我个人恶意猜测，safari 与 安卓 chrome 的互相不兼容 h264、vp8只是大佬们的互相博弈。未来vp8、h264应该都会是被全支持的，那时开发者会有更多的选择。而h265因为专利和授权费的问题，可能还要再等一断时间，h264/h265可是很贵的。

webRTC中的音频编码

目前webRTC支持多前音频编码格式，但opus几乎成为了公认的最优选。

Opus是由IETF RFC 6176定义的免版税音频编解码器。它支持从6 kbit / s到510 kbit / s的恒定和可变比特率编码，帧大小从2.5 ms到60 ms，以及8 kHz的各种采样率（带4 kHz带宽）至48 kHz（带宽为20 kHz，可以再现人类听觉系统的整个听觉范围）。

几乎全方面碾压其他webRTC支持的方式(webRTC目前不支持AAC)，唯一的缺点就是他还太年轻。