Zoom的Web客户端和WebRTC有什么关系
zoom是非常出色的视频会议平台，拿zoom的web客户端和webrtc对比似乎有失公允。重要的是，未来webrtc还会不断做明智的改进。
zoom有一个web客户端，允许参与者在不下载他们的app的情况下参加会议。打开chrome://webrtc-internals显示只有getusermedia用于访问相机和麦克风，但是没有像webrtc那样调用rtcpeerconnection。这让我很感兴趣-他们没有使用webrtc是如何打电话的？
为什么不使用webrtc？
就像他们的网站上所说的那样，zoom和webrtc的关系比较复杂。
jitsi团队最近通过比较质量回应了这件事。tsahi levent levi也对此发表了一些有用的评论。因此，让我们在chrome中运行这种非常有趣的环境下快速查看这些“优秀特性”。
zoom web客户端
chrome网络开发者工具迅速显示了两件事：
websocket用于数据传输
这是一些工作人员加载的webassembly (wasm) 文件
基于websocket的媒体传输
基于websocket的媒体传输整体设计非常有趣。它使用websocket传输媒体，这当然不是最佳选择。类似于webrtc中的turn/tcp——它会影响传输质量，并且在很多情况下都不能很好地工作。使用tcp传输实时媒体的一般问题是丢包，这会导致重新发送和增加延迟。tsahi前一段时间在testrtc上描述了这一点，显示了使用这种方案对比特率和其他特性的影响。
基于websocket传输媒体最主要的优势在于，它可以在turn/tcp和turn/tls被防火墙阻塞时，穿过防火墙。它避免了webrtc trun连接不经过认证代理的问题。这是chrome webrtc实施中长期存在的问题，去年才得到解决。
在websocket上接收的数据进入基于webassembly (wasm)的解码器。浏览器中的audiowrklead获取到音频数据。从那里，解码的音频使用webaudio“magic”目的节点播放。
视频被渲染出来，这个过程出乎意料的顺利，质量也非常高。
另一方面，webaudio通过getusermedia调用捕获媒体数据，发送给webassembly编码器编码，然后通过websocket传输。640*360分辨率的视频数据在发送给webassembly编码器之前从画布中获取到，这是非常常见的。
wasm文件似乎包含与zooms本地客户端相同的编码器和解码器，这意味着网关不必进行转码。相反，它可能只是一个websocet-rtp中继，类似于转换服务器。编码的视频有时有些像素化。虽然编码器的cpu使用率相当高（在640×360分辨率），但这可能并不重要，因为用户可能将问题归咎于chrome，并在下次使用客户端。
h.264
使用webassembly提供媒体引擎是非常有趣的，它允许支持chrome／webrtc不支持的编解码器。用emscripten编译的ffmpeg以前已经做了很多次了，这里似乎也使用了emscripten。通过websockets传输编码后的数据，可以使用chrome优秀的调试工具检查rtp头和一些帧来显示h264荷载。
令我惊讶的是，网络抽象层单元（nalu）没有表示h264-svc。
和webrtc的比较：
总之，让我们比较一下chrome在本例中使用的与webrtc标准（w3c或者各种ietf草案）不同的地方：
特性 zoom web client webrtc/rtcweb specifications
加密 基于安全websocket的rtp dtls-srtp
数据通道 n/a? sctp-based
ice n/a for websocket rfc 5245 (rfc 8445)
audio codec 未知 opus
多码流 未研究 chrome实现
simulcast 在web client上未研究 扩展特性
webrtc下一版
尽管webrtc 1.0还远远没有完成（而且大多数开发人员仍在使用被称为“遗留api”的东西），但是关于“下一个版本”的讨论仍然很多。
zoom网络客户端的总体设计强烈地提醒了我，在今年早些时候在斯德哥尔摩召开的工作组面对面会议上，google的peter thatcher为webrtc nv提出的建议。请参阅幻灯片（https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/webrtcwg-2018-06-19.pdf）。
如果我们要在2018重建webrtc，我们可能已经采取了类似的方法来分离组件。基本上采取以下步骤：
编译用于wasm的webrtc.org编码器/解码器。
将解码器与画布连接，webaudio用于”布局”
将编码器和getusermedia连接用于输入
将编码后的数据通过不可靠的信道发送
以某种方式连接rtcdatachannel反馈度量和音频/视频编码器
该方法是从工作组会议幻灯片中看到的：
与zoom方法相比，该方案具有非常明显的技术优势。例如，使用rtcdatachannels传输数据，这比websocket具有更好的拥塞控制特性，特别是当存在分组丢失时。
该设计的最大优点是可以将编码器和解码器（以及相关的东西，如rtp打包）与浏览器分离，从而允许定制版本。主要问题是找到一种好的方法，以包括硬件加速的高性能方式使数据处理脱离主线程。这是chrome早期面临的一大挑战，我记得很多关于沙箱让事情变得困难的抱怨。zoom看起来很好，但是我们只尝试了1:1的聊天，而典型的webrtc应用程序比这个要求更高一些。重用像mediastreamtrack这样的构建块来进行从工人到工人的数据传输也比使用canvas元素和webaudio要好。
2021年三星手机的整体出货量或继续下降
小米12月28日发布会：只讲技术，不发产品
高通高管表示：骁龙888将不支持AC1视频技术
西安大学在柔性可穿戴设备研究领域更进一步
关于氮(氧)化硅湿法刻蚀后清洗方式的改进
Zoom的Web客户端和WebRTC有什么关系
日本东芝进军海外核电行业计划提上日程
中国电信、中国联通日前开启 5G 消息中心联合公开测试
激光雷达-无人机定高产品的推陈出新
有哪一些款式的MOS管是比较常用于电机控制呢？
PCB电磁兼容设计关键的三个要点
水质监测站的监测指标及其特点的介绍
电动汽车对于悬架的要求会不会比较高
CHINAPLAS线上展会今日盛大启动 足不出户发现全球热点橡塑科技
测量仪器的原理及制作
DeviceNet主站与Modbus TCP主站之间的数据交换
WAVE SUMMIT 2022深度学习开发者峰会在线上举行
数智融合，兆越通讯赋能智慧城轨发展
一键掌控多媒体：中央控制系统的便利性
用ML4835设计室内可调光小型荧光灯电子镇流器
zoom有一个web客户端，允许参与者在不下载他们的app的情况下参加会议。打开chrome://webrtc-internals显示只有getusermedia用于访问相机和麦克风，但是没有像webrtc那样调用rtcpeerconnection。这让我很感兴趣-他们没有使用webrtc是如何打电话的？
为什么不使用webrtc？
就像他们的网站上所说的那样，zoom和webrtc的关系比较复杂。
jitsi团队最近通过比较质量回应了这件事。tsahi levent levi也对此发表了一些有用的评论。因此，让我们在chrome中运行这种非常有趣的环境下快速查看这些“优秀特性”。
zoom web客户端
chrome网络开发者工具迅速显示了两件事：
websocket用于数据传输
这是一些工作人员加载的webassembly (wasm) 文件
基于websocket的媒体传输
基于websocket的媒体传输整体设计非常有趣。它使用websocket传输媒体，这当然不是最佳选择。类似于webrtc中的turn/tcp——它会影响传输质量，并且在很多情况下都不能很好地工作。使用tcp传输实时媒体的一般问题是丢包，这会导致重新发送和增加延迟。tsahi前一段时间在testrtc上描述了这一点，显示了使用这种方案对比特率和其他特性的影响。
基于websocket传输媒体最主要的优势在于，它可以在turn/tcp和turn/tls被防火墙阻塞时，穿过防火墙。它避免了webrtc trun连接不经过认证代理的问题。这是chrome webrtc实施中长期存在的问题，去年才得到解决。
在websocket上接收的数据进入基于webassembly (wasm)的解码器。浏览器中的audiowrklead获取到音频数据。从那里，解码的音频使用webaudio“magic”目的节点播放。
视频被渲染出来，这个过程出乎意料的顺利，质量也非常高。
另一方面，webaudio通过getusermedia调用捕获媒体数据，发送给webassembly编码器编码，然后通过websocket传输。640*360分辨率的视频数据在发送给webassembly编码器之前从画布中获取到，这是非常常见的。
wasm文件似乎包含与zooms本地客户端相同的编码器和解码器，这意味着网关不必进行转码。相反，它可能只是一个websocet-rtp中继，类似于转换服务器。编码的视频有时有些像素化。虽然编码器的cpu使用率相当高（在640×360分辨率），但这可能并不重要，因为用户可能将问题归咎于chrome，并在下次使用客户端。
h.264
使用webassembly提供媒体引擎是非常有趣的，它允许支持chrome／webrtc不支持的编解码器。用emscripten编译的ffmpeg以前已经做了很多次了，这里似乎也使用了emscripten。通过websockets传输编码后的数据，可以使用chrome优秀的调试工具检查rtp头和一些帧来显示h264荷载。
令我惊讶的是，网络抽象层单元（nalu）没有表示h264-svc。
和webrtc的比较：
总之，让我们比较一下chrome在本例中使用的与webrtc标准（w3c或者各种ietf草案）不同的地方：
特性 zoom web client webrtc/rtcweb specifications
加密 基于安全websocket的rtp dtls-srtp
数据通道 n/a? sctp-based
ice n/a for websocket rfc 5245 (rfc 8445)
audio codec 未知 opus
多码流 未研究 chrome实现
simulcast 在web client上未研究 扩展特性
webrtc下一版
尽管webrtc 1.0还远远没有完成（而且大多数开发人员仍在使用被称为“遗留api”的东西），但是关于“下一个版本”的讨论仍然很多。
zoom网络客户端的总体设计强烈地提醒了我，在今年早些时候在斯德哥尔摩召开的工作组面对面会议上，google的peter thatcher为webrtc nv提出的建议。请参阅幻灯片（https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/webrtcwg-2018-06-19.pdf）。
如果我们要在2018重建webrtc，我们可能已经采取了类似的方法来分离组件。基本上采取以下步骤：
编译用于wasm的webrtc.org编码器/解码器。
将解码器与画布连接，webaudio用于”布局”
将编码器和getusermedia连接用于输入
将编码后的数据通过不可靠的信道发送
以某种方式连接rtcdatachannel反馈度量和音频/视频编码器
该方法是从工作组会议幻灯片中看到的：
与zoom方法相比，该方案具有非常明显的技术优势。例如，使用rtcdatachannels传输数据，这比websocket具有更好的拥塞控制特性，特别是当存在分组丢失时。
该设计的最大优点是可以将编码器和解码器（以及相关的东西，如rtp打包）与浏览器分离，从而允许定制版本。主要问题是找到一种好的方法，以包括硬件加速的高性能方式使数据处理脱离主线程。这是chrome早期面临的一大挑战，我记得很多关于沙箱让事情变得困难的抱怨。zoom看起来很好，但是我们只尝试了1:1的聊天，而典型的webrtc应用程序比这个要求更高一些。重用像mediastreamtrack这样的构建块来进行从工人到工人的数据传输也比使用canvas元素和webaudio要好。
2021年三星手机的整体出货量或继续下降
小米12月28日发布会：只讲技术，不发产品
高通高管表示：骁龙888将不支持AC1视频技术
西安大学在柔性可穿戴设备研究领域更进一步
关于氮(氧)化硅湿法刻蚀后清洗方式的改进
Zoom的Web客户端和WebRTC有什么关系
日本东芝进军海外核电行业计划提上日程
中国电信、中国联通日前开启 5G 消息中心联合公开测试
激光雷达-无人机定高产品的推陈出新
有哪一些款式的MOS管是比较常用于电机控制呢？
PCB电磁兼容设计关键的三个要点
水质监测站的监测指标及其特点的介绍
电动汽车对于悬架的要求会不会比较高
CHINAPLAS线上展会今日盛大启动 足不出户发现全球热点橡塑科技
测量仪器的原理及制作
DeviceNet主站与Modbus TCP主站之间的数据交换
WAVE SUMMIT 2022深度学习开发者峰会在线上举行
数智融合，兆越通讯赋能智慧城轨发展
一键掌控多媒体：中央控制系统的便利性
用ML4835设计室内可调光小型荧光灯电子镇流器