默认
打赏 发表评论 6
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
[观点] WebRTC应该选择H.264视频编码的四大理由
微信扫一扫关注!

前言


微软近日宣布: Edge的ORTC开始支持H.264/AVC。这是目前唯一能够在Firefox、Chrome和Edge之间跨浏览器进行视频通话的方法。VP8和VP9至多能让你在Chrome和Firefox之间建立视频通话。

对实时音视频开发者来说,当开发一个基于WebRTC的产品时,我们应该选择什么样的视频编解码器?去年的时候,答案可能是“VP8”。几个月前,答案可能是“看情况”。现在答案是“除非必须用VP8,否则就用H.264”。

本文以下内容是做出如上决定的四个原因。个人观点,仅供参考!

补充说明


VP8(最新版是VP9)是Google开源的实时音视频框架WebRTC的默认编码标准(相关介绍请参见《开源实时音视频技术WebRTC的现状》),H.264(也称作AVC,最新版是H.265)是以微软和苹果为首的音视频编码争端阵营所支持的标准。

- 关于H.264和VP8的关系请见:即时通讯音视频开发(十七):视频编码H.264、V8的前世今生》;
- 有关WebRTC的资料详情请见:WebRTC实时音视频资料》;
- 更多实时音视频开发资料请见:实时音视频开发》。

理由一:浏览器互操作


如果你希望你的服务能够覆盖尽可能多的浏览器,并且需要视频功能,那么H.264是你正确的选择。再过几个月, H.264将获得所有浏览器厂商的官方支持,并就此一锤定音。

此外,你可以期待苹果首先使用H.264,并在后面再考虑使用VP8,就像微软现在在Edge上所做的那样。

理由二:移动领域


相比于VP8,移动设备更喜欢H.264。视频编解码器消耗相当多资源;为克服这个问题,移动设备使用硬件编解码。他们都支持H.264硬件加速,尽管开发者并不总是能够对此进行编程。许多移动设备商对VP8知之甚少,这归结为移动设备上的WebRTC需要用软件方式实现VP8。

基于这个原因,一些开发者在移动设备上用H.264替换VP8,特别是针对那些只在移动设备上运行的产品。虽然我相信在新的芯片上VP8的性能正在提升,但是在已经存在的数百万个移动设备上支持VP8仍然是个麻烦的问题。既然现在所有浏览器都以各种方式支持H.264,那么开发者为什么还要去支持那些必须使用VP8的移动应用呢?

理由三:遗留视频系统


遗留视频系统主要是视频会议系统,他们使用H.264编解码器,绝大多数不支持VP8。直到今天,他们仍然通过一种特别的网关(MCU)支持WebRTC,或者根本就不支持。

视频转码是WebRTC连通遗留视频系统的主要障碍之一,这非常消耗资源。直接让H.264在运行在各系统上是最容易的办法,也是当前就可以实现的办法。这也是思科用Spark连通Firefox的原因。思科决定在WebRTC中使用H.264,而不是对VP8进行转码。

理由四:流量


互联网上超过60%的流量都是视频。这其中大部分不是实时视频,而是像YouTube或者Netflix这样的非实时视频。如今视频流基本上都是H.264,某些情况下是VP9(YouTube使用VP9编码)。在iPhone上获取视频内容需要HLS协议,这再次意味着必须使用H.264编解码器。

因此我们面临两种选择:当我们想输出视频流时,是把WebRTC生成的视频内容转码成H.264,还是直接在开始就使用H.264生成视频内容。

你是否需要关注?


如果你的视频服务是一对一的会话服务,没有服务器端做视频处理,那么你大可不必关注。在这种场景下,浏览器的最终协商结果对你来说已经足够好了,并且很有可能是该特殊场景下的最佳选择。

如果厂商在服务端视频处理针对VP8进行大量投入,包括视频录制、混合、路由等,那么把这些服务端设备进行改造使其支持H.264可能很重要。对他们来说,转向H.264可能是一个困难的决定,但却是不得不做的决定。

WebRTC视频编解码器的未来?


一旦我们放眼未来,我们可能需要关注VP9。然后就是开放媒体联盟,他们致力于开发一款广泛使用的下一代免专利视频编解码器。从个人角度,我相当讨厌H.264和它代表的一切。但是现在必须承认, 它留了下来,和WebRTC一起发展。

附录:更多实时音视频技术文章


[1] 开源实时音视频技术WebRTC的文章:
开源实时音视频技术WebRTC的现状
简述开源实时音视频技术WebRTC的优缺点
访谈WebRTC标准之父:WebRTC的过去、现在和未来
良心分享:WebRTC 零基础开发者教程(中文)[附件下载]
WebRTC实时音视频技术的整体架构介绍
新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?
WebRTC实时音视频技术基础:基本架构和协议栈
浅谈开发实时视频直播平台的技术要点
[观点] WebRTC应该选择H.264视频编码的四大理由
基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?
开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用
简述实时音视频聊天中端到端加密(E2EE)的工作原理
实时通信RTC技术栈之:视频编解码
开源实时音视频技术WebRTC在Windows下的简明编译教程
网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?
>> 更多同类文章 ……

[2] 实时音视频开发的其它精华资料:
专访微信视频技术负责人:微信实时视频聊天技术的演进
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生
实时语音聊天中的音频处理与编码压缩技术简述
网易视频云技术分享:音频处理与压缩技术快速入门
学习RFC3550:RTP/RTCP实时传输协议基础知识
基于RTMP数据传输协议的实时流媒体技术研究(论文全文)
声网架构师谈实时音视频云的实现难点(视频采访)
浅谈开发实时视频直播平台的技术要点
还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!
实现延迟低于500毫秒的1080P实时音视频直播的实践分享
移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡
如何用最简单的方法测试你的实时音视频方案
技术揭秘:支持百万级粉丝互动的Facebook实时视频直播
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端实时音视频直播技术详解(一):开篇
移动端实时音视频直播技术详解(二):采集
移动端实时音视频直播技术详解(三):处理
移动端实时音视频直播技术详解(四):编码和封装
移动端实时音视频直播技术详解(五):推流和传输
移动端实时音视频直播技术详解(六):延迟优化
理论联系实际:实现一个简单地基于HTML5的实时视频直播
IM实时音视频聊天时的回声消除技术详解
浅谈实时音视频直播中直接影响用户体验的几项关键技术指标
如何优化传输机制来实现实时音视频的超低延迟?
首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?
Android直播入门实践:动手搭建一套简单的直播系统
网易云信实时视频直播在TCP数据传输层的一些优化思路
实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器
>> 更多同类文章 ……

(原文链接:http://www.cnblogs.com/lingyunhu/p/rtc79.html

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:浅谈开发实时视频直播平台的技术要点下一篇:技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)

本帖已收录至以下技术专辑

推荐方案
评论 6
H.264几乎是事实的工业标准,谷歌就是为了分一杯羹非得用这VP8,Yutube如果不是google收购了估计不可能转成vp9标准,扯蛋的商业利益!
签名: 该会员没有填写今日想说内容.
引用:什么狗屁云 发表于 2016-08-15 11:03
H.264几乎是事实的工业标准,谷歌就是为了分一杯羹非得用这VP8,Yutube如果不是google收购了估计不可能转成 ...

商业不就是这样吗,只是苦了码农
感觉H.264现阶段已经够用了,移动设备上支持很好
引用:kydkylin 发表于 2016-08-16 15:34
感觉H.264现阶段已经够用了,移动设备上支持很好

巨头们都是有私心的
感谢楼主分享
感谢
签名: 慢慢
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部