2019年WebRTC和低延迟流媒体的现状

延迟一直是流媒体行业的一个问题, 就像之前视频会议行业的问题一样. 如何降低时间关键型交付的延迟, 同时允许单向流扩展, 2019年行业面临的五大挑战之一是什么.

立即访问我们的2019年百家乐软件手册. 立即注册免费下载整个问题!

一种可能的方法, 7年后，哪一项最终被提交标准化, 被称为WebRTC (RTC代表实时通信). 本文探讨了2018年底和2019年初WebRTC的状态.

什么是WebRTC?

根据WebRTC.org, 这个项目被称为WebRTC(也被互联网工程任务组称为rtcweb), (或IETF)继续积极地将语音和视频的标准化原生RTC集成到领先的web浏览器中. 原生RTC实现意味着WebRTC通信可以在浏览器内进行，而不需要插件架构(参见图1). 标准化意味着, 在理论上, 浏览器之间的WebRTC通信——无论它们是原生的Android, 铬, iOS, 火狐, 或Opera浏览器，即WebRTC.Org网站列表为兼容-可能发生.

图1:使用WebRTC的简化流媒体工作流程

我们之所以将其称为“理论上”，是因为rtcweb实际上并不是一个标准, 而是关于如何实施IETF针对开源项目WebRTC的建议草案的建议. 话虽如此, IETF与万维网联盟(W3C)合作，为实现WebRTC保持一致的建议，并在一些特定领域扩展了原始工作.

WebRTC的当前状态可以分解为几个组件:应用程序, 实时音频, 实时视频, 安全, 冰, 和眩晕, 或将. 在我们深入研究这些缩写词之前, 虽然, 值得注意的是，rtcweb概述的第19次草案于2017年底提交, 大约在那个时候 2018年关于WebRTC现状的资料书文章是写.

虽然每年通常会提交两份概述草案, 第19份草案于5月16日到期, 2018, 2018年没有“基于浏览器的应用实时协议”第20版草案并不意味着rtcweb已经死了. 远非如此, 第19个草案已提交给IETF下属的互联网工程标准组(IESG), 并建议将其作为标准发布.

鉴于IETF和W3C之间的协作, 随后的委员会工作花了几个月的时间, 但在2018年末, W3C发布了规范WebRTC的文档 (被称为WebRTC 1.2018年9月27日在其网站上作为W3C候选建议发布. 当标准最终获得批准时，详细信息将出现在W3C网站上 www.w3.org/TR/webrtc.

讲清楚了之后, 让我们来看看WebRTC和rtcweb开发的几个关键领域的进展.

WebRTC应用程序和设备

在WebRTC应用程序和设备之间有一个独特的区别. 区别在于JavaScript, 它是许多现代浏览器使用的编程语言，也是iOS应用程序的核心基础, 例如, 以及HTML5和层叠样式表(CSS)——它也被用来控制WebRTC应用程序.

遵守IETF关于rtcweb的建议草案14中提到的WebRTC建议, 一个webtc应用程序必须实现JavaScript. 用IETF的术语来说, 这将是一个基于浏览器的用户代理(WebRTC UA), 其中“符合协议规范和JavaScript API”作为其合规的互操作性.

但是，对于设备类别，没有必要依赖JavaScript. 在IETF术语中，任何webbrtc的非浏览器实现都可以被称为webbrtc设备.

根据IETF的定义, WebRTC非浏览器是符合协议规范的东西, 但它并没有宣称实现了JavaScript API.

当涉及到IETF所谓的WebRTC原生应用程序时，设备和应用程序之间的界限有点模糊. 这类原生应用最常出现在智能手机和平板电脑的软件中, 比如安卓操作系统或苹果的iOS.

Android和iOS应用程序都可以利用JavaScript应用程序编程接口(API)。, 而且还有更健壮的编程语言. c++就是这样一种语言, 它有一个对底层硬件基础设施编程有用的API.

WebRTC音频和视频

第二个状态更新集中在WebRTC音频和视频上.

在视频方面，WebRTC视频有一个IETF 征求意见(RFC)指定rfc7742,而音频有一个单独的名称的rfc7874.

用于WebRTC的视频是从Y 'CbCr 4:2:0颜色空间编码的, 哪个是大多数流媒体优质内容分发使用的相同的本机色彩空间, 从电影和情节到网络摄像头镜头.

视频也分为摄像头捕获的内容和屏幕捕获的内容. 快速浏览一下rfc7742，可以看到一些关于如何处理屏幕捕获内容的有趣注释, 利用多年的学习如何处理说话的头和计算机图形在传统, 基于硬件视频会议.

“因为屏幕源视频可以改变分辨率(由于，例如.g., 窗口大小调整和类似操作), webtc视频接收者必须准备好以保留其效用的方式处理中流分辨率变化,a说。 IETF文档中的符号. 同样的文档, 写于2016年, 同时也挑战了压缩专家解决视频和屏幕捕获颜色空间之间的不匹配，以实现最佳编码.

请注意，默认的视频扫描格式(Y 'CbCr 4:2:0)对于在撰写本文档时使用的大多数系统所产生的屏幕内容的表示来说，并不是最佳的, 它们通常使用RGB，每个样本至少24位.”

IETF文档补充了这一点, 在未来, 更准确的屏幕捕捉交付, “使用针对屏幕内容优化的视频编解码器来表示这类内容可能是明智的.”

WebRTC安全

从2016年到现在已经三年了, 值得注意的是，无论是音频还是视频方面都没有太大变化. 相比之下，在安全方面做了更多的工作.

尤其是在2018年末，市场出现了相当大的波动交互式连接建立(冰)候选协议. 这个透明的候选列表可能包括特定网络接口卡(NIC)及其IP地址的组合, 可用端口(e).g.(8080或3265)，以及该特定网卡上可用的传输协议.

候选人的概念类似于选民在地方选举或大选中有多种选择的概念. 这里有一个主要的区别, 虽然, 是否WebRTC候选人的选择是由基于特定标准的算法控制的. 冰连接候选者面临的一个挑战, 虽然, 单台计算机上的多个网卡与多台计算机上的网卡有什么区别.

请注意，一台计算机可能有多个网络接口(无线、有线等).),” 亚历山大·兹拉特科夫写道在SessionStack中.因此可以分配多个IP地址，每个接口一个.兹拉特科夫在博客中写道, 《百家乐软件》,是一个很好的百家乐软件，不仅可以帮助你理解WebRTC应用程序的JavaScript方面, 以及STUN和TURN如何适应启动WebRTC会话的整个画面.

STUN代表NAT会话遍历实用程序由IETF指定为rfc7675. TURN代表在NAT周围使用中继进行遍历. “NAT”代表网络地址转换.

为了更好地理解STUN和TURN, 首先需要了解任何协议在穿越防火墙到适当的设备或应用程序时所面临的挑战. 将实时通信通过防火墙传送到正确的IP地址的挑战被称为NAT穿越. 从H的早期开始，NAT就一直是企业的一个持续问题.323视频会议时的H.264编解码器首次被引入.

下一个页面