WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档

为WebRTC服务选择H.264的四个理由

2019-12-25 06:17:39

H.264被设定为取代VP8成为WebRTC服务的视频编解码器。

微软上周在他们的Edge开发博客上宣布, Edge的ORTC开始支持H.264/AVC。

· 是的,它是ORTC而不是WebRTC

· 是的,它仅通过运行时标志就可以开启

· 是的,它只在Edge浏览器可用,IE浏览器不行

但话又说回来,这是目前唯一能够在Firefox、Chrome和Edge之间跨浏览器进行视频通话的方法。VP8和VP9至多能让你在Chrome和Firefox之间建立视频通话。

这也是我写这篇文章的原因。Edge在ORTC中对H.264的支持并不多。从更大的视角来看,这甚至谈不上有意义。相比于其他浏览器Edge几乎没有市场份额,那么为什么还要为它花费心思呢?但是这件事仍然标志着一个转折——我们应当问自己:当我们要开发一个基于WebRTC的产品时,我们应该选择什么样的视频编解码器。

去年的时候,这个答案可能是“VP8”。

几个月前,答案可能是“看情况”。

现在,答案将会是“除非必须用VP8,否则就用H.264”。

如下,就是这一切发生的四个原因:

1. 浏览器互操作基准

如果你希望你的服务能够覆盖尽可能多的浏览器,并且需要视频功能,那么H.264是你正确的选择。再过几个月, H.264将获得所有浏览器厂商的官方支持,并就此一锤定音。此外,你可以期待苹果首先使用H.264并接下来考虑使用VP8,就像微软现在在Edge上所做的那样。

2. 移动领域

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

基于这个原因,一些开发者在移动设备上用H.264替换VP8,特别是针对那些只在移动设备上运行的产品。

虽然我相信在新的芯片上VP8的性能正在提升,但是在已经存在的数百万个移动设备上支持VP8仍然是个麻烦问题。既然现在所有浏览器都以各种方式支持H.264,那么开发者还有什么动机去支持那些必须使用VP8的移动应用呢?

3. 遗留视频系统

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

视频转码是WebRTC连通遗留视频系统的主要障碍之一,这非常消耗资源。直接让H.264在运行在各系统上是最容易的办法,也是当前就可以实现的办法。

这也是思科用Spark连通Firefox的原因。思科决定在WebRTC中使用H.264,而不是对VP8进行转码。

4.流量

互联网上超过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一起发展。

更多资料可关注官方公众号:编风网(微信ID:befoio)或 WebRTC编风网(微信ID:webrtcorgcn)

By:rasp | WebRTC编码与解码 |

  • 分类目录

    • WebRTC概念与基础 (228)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (14)
    • WebRTC服务端开发 (23)
    • WebRTC网络与通信 (26)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
  • 最新文章

    • WebRTC研究:WebRTC M89关键更新
    • WebRTC Native 源码导读(十五):RTP H.264 封装与解封装
    • 提纲挈领webrtc之vad检测
    • Medooze RTP录制为MP4 源码解析 
    • audio语音相关的基础知识-VAD,ASR,AEC,AGC,BF等
    • 音视频相关的书籍,多媒体技术
    • SFU级联解决方案——Jitsi
    • SFU级联解决方案——Licode
    • Janus源码分析(6)——Streaming分析
    • janus Streaming插件推流指南
    • 流媒体服务器 
    • WebRTC+libwebsockets+Janus的秒开实践
    • 基于WebRTC的直播CDN
    • 不需要SFU实现WebRTC联播实践  
    • webrtc 开启Simulcast功能
    • Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API
    • WebRTC源码分析rfc4588 RTP重传有效载荷格式
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • 自研WebRTC网关服务器架构的实践之路
    • WEBRTC三种类型(Mesh、MCU 和 SFU)的多方通信架构  
    • janus的videoroom插件
    • WebRTC+libwebsockets+Janus的秒开实践
    • Janus源码分析(7)——videoroom分析
    • Janus源码分析(5)——echotest分析
    • Janus源码分析(4)——信令交互过程
    • WebRTC+libwebsockets+Janus的秒开实践
    • 前向纠错码(FEC)的RTP荷载格式
    • WebRTC 开发实践:从一对一通话到多人会议
    • Distord如何使用WebRTC处理250万用户同时进行的音频交流
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.