我们多次触及的一个领域是使用 WebCodecs 和 WebTransport 作为 WebRTC 的 RTCPeerConnection 的替代方案。为了简洁起见,我们将这种方法称为 W&W。 这些想法已被 WebTransport 采纳。因此,在我看来,其中很大一部分是扩展了 WebRTC,同时也添加了新的功能,可以将 WebRTC 与其他东西结合起来。” 我认为 WebRTC 并不擅长某些事情,例如缓存和 DRM 等超低延迟流媒体功能,这些功能可以通过 WebCodecs 和 WebTransport 来完成,我们肯定会深入探讨这一点。” “口型同步的音频和视频对齐本身就是一个完整的主题,这是我花最多时间的领域。这可以得到很大改善。但无论如何,这里我们做了一些补偿来对齐音频和视频。” “最后一点——我们将音频发送到音频循环缓冲区。 图8 实际图像渲染速度 Jordi 遇到的挑战与实验数据 Chad:“Jordi,您能谈谈您的实验结论吗?您对哪些感到满意,哪些还需要改进?”
WebRTC 无疑推动和改变了互联网视频,而这仅仅是刚刚开始,除了大家熟悉的 WebRTC-PC、Simulcast 和 SVC,有太多的新技术和新架构出现在 WebRTC 新的标准中,比如 WebTransport 、WebRTC-NV 用例、WebRTC-ICE,、WebTransport 和 WebRTC-QUIC 等文档的主编,微软 Teams 媒体组的首席架构师。 很多会议服务器支持 RID 和 MID,我认为 Medooze 和 Janus 都支持。而 VP8 和 VP9 是默认都支持的,解码器必须支持它,因此不用协商。 它更多是 VP8、VP9 的继续演进版本。它有 H.264 那样的 NALU 语法,所以它有点像 VP9 和 H.264 之间的过渡。 比如 WebCodecs 支持了 GPU 缓冲区,但目前这个缓冲区是只读的,如果你希望对 GPU 缓冲区的内容做 ML,这就不行了因为无法修改它,你只能用拷贝实现。
因此,从理论上讲,您应该能够使用H.264,VP8和VP9做到这一点。 我们一直在寻找错误。我们遇到了一些非常可怕的错误,例如H264无法正常工作。 我认为许多会议服务都支持RID和MID,Medooze和Janus都支持。关于SVC的理解之一是,在VP8和VP9中都是必需的-解码器必须支持这一点。因此,没有什么可以谈判的。编码器可以将其推出。 我认为这是VP8 VP9系列中的下一个。它具有某种H.264类型的MAL单元语义,因此有点像H.264和VP9之间的交叉。 它现在可以与VP8和VP9一起使用,它不能与H264一起使用。我不确定不能使其与H264一起使用,但是我们有一个仍在处理的错误。 因此,作为一个示例,您将看到WebCodecs确实支持GPU缓冲区的概念,但是存在局限性,因为很多时候这些GPU缓冲区不可写-它们是只读的。
什么是WebTransport? WebTransport 是WebRTC体系下的一套浏览器API,提供低延迟,client和server之间双向通信的能力。 核心的能力点包括: WebTransport 提供基于QUIC 和 HTTP3实现的API, 自动获得QUIC和HTTP3本身的特性,比如应用层的拥塞,避免队头阻塞。 2,云游戏 目前web端的云游戏方案 大都使用WebRTC, WebRTC为通话场景设计,本身的jitterbuffer,音视频同步,渲染延迟设计会引入额外的延迟,且Web端并没有暴露出来可以控制延迟的 5,更具定制化能力的RTC组合 WebRTC作为浏览器的一个标准, 在浏览器中我们无法控制WebRTC的内部工作机制, 对于有能力处理好音视频前后处理的团队来说,加上WebTransport提供的传输能力 最后,我们已经在最新的Chrome Canary 开发版本中体验测试 WebTransport + WebCodecs, 后端quic的各种实现也已经具备和WebTransport互通能力, 我们放出一个后端使用
、WebTransport和WebRTC-QUIC文档的编辑。 WebRTC-ICE(目前已经作为独立的规范实现)属于这一类,W3C WEBRTC工作组之外开发的API规范也属于这一类,如WebTransport(W3C WebTransport工作组)、WebRTC-QUIC 您可以看到这反映在WebRTC和用例中——这些场景就像对等数据交换一样。 网络传输 WebTransport是W3C的另一个规范,有自己的工作组和规范。 Chad:那么什么是WebTransport,它是从哪里来的,和WebRTC有什么关系呢? Bernard:网络传输既是一个API,又是W3C网络传输组的成员。 因此,从理论上讲,你应该能够使用H.264,VP8和VP9做到这一点。 我们一直在寻找错误,也遇到过一些非常可怕的错误,例如H264无法正常工作。
这是WebRTC的架构示意图。WebRTC提供了丰富的Web API。音视频采集、音视频编解码、音视频前后处理、音视频的传输和渲染都因WebRTC得以实现。 首先WebRTC不能自定义编解码器,另外WebRTC不能复用现有的服务框架以及优化能力,最后WebRTC的可定制化程度较低。 有没有新的Web技术作为替代来解决WebRTC的问题呢? WebTransport是一个全新的可插拔的通信协议,支持可靠和非可靠传输。在一些需要可靠传输的应用中可以使用WebTransport。WebTransport的目标是更快速、更高效、安全和低延时。 WebAssembly引擎主要包含WebSDK、用户调度中心、WebTransport/WebSocket Gateway集群和后台TRTC服务集群和调度四大模块。 WebTransport不能在Safari浏览器中运行,WebCodecs目前只能在Chrome和Edge94以上以及最新的 safari版本运行,WebTransport也只能在Chrome和Egde97
通常人们把WebTransport跟另外两个协议进行对比,一个是Websocket,一个是WebRTC。 另外一个经常对比的协议就是WebRTC,WebRTC必须要依靠ICE(Interactive Connectivity Establishments)协议来让通讯双方知道对方的IP地址和网络端口,如果通讯双方没有直接的网络连接的话 那么在这一点上Websocket和WebRTC就不如WebTransport,因为它是直接运行在443网络端口上的,所以它天然具备穿透NAT和防火墙的能力,现有的Web Infrastructure就可以无障碍的支持 WebTransport,所以它相较于WebRTC更简单一些,也更易于部署,不需要额外的基础设施投资。 但是WebRTC比较依赖ICE和底层的infrastructure,所以它的协议更复杂一些,需要额外的基础设施部署。
它利用了 HTTP/3 QUIC 协议[8],可以实现以可靠和不可靠的方式实现多个流的数据传输功能,甚至允许数据无序发送。 WebRTC 设计用于通过 NAT 和防火墙工作,利用诸如 ICE、STUN 和 TURN 等协议来建立对等之间的连接。 WebTransport:设计为高度可伸缩,受益于 HTTP/3 在处理连接和流时的高效性,与 WebSockets 和 SSE 相比,可能减少服务器负载。 8. : https://www.w3.org/TR/webtransport/ [8] HTTP/3 QUIC 协议: https://en.wikipedia.org/wiki/HTTP/3 [9] 工作草案阶段 : https://w3c.github.io/webtransport/ [10] 网页实时通信(Web Real-time Communication,WebRTC): https://webrtc.org
WebTransport&WebCodecs 对WebRTC不满意?还有WebTransport和WebCodecs。 WebTransport和WebCodecs(一起)理论上可以实现媒体的编解码以及从服务器发送或接收媒体。 细节决定成败,虽然WebTransport和WebCodecs还没有达到可以取代WebRTC的受欢迎程度,但它们却非常有前景。 至少要等到WebTransport 和WebCodecs技术成熟以后。 从2D到元宇宙 每个人都在重新思考未来通信方式,这些方式可不是过去20多年间我们所依赖的那种对着摄像机讲话。 微软在谷歌的libwebrtc中改进了屏幕分享这一功能(在决定Edge采用Chromium之后),Intel助力AV1硬件编码,RingCentral和8x8推动在WebRTC中向Opus添加RED等等
)/ Noise Reduction(噪声抑制) Video Engine(视频引擎) VP8 Codec(视频图像编解码器) Video jitter buffer(视频抖动缓冲器,处理视频抖动和视频信息包丢失 ) 除此之外,安全传输可能还会用到DTLS(数据报安全传输),用于加密传输和密钥协商 整个WebRTC通信是基于UDP的 WebRTC 的核心组件 音视频引擎:OPUS、VP8 / VP9、H264 传输层协议 IETF WebTransport (WEBTRANS) 和 WebRTC Ingest Signaling over HTTPS (WISH) 工作组已经在开展工作,在 IETF 其他工作组的基础上进一步协调 其中包括 QUIC(定义支持 WebTransport API 开发的新协议)和 HTTPBIS(指定简单、可扩展的、基于 HTTPS 的信令协议),以在广播工具和实时媒体广播网之间建立基于 WebRTC W3C 近期开始的 WebTransport 和 Web Codecs 工作预计将低延迟流媒体的优势引入更广大的媒体和娱乐生态系统。
[]; for(let j=0;j<y;j++) for(let i=0;i<x;i++) r.push([i,j]); return r } 4.对比不同 JavaScript 的写法对 V8 Position { TOP, // = 0 BOTTOM, // = 1 } 5.WebSockets vs Server-Sent-Events vs Long-Polling vs WebRTC vs WebTransport[6] 相关地址:https://rxdb.info/articles/websockets-sse-polling-webrtc-webtransport.html#performance-comparison 一些有用的函数简写: https://gist.github.com/tangentstorm/4f271600fc20404150e05c373109551d [5] 对比不同 JavaScript 的写法对 V8 vs WebTransport: https://rxdb.info/articles/websockets-sse-polling-webrtc-webtransport.html#performance-comparison
Encoded Media Transform Transferable DataChannels Webcodecs WebTransport No WebRTC? NICER 是一种在一次对话中切换 4G 和 wifi 的一种方法,这给 WebRTC 增加了一个新功能。 WebTransport 严格来说,这也不能算作是 WebRTC。 WebTransport 是一种与服务器低延迟通信的方法,并且支持不可靠和乱序的通信。 远程控制 图 7 这个案例使用了 |pipe| 的轻量栈,对 Arm 友好; 远程用户可以观看和控制至多 6 台设备; 共享音频空间; 在树莓派上运行; 基本无需任何安装,因为 Web 接口加载了 WebRTC Remote web server 图 8 远端的 web 服务器实现,其域名为 dev.pi.pe,该页面的代理是通过 WebRTC 数据通道 服务器 worker Iframe 实现的。
导语 | 如今通过网络进行实时音视频通话已经越来越流行,对于音视频领域的技术要求也越来越高,许多网络技术应运而生,如WebRTC,QUIC,HTTP3,WebTransport,WebAssembly WebTransport简析 前面我们知道了QUIC和HTTP3,下面来谈一谈浏览器的一个重磅级特性——WebTransport。 1. 最新版的WebTransport草案中,该协议是基于HTTP3的,即WebTransport可天然复用QUIC和HTTP3的特性。 2. 编程样例 使用如下的web端简单编程样例即可和支持WebTransport的后台服务进行通信。 WebTransport Gateway 我们团队在WebTransport上作出了许多努力,研发的WebTransport Gateway可以支持接入用户转发的可靠和非可靠信息,将其转发给后台服务,同样也可以回送给用户
WebRTC部分(Opus/VP8/VP9/H264)✔(P2P信令+ICE)RTSP控制层流媒体协议IETF RFC 2326 / 7826由 RTP 承载决定✔(SETUP/PLAY/PTZ)RTMP 在“实时性”和“网络适应性”上远胜 WebSocket。 WT 则提供: 可控 可扩展 更像“Web 版的 SRT” 2.3 WebTransport 的当前限制(标准化进度和工程现实)尽管 WT 很强,但它仍处在早期阶段,存在以下限制:✘ 浏览器支持仍不完整 4.1 WebRTC = 一个庞大的规范族(Standards Family),而非单一协议WebRTC 的能力由 IETF(网络传输与安全)和 W3C(浏览器 API)两个组织同时定义,其规范体系包括四个主要领域 、WebTransport 这 8 类协议并不是彼此取代关系,而是 在系统架构中承担不同的语义与职责。
通常与 之相提并论的协议包括Websocket和WebRTC data channel。 WebTransport同时具备双向通信, 传输可靠性(WebTransport stream),传输安全性,跨互联网的穿透性等优点。 8月16日晚19:30,LiveVideoStack邀请到了Pluto TV软件架构师 张博,本次分享将提出一种基于WebTranspor的源视频流注入方法 (a method for live stream 讲师信息: 张博,现供职于美国Paramount Global集团旗下的Pluto TV,担任负责视频编码和播放系统设计 的软件架构师。 他曾在视频技术和通信网络技术研究领域发表十余篇论文。其中一篇曾获得2011 年ACM MSWiM会议的最佳论文奖。
,相关于网络进行实时通讯技术应运而生,如WebRTC,QUIC,HTTP3,WebTransport,WebAssembly,WebCodecs等。 最新版的WebTransport草案中,该协议是基于HTTP3的,即WebTransport可天然复用QUIC和HTTP3的特性。 WebTransport 是一个新的 Web API,使用 HTTP/3 协议来支持双向传输。它用于 Web 客户端和 HTTP/3 服务器之间的双向通信。 WebTransport 支持三种不同类型的流量:数据报(datagrams) 以及单向流和双向流。 WebTransport 的设计基于现代 Web 平台基本类型(比如 Streams API)。 它在很大程度上依赖于 promise,并且可以很好地与 async 和 await 配合使用。
通常与 之相提并论的协议包括Websocket和WebRTC data channel。 WebTransport同时具备双向通信, 传输可靠性(WebTransport stream),传输安全性,跨互联网的穿透性等优点。 如果在其下层使用 HTTP/3 datagram,WebTransport还能实现快速,低延迟的数据传输(WebTransport datagram)。 讲师信息: 张博,现供职于美国Paramount Global集团旗下的Pluto TV,担任负责视频编码和播放系统设计 的软件架构师。 他曾在视频技术和通信网络技术研究领域发表十余篇论文。其中一篇曾获得2011 年ACM MSWiM会议的最佳论文奖。
8.Zoom支持自动生成字幕 ---- Zoom正面临着很激励的竞争,前一段时间开始做RTC的PaaS服务, 以147亿美元收购five9,但最后以失败而告终。 Streaming服务,让用户可以在云端服务器上运行虚幻引擎应用程序,通过WebRTC将渲染的帧和音频流送到浏览器和移动设备上。 WebTransport提供低延迟,client和server之间双向通信的能力。 WebTransport 提供基于HTTP3实现的API, 自动获得QUIC和HTTP3本身的特性,比如应用层的拥塞,避免队头阻塞。 欢迎在本文评论区提问、交流,老师将为您解答。 云荐官将抽取1位小伙伴送出云加视频礼盒一份!
然后主讲人首先介绍第一部分:什么是 WebRTC? 一般而言,WebRTC 的定义是这样的:WebRTC 是一个免费的开放项目,通过简单的 API 为浏览器和移动应用程序提供实时通信(RTC)功能。 视频编解码器包括: VP8; VP9; H264; AV1(即将推出!)。 音频编解码器则包括: iSAC(强大的、带宽自适应的、宽频和超宽频的语音编解码器); iLBC(免费窄带语音编解码器); 以及一些其他的音频编解码器。 Singalling 通常在中间有一个 WebRTC 服务器。最常见的两种是 Janice 和 gizzi。但这些服务器是你的 WebRTC 流要进入的地方,所以你的 RTP 数据包用于音频和视频。 dis_k=4e18b144fca88b8d72b8ae9207a5e877&dis_t=1653387393&vid=wxv_2351259177286991872&format_id=10002&support_redirect
过去十多年,音视频流传输协议的变革从 RTMP、RTSP 到 WebRTC、SRT、WebTransport、QUIC,再到 HLS 和 DASH,几乎代表了整个音视频行业的发展历程。 其核心思想是将视频流分割成多个小的媒体文件(如 TS 文件),并通过播放列表文件(m3u8)来指引客户端下载这些分片。 8️⃣ WebTransport — 下一代低延迟浏览器实时传输协议WebTransport 是基于 QUIC 的新兴协议,旨在提供比 WebRTC 更低延迟、更高效的浏览器端实时通信解决方案。 通过多路复用,WebTransport 可以实现高效的数据并发传输,并确保数据的安全性和完整性。 低延迟互动场景(如视频会议、远程医疗):优先选择 WebRTC 或 SRT,确保最佳实时性。WebRTC 和 SRT 都能提供极低的延迟和高效的传输,尤其适用于需要实时反馈的互动场景。