WebRTC SDP详解

最新推荐文章于 2024-08-19 19:43:21 发布
最新推荐文章于 2024-08-19 19:43:21 发布
阅读量1.3k 收藏 7
点赞数 3
分类专栏： webrtc
原文链接：https://aggresss.blog.csdn.net/article/details/106436703
版权

TL;NR 更详细的 WebRTC SDP 解析请参考 https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-12

0x00 前言

SDP (Session Description Protocol) 格式是一种很有历史的格式，在 20 世纪的会议系统中通常都是使用 SDP 格式的文本来交互多媒体通信双方的连接属性信息和媒体属性信息，在今天 JSON 这种对象化和可拓展的格式面前确实显得不够通用，尤其是在进行 RPC 通信时通常要将 SDP 信息解析成模块化的格式，ORTC 就是基于这个出发点创建的，但是 SDP 在传统流媒体通信设备上的通用度还是比较高，熟练的理解并分析 SDP 信息对于系统功能开发和调试都是大有裨益的。本文主要通过参考 RFC 4566 文档和 ORTC 思维模式来阐述一套系统化的分析 WebRTC 中 SDP 信息的方法。

0x01 SDP 格式规则

SDP 会话描述由一个会话级别的部分后跟零个或多个媒体级别的部分组成。会话级部分从 “v=” 行开始，持续到第一个媒体级部分。每个媒体级部分以 “m=” 行开始，并继续到下一个媒体级部分或整个会话描述的末尾。通常，会话级值是所有媒体的默认值，除非被等效的媒体级值覆盖。

一个 SDP 会话描述由若干行文本组成形式:

<type>=<value>

其中 <type> 必须是一个区分大小写的字符，<value> 是结构化文本，其格式取决于<type>。通常，<value> 是由单个空格字符或自由格式字符串分隔的多个字段，并且是区分大小写的，除非特定字段另有定义。"=" 符号的两边不能有空格。

对于比较复杂的行还会在空格等级的基础上继续拓展使用分号 ; 作为各个参数之间的分隔符，例如:

a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f

按照分级的思路可以记忆为 行等冒空分

0x02 WebRTC SDP 内容解析

WebRTC 的 SDP 内容要求相对宽松一些，只要满足 v o s t m c b a 行即可，即 Version/Owner/Session/Timing/Media/Connection/Bandwidth/Attributes，示例如下：

v=0
o=mozilla...THIS_IS_SDPARTA-82.0.3 485627351772987711 0 IN IP4 0.0.0.0
s=-
t=0 0
m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
b=AS:1000
a=sendrecv

// o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
// m=<media> <port> <proto> <fmt> ...

RTP/AVP：应用场景为视频/音频的 RTP 协议。参考 RFC 3551
RTP/SAVP：应用场景为视频/音频的 SRTP 协议。参考 RFC 3711
RTP/AVPF: 应用场景为视频/音频的 RTP 协议，支持 RTCP-based Feedback。参考 RFC 4585
RTP/SAVPF: 应用场景为视频/音频的 SRTP 协议，支持 RTCP-based Feedback。参考 RFC 5124

随着 WebRTC 的发展 SDP 衍生出两种风格: Plan B 和 Unified Plan 。这两种风格的主要区别在于一个 media 单元中是否携带多个 track 信息。早期的 WebRTC 中一次回话描述通常只包含一个 Audio 和 一个 Video，基于这种需求衍生出来的 SDP 比较简单，即一个 Session 和两个 m-line 。但随着业务复杂度的发展可能一次回话会包含多个 Audio 和 Video，早期的解决方案是在 m-line 中增加媒体信息，也就是 Plan B 的风格，但这样使 SDP 的解析增加了难度，尤其是当多个 Audio 或 Video 在 同一个 m-line 中存在属性冲突的场景下 Plan B 风格的缺点也就彰显了出来，于是又衍生出了 Unified Plan 风格的 SDP 会话描述，将每个 media 记录到独立的 m-line 当中。
上文描述了随着 WebRTC 的发展同一个回话中出现了更多的 media，下面我们要说的是随着 Simulcast 的引入，WebRTC 中每个 media 的内容也进行了拓展。传统的基于 RTP 的会议系统中一个 media 通常只包含一对 RTP stream (即媒体 RTP stream 和 重传 RTP Stream）但是当引入 Simulcast 概念后，一个 media 中便包含了多对 RTP stream，这种拓展也同时要求我们在解析 SDP 信息时要更新观念，由传统的 Session Level 和 Media Level 模式拓展为三段式，即：

- Session Level
	- Media Level
		- Track Level

WebRTC 中 answer SDP 中 m-line 不能随意增加和删除，顺序不能随意变更，需要和 Offer SDP 中保持一致，Offer SDP 的 m-line 顺序应遵循先 audio 后 video 的原则。

WebRTC 的 SDP 信息中的 a-line 承载了大多数的信息，主要包括 媒体信息 和 连接信息 :

  • 媒体信息 (RTP Parameters)
    • Codec Parameters
    • Header Extension Parameters
    • Encoding Parameters
    • RTCP Parameters
  • 连接信息
    • ICE Candidate
    • ICE Parameters
    • DTLS Parameters

可以方便记忆为 CHECIID

下文将基于上面的分类方式详细的描述 WebRTC 中 SDP 常见 a-line 的属性信息。

a-line 有两种组成形式:

  • a=<flag> 只用来标记开关类型的属性，例如 “a=recvonly”.
  • a=<attribute>:<field1> <field2> 用来标记具有值的属性，例如 “a=orient:landscape”

① Codec Parameters

AttributeIllustrate
a=rtpmapa=rtpmap:108 H264/90000
a=fmtpa=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtcp-fba=rtcp-fb:108 goog-remb
  • a=rtpmap 的 value 对应 RTP 头部的 Payload Type，长度 8 位，也就是取值范围 0-255，95-127 为自定义，通过 rtpmap 字段进行定义并通过跟随其后的 fmtp 字段来定义属性信息。举例：
    a=rtpmap:108 H264/90000
    定义了 Payload Type 为 108 的 RTP 用来传输 H.264 格式的媒体，媒体采样频率为 90kHz 。
  • a=fmtp 为对应 codec 的参数信息 (Format Parameters)，常见的几种 codec 的 fmtp 举例：
    • opus a=fmtp:111 minptime=10;stereo=0;useinbandfec=1
      这个 fmtp 描述了一个 Payload Type 为 111 的 opus 媒体编码参数
    • H.264 a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
      这个 fmtp 描述了一个 Payload Type 为 102 的 H.264 媒体编码参数
    • RTX a=fmtp:120 apt=102
      这个 fmtp 描述了重传的参数，APT (Associated Payload Type)，将重传 Payload Tpye 与媒体 Payload Type 进行关联，即 Payload Type 为 120 的 RTP 用于重传 Payload Type 为 102 的媒体信息。
  • a=rtcp-fb 用于描述一个 Codec 支持的 RTCP Feedback 的类型，常见的有：
    • a=rtcp-fb:120 nack 支持 nack 重传，nack (Negative-Acknowledgment) 。
    • a=rtcp-fb:120 nack pli 支持 nack 关键帧重传，PLI (Picture Loss Indication) 。
    • a=rtcp-fb:120 ccm fir 支持编码层关键帧请求，CCM (Codec Control Message)，FIR (Full Intra Request )，通常与 nack pli 有同样的效果，但是 nack pli 是用于重传时的关键帧请求。
    • a=rtcp-fb:120 goog-remb 支持 REMB (Receiver Estimated Maximum Bitrate) 。
    • a=rtcp-fb:120 transport-cc 支持 TCC (Transport Congest Control) 。

② Header Extension Parameters

AttributeIllustrate
a=extmapa=extmap:14 urn:ietf:params:rtp-hdrext:toffset

③ Encoding Parameters

AttributeIllustrate
a=ssrca=ssrc:2430709021 cname:nYAodpnTebS8lziR
a=ssrc-groupa=ssrc-group:FID 2430709021 3715850271

  • a=ssrc 用于描述 RTP packet 中 SSRC (Synchronization sources) 字段对应的媒体信息，既用于描述当前 media 中存在该 SSRC ，又用于描述该 SSRC 的属性信息，早期的 Chrome 产生的 SDP 中每个 SSRC 通常有 4 行，例如：

    a=ssrc:3245185839 cname:Cx4i/VTR51etgjT7
a=ssrc:3245185839 msid:cb373bff-0fea-4edb-bc39-e49bb8e8e3b9 0cf7e597-36a2-4480-9796-69bf0955eef5
a=ssrc:3245185839 mslabel:cb373bff-0fea-4edb-bc39-e49bb8e8e3b9
a=ssrc:3245185839 label:0cf7e597-36a2-4480-9796-69bf0955eef5
    •  

    这么繁杂的信息是有历史原因的，cname 是必须的，msid/mslabel/label 这三个属性都是 WebRTC 自创的，或者说 Google 自创的，可以参考 https://tools.ietf.org/html/draft-ietf-mmusic-msid-17，理解它们三者的关系需要先了解三个概念：RTP stream / MediaStreamTrack / MediaStream ：

    • 一个 a=ssrc 代表一个 RTP stream ；
    • 一个 MediaStreamTrack 通常包含一个或多个 RTP stream，例如一个视频 MediaStreamTrack 中通常包含两个 RTP stream，一个用于常规传输，一个用于 nack 重传；
    • 一个 MediaStream 通常包含一个或多个 MediaStreamTrack ，例如 simulcast 场景下，一个 MediaStream 通常会包含三个不同编码质量的 MediaStreamTrack ；

    上面的示例中: label 对应 MediaStreamTrack ID，mslabel 对应 MediaStream ID，msid 将 MediaStream ID 和 MediaStreamTrack ID 组合在一起。
    这种标记方式并不被 Firefox 认可，在 Firefox 生成的 SDP 中一个 a=ssrc 通常只有一行，例如：

    a=ssrc:3245185839 cname:Cx4i/VTR51etgjT7

    用于描述该 RTP stream 对应的 RTCP 协议中的 CNAME。

    RTCP 为每个 RTP 用户提供了一个全局唯一的规范名称标识符 CNAME (Canonical Name) ，接收者使用它来追踪一个 RTP stream。当发现冲突或程序重新启动时，RTP 中的 SSRC (同步源标识符) 可能会发生改变，接收者可利用 CNAME 来索引 RTP stream。同时，接收者也需要利用 CNAME 在相关 RTP 连接中多个 RTP stream 之间建立联系。当 RTP 需要进行音视频同步的时候，接受者就需要使用 CNAME 来使得同一发送者的音视频数据相关联，然后根据 RTCP 包中的 NTP (Network Time Protocol) 来实现音频和视频的同步。

  • a=ssrc-group 定义参考 RFC 5576 ，用于描述多个 ssrc 之间的关联，常见的有两种：

    • a=ssrc-group:FID 2430709021 3715850271 FID (Flow Identification) 最初用在 FEC 的关联中，WebRTC 中通常用于关联一组常规 RTP stream 和 重传 RTP stream 。
    • a=ssrc-group:SIM 360918977 360918978 360918980 在 Chrome 独有的 SDP munging 风格的 simulcast 中使用，将三组编码质量由低到高的 MediaStreamTrack 关联在一起。

④ RTCP Parameters

AttributeIllustrate
a=rtcpa=rtcp:51472 IN IP4 127.0.0.1
a=rtcp-muxa=rtcp-mux
a=rtcp-rsizea=rtcp-rsize
  • a=rtcp 用于描述 RTCP 的通信地址，在 WebRTC 已经不常用到，因为 WebRTC 通常会使用 rtcp-mux 方式，也就是 RTP 和 RTCP 使用同一个连接地址。同时因为 ICE 在 WebRTC 中是强制性的，所以 a=rtcp 和 c-line 一般都不会被使用。
  • a=rtcp-mux 在 RFC 5761 中定义，用于标示当前会话将 RTP 和 RTCP 绑定在同一连接地址和端口中。
  • a=rtcp-rsize 在 RFC 5506 中定义，用于标示当前会话支持 reduced-size RTCP packets 。

⑤ ICE Candidate

AttributeIllustrate
a=candidatea=candidate:0 1 UDP 2122252543 192.168.0.111 56774 typ host
a=end-of-candidatesa=end-of-candidates
  • a=candidate 用于描述 ICE 交互时的一个连接候选者的参数，需要注意 UDP 类型和 TCP 类型的 candidate 定义上是有区别的。 
    UDP
<foundation> <component-id> <transport> <priority> <conn-addr> <conn-port> <cand-type> <candidate-types>
a=candidate:1 1 UDP 2130706431 fe80::6676:baff:fe9c:ee4a 8998 typ host
TCP
<foundation> <component-id> <transport> <priority> <conn-addr> <conn-port> <cand-type> <candidate-types> <tcp-type-ext> <tcp-type>
a=candidate:2 1 TCP 2124414975 192.0.2.1 3478 typ host tcptype passive

component-id 1:RTP 2:RTCP
    •  

    ICE Candidate 的 4 种类型 https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-39

    • host 该 candidate 是一个真实的主机，参数中的地址和端口对应一个真实的主机地址
    • srflx (server reflexive) 该 candidate 是通过 Cone NAT 反射的类型，参数中的地址和端口是端发送 Binding 请求到 STUN/TURN server 经过 NAT 时，NAT 上分配的地址和端口
    • prflx (peer reflexive) 该 candidate 是通过 Symmetric NAT 反射的类型，参数中的地址和端口是端发送 Binding 请求到 STUN/TURN server 经过 NAT 时，NAT 上分配的地址和端口
    • relay 该 candidate 是通过 TURN 服务中继的类型，参数中的地址和端口是 TURN 服务用于在两个对等点之间转发数据的地址和端口
  • a=end-of-candidates 在 Trickle ICE 模式时，用于显示声明 candidate 信息的结束，在 https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-18 中定义。

⑥ ICE Parameters

AttributeIllustrate
a=ice-optionsa=ice-options:trickle
a=ice-litea=ice-lite
a=ice-ufraga=ice-ufrag:3e1029a1
a=ice-pwda=ice-pwd:143a54b37278247c66e93088f767c62d
  • a=ice-options 用于描述 ICE 连接的属性信息，ice-options 的定义有很多种，WebRTC 中常见的有：
    • a=ice-options:trickle client 一边收集 candidate 一边发送给对端并开始连通性检查，可以缩短 ICE 建立连接的时间。
    • a=ice-options:renomination 允许 ICE controlling 一方动态重新提名新的 candidate 。
  • a=ice-lite 用于描述使用 ICE lite 实现。

    ICE 的实现分为 Full ICE 和 Lite ICE：
    Full ICE 参与连接的两端都要进行连通性检查。
    Lite ICE 在 FULL ICE 和 Lite ICE 连接时，只需要 Full ICE 一方进行连通性检查， Lite ICE 一方只需回应 Response 消息。这种模式对于部署在公网的设备比较常用。

  • a=ice-ufrag (ICE Username Fragment)，描述当前 ICE 连接临时凭证的用户名部分。
  • a=ice-pwd (ICE Password)，描述当前 ICE 连接临时凭证的密码部分。

⑦ DTLS Parameters

AttributeIllustrate
a=setupa=setup:actpass
a=fingerprinta=fingerprint:sha-256 9D:58:00:00:00:00:FF:FF:00:00:00:FF:FF:FF:FF:FF:FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00
  • a=setup 合法值包括 actpass/active/passive 。在 WebRTC 中 DTLS 主要是为了交换 SRTP 的密钥，定义参考 RFC 5763 。一次 DTLS 通信的角色通常需要协商指定，通常发起 Offer 一方都会设置为 actpass，即由对方来定，这时 Answer 回复 active 或者 passive 即完成了角色的协商，当然如果 Offer 一方指定了 active 或者 passive，Answer 一方就只能选择剩下的那个角色了。
  • a=fingerprint DTLS 通信开始前上方都需要校验证书是否被篡改，检验的依据就是协商阶段的证书指纹信息。常见的指纹校验算法有：sha-1/sha-224/sha-256/sha-384/sha-512

⑧ Miscellaneous

AttributeIllustrate
a=sendrecv/sendonly/recvonly/inactivea=sendrecv
a=groupa=group:BUNDLE 0 1
a=mida=mid:0
a=rida=rid:1 send pt=98;max-width=1280;max-height=720
a=simulcasta=simulcast:send hi;mid;lo
a=bundle-onlya=bundle-only
a=msid-semantica=msid-semantic:WMS *
ydjjcdd
关注
专栏目录
基于Android 的WebRTC SDP协议讲解
hnjzfwy的博客
04-01 449
webrtc通过SDP协商，告知对端支持的音视频编码类型，编码器参数，音频或者视频的路数，以及与音视频相关的采样率，编码等等，双方根据各自的能力情况，协商出待传输音视频流的具体参数。
WebRTC 中 SDP 信息解析
aggresss
11-22 8087
在 20 世纪的会议系统中通常都是使用 SDP 格式的文本来交互连接属性信息和媒体属性信息，在今天 JSON 这种对象化和可拓展的格式面前确实显得不够通用，尤其是在进行 RPC 通信时通常要将 SDP 信息解析成模块化的格式，ORTC 就是基于这个出发点创建的，但是 SDP 在传统流媒体通信设备上的通用度还是很高的，熟练的理解并分析 SDP 信息对于系统功能开发和调试都是大有裨益的。本文主要通过参考 RFC 4566 文档和 ORTC 思维模式来阐述一套系统化的分析 WebRTC 中 SDP 信息的方法。
WebRTC - ICE 过程简述
paradox_1_0的博客
10-18 1470
1. ICE介绍 1.1.ICE的角色 分为 controlling和controlled。 Offer 一方为controlling角色，answer一方为controlled角色。 1.2.ICE的模式 分为FULL ICE和Lite ICE： FULL ICE:是双方都要进行连通性检查，完成的走一遍流程。 Lite ICE: 在FULL ICE和Lite ICE互通时，只需要FULL ICE一方进行连通性检查， Lite一方只需回应response消息。这种模式对于部署在公网的设备比较.
Webrtc之SDP协议
最新发布
chen_jianjian的专栏
08-19 805
SDP
解剖WebRTC SDP
我的玻璃盒子
11-27 421
这里有一个查询SDP的页面，鼠标覆盖在每一项上，右侧就会出现解释说明，类似一个字典一样，非常方便： Anatomy of a WebRTC SDP https://webrtchacks.com/sdp-anatomy/...
Webrtc SDP格式解读
Andy Tools
07-17 2781
因为设备端只支持H264编码方式接入，这里涉及到webrtc web端要修改默认编码器，而编码器就离不开webrtc 信令中SDP 消息的解读，读懂了 才能知道自己支持编码器的情况下对SDP的信息进行二次修改。 本文主要内容来自该说明文档：https://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-08主要涉及到 RFC4566 RFC5888...
webrtc中mid rid
sun007700的专栏
02-18 930
通过SSRC，MID或RID 区分rtp流 【WebRTC基础系列】Mid-call features https://blog.csdn.net/pkueecser/article/details/6868900
硬货专栏 ｜WebRTC SDP 详解和剖析
qq_52703909的博客
03-21 737
WebRTC 是 Web Real-Time Communication，即网页实时通信的缩写，是 RTC 协议的一种Web实现，项目由 Google 开源，并和 IETF 和 W3C 制定了行业标准。在国内 WebRTC 已经获得了越来越多厂商的支持，应用前景变得更加广阔，所以我们也开设专栏，分享阿里云内部的 WebRTC 研究工作。 本篇是阿里云视频云 WebRTC 技术专栏系列文章的第一篇，作者将从 WebRTC SDP 例子和关键属性的角度为大家深度剖析解读，其中也分享了阿里云技术专家的一些实践经
webrtc-sdp详解
码农修仙的博客
06-17 3867
1、SDP协议简介 SDP(Session Description Protocol) 是一种会话描述协议，基于文本，其本身并不属于传输协议，需要依赖其它的传输协议（比如 SIP 和 HTTP）来交换必要的媒体信息，用于两个会话实体之间的媒体协商，详细的标注规范可参考RFC2327和RFC4566。WebRTC 中使用 Offer-Answer 模型交换 SDP，本文详细介绍SDP各属性在WebRTC中的应用。 2、SDP组成 SDP是由多行文本组成的一个纯文本协议，如果将SDP从语义上分解成不同组件来描述
技术分享| WebRTC之SDP详解
anyRTC的博客
08-18 695
SDP(Session Description Protocol) 是一种会话描述协议，基于文本，其本身并不属于传输协议，需要依赖其它的传输协议（比如 SIP， HTTP，自定义的信令等）来交换必要的媒体信息，用于两个会话实体之间的媒体协商，同时SDP也不是只为WebRTC使用，其他的传输比如RTSP，SIP通话也是通过SDP进行媒体协商。
webrtc sdp(会话传输协议)详解
Hello World
11-12 946
1、什么是sdp SDP(Session Description Protocol)描述会话协议，它只是一种信息格式的描述标准，本身不属于传输协议，但是可以被其他传输协议用来交换必要的信息，用于两个会话实体之间的媒体协商。 2、sdp协议结构 SDP的文本信息包括： 会话信息 网络信息 媒体信息 安全信息 服务质量和分组信息 +---------------------+
webrtc之simulcast的sdp信息实例
12-03
众所周知，webrtc启用simulcast是通过修改sdp信息实现的，这里提供一个具体的sdp实例。
【WebRTC基础系列】Mid-call features
三少GG
10-13 3046
1.什么是Mid-call? BACKGROUND  This invention relates to mid-call features in a telephone communication system.  Many telephone systems pro
SRS源码分析-SDP内容解析
xfc_1939的博客
03-05 1768
分析SDP格式，介绍SRS4.0中，浏览器播放SRS服务中的webrtc流时双方产生的SDP内容
关于H.264 profile-level-id
我的玻璃盒子
10-29 9916
我们在WebRTC开发中，如果采用的是H.264来作为视频流编码类型，就会面临一个问题，那就是编码端和解码端需要进行协商各自的编解码能力。例如，如果编码端使用了高级别的profile和level，或使用了解码器不支持的编码特性，那么对解码端来说就是个灾难了。 大家知道，H.264的Profile以及Level有好多种，而并不是每一种编码器或者解码器都支持每一个Profile和Level。实际应用当...
WebRTC simulcast
温故而知新
06-26 2041
简介 Simulcast 可以翻译成联播，不是新闻联播，而是多个媒体流的传播，如图所示 注: SFU 即 Selective Forward Unit, 媒体转发服务器 刚开始，发送方 sender 发送一路 1080p 的视频流给服务器 SFU， SFU 再转发给多个接收方 receiver1, receiver2 和 receiver3。 一会儿，receiver 2 和 recei...
webrtc sdp详解
wangbuji的博客
01-21 2500
SDP（Session Description Protocol）是一种通用的会话描述协议，主要用来描述多媒体会话，用途包括会话声明、会话邀请、会话初始化等。 WebRTC主要在连接建立阶段用到SDP，连接双方通过信令服务交换会话信息，包括音视频编解码器(codec)、主机候选地址、网络传输协议等。 协议版本号 v=0 会话发起者 o=<username> <sess-id> <sess-version> <nettype> <ad
漫谈 WebRTC 一: 何谓Simulcast， WebRTC中的Simulcast
热门推荐
闲敲棋子落灯花
11-05 1万+
写作本文的初衷是： 前些日子为WebRTC设计Simulcast, 把所有相关的代码又重新阅读了一遍， 想着WebRTC代码结构复杂， 代码量巨大， Google的release迭代改动快， 改动量大， 代码常读常忘， 忘了再读， 也许应该写点啥东西保存起来。 适之先生说， 要使你所得印象变成你自己的， 最有效的方式是记录或者表现成文章。 故此不揣浅薄， 记录一些东西， 以为未来参考， 也算是响
WebRTC对多流传输（Simulcast）的支持
VhpPhp的博客
09-24 188
Simulcast是一项在实时通信中常用的技术，它允许发送方同时传输多个不同分辨率和比特率的视频流，以适应不同网络条件和接收方设备的要求。然后，我们获取支持的编解码器和创建Simulcast的编码参数。这使得应用程序能够根据不同的网络条件和接收方设备的要求，动态地发送适当分辨率和比特率的视频流，提供更好的用户体验。WebRTC提供了一些内置的功能和API，以支持Simulcast的实现。请注意，上述代码仅作为示例，实际的WebRTC应用程序可能需要根据具体需求进行适当的修改和扩展。
WebRTC技术详解与应用实践
- **WebRTC三角形会话**：在这种模式下，会话描述（SDP）对象通常通过服务器进行中转，浏览器与服务器之间以及服务器与另一个浏览器之间分别进行通信。这种模式适用于服务器充当信号传输中介的情况，能减少直接的...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值