SRS源码分析-SDP内容解析

已于 2023-03-05 18:52:30 修改
阅读量1.5k 收藏 2
点赞数
分类专栏： SRS4.0 文章标签： SDP webrtc SRS
于 2023-03-05 18:01:12 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xfc_1939/article/details/129337474
版权

前言

在学习SRS的RTC模块之前，首先来分析下SRS在将rtmp推流转成rtc流，通过浏览器拉取webrtc流场景下产生的SDP内容

SDP格式介绍

SDP数据是文本格式，由多个 <key>=<value> 表达式构成，<key>的值只能是一个字符，<value>是一个字符串。注意：等号两边不能有空格

SDP主要由下列描述构成

  • 会话级描述（作用于整个会话），位置从 v= 行开始到第一个媒体描述为止
    • v=，sdp协议版本，默认为0
      • 例子：v=0
    • o=，发起者或者会话标识
      • 格式：o=<username> <session id> <version> <network type> <address type> <address>
      • 例子：o=SRS/4.0.245(Leo) 17778048 2 IN IP4 0.0.0.0
      • 说明：
        • username：用户名，不关心时，可用 ‘-’ 代替
        • session id： 会话id，会话唯一，规范建议使用NTP时间戳
        • version：会话版本，会话数据发生变化时该版本递增，规范建议使用NTP时间戳
        • network type：网络类型，IN表示 Internet
        • address type：地址类型，比如IP4、IP6等
        • address：域名或者IP地址
    • s=，会话名称，每个SDP里面只能有一个，且不能为空
      • 例子：s=SRSPlaySession
    • t=, 会话的有效时间
      • 格式：t=<start time> <stop time>
      • 例子：t=0 0
      • 说明：
        • start time/stop time均为NTP时间戳，均为0时，表示持久会话
    • b=，会话或媒体使用的建议带宽
  • 媒体级别描述（针对单个媒体流，一个会话中可以有多个媒体流），位置是从 m= 行开始到下一个媒体描述为止
    • m=, 媒体类型和传输地址
      • 格式：m=<media type> <port> <transport> <fmt list>
      • 例子：
        m=audio 9 UDP/TLS/RTP/SAVPF 111
m=video 9 UDP/TLS/RTP/SAVPF 106
      • 说明：
        • media type：媒体类型，比如audio/video，application(bfcp)、text等类型
        • port：当前媒体类型的数据传输端口，在RTC场景下都是通过ICE candidate的信息来进行传输的，这个端口不会用到，但是在SIP场景下，这个port代表RTP端口，结合SDP会话级别描述中的C=中的ip地址，就可以知道在SIP中这路流的传输地址了
        • transport：传输协议，运行与c=中定义的地址类型之上，比如IP4，就是运行IP4之上的协议
        • fmt：代表音视频流的Media Codec，会话后面会跟着rtpmap、rtcp-fb、fmtp这些属性来进一步的描述，可以有多个值，存在多个值的时候，表示在这次会话中，多种类型都会用到，且第一个是默认的。
    • a=rtpmap，描述媒体会话描述(m=)中的fmt负载类型对应的编码器名称以及时钟速率信息和编码参数
      • 例子：
        a=rtpmap:111 opus/48000/2   // 对fmt为111的类型进行描述，audio codec/sample rate/channel
a=rtpmap:106 H264/90000    // 对fmt为106的类型进行描述，video codec/timebase
    • a=fmtp，扩展字段，对媒体会话描述中的指定的fmt进行详细的参数格式指定(这个参数是需要有SDP传输，并且透传给使用此格式的媒体工具)，每一个fmt只能有一个此描述
      • 格式：a=fmtp:<fmt> <format specific parameters>
      • 例子：a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
      • 说明：
        • fmt：媒体会话描述(m=)中指定的编码格式
        • format specific parameters：fmt对应的透传参数
        • level-asymmetry-allowed=1 => 是否允许两端的编码level不一致，必须SDP双方都为1
        • packetization-mode=1 => NALU打包方式，1表示，每帧图像被拆分到多个NALU单元传送，这些NALU单元传送的顺序是按照解码的顺序发送的
        • profile-level-id=42e01f => 指定H264的baseline和level等参数
    • a=extmap，扩展，支持什么协议
      • 例子：a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
    • a=sendrecv 媒体流的方向，既可以在会话描述中，也可以在媒体描述中
      • 例子： a=sendonly //仅发送
      • 说明：
        • sendrecv: 双向传输，即发送也接收
        • sendonly: 只发送数据
        • revonly: 只接收数据
        • inactive: 禁止发送数据
    • a=ssrc，RTC场景下音视频流和RTP/RTCP复用单一端口，通过SSRC区分每一路流，通过数据包的头部字段值来区分RTC/RTCP
      • 例子：
        a=ssrc:3459677730 cname:648fef7tl720yj49
a=ssrc:3459677730 label:audio-8804l2a1
a=ssrc:3459677731 cname:648fef7tl720yj49
a=ssrc:3459677731 label:video-7h7733ci
      • 说明：cname是RTCP为每个RTP用户提供的一个全局唯一的规范名称标识符，描述该RTP流对应的RTCP协议中的cname。
      • label对应MediaStreamTrack ID
    • a=mid，当前媒体级别描述的ID，相当于给媒体级别描述编号
      • 例子：
        a=mid:audio   //audio就是当前这个媒体级别描述(m=)的ID
a=mid:1   //同理，mid后面的值也可以是数字
  • 网络描述
    • c=，指明接收或者发送音视频使用的IP地址，webrtc使用ICE传输，这个被忽略
      • 格式：c=<nettype> <addrtype> <connection-address>
      • 例子：c=IN IP4 0.0.0.0
      • 说明：可以是会话级别或者是媒体级别，如果是媒体级别则每一个媒体级别描述都必须至少包含一个
    • a=candidate，candidate信息，传输的候选人，有host(主机)类型，有replay（反射）类型等
      • 格式：c=candidate:<foundation> <component-id> <transport> <priority> <conn-addr> <conn-port> <cand-type> <candidate-types>
      • 例子：
        // 传输协议是udp，优先级是2130706431
// ip地址是124.221.111.76，端口8000，candidate的类型是host类型(即ip地址是主机的ip地址)
// 候选者的代数式0，表示最初生成的
a=candidate:0 1 udp 2130706431 124.221.111.76 8000 typ host generation 0
      • 说明：candidate信息可以有多个
  • 安全描述
    • a=crypto
    • a=ice-ufrag，ice short-term认证算法用到的用户名
    • a=ice-pwd， ice short-term认证算法用到的密码
    • a=fingerprint DTLS过程中的Certificate整数的签名
  • DTLS角色
    • a=setup
      • 例子：a=setup:passive
      • 说明：指定DTLS角色，Active：客户端，Passive：服务端，两者都可以则是actpass
  • ICE策略
    • a=ice-options:trickie
      • 说明：trickie说明SDP中没有包含candidate信息，candidate是通过信令单独交换的，client一边收集candidate，一边发送给对端进行连通性检查，提高连通性检查和候选捕获的速度
    • a=ice-lite
      • ICE的实现分为以下两种
        • Full ICE: 参与连接的两端都需要进行连通性检查
        • Lite ICE: 在Full ICE和Lite ICE连接时，只需要Full ICE一方进行连通性检查，Lite一方只需要回应Response消息就行。这种模式常用语公网设备
    • a=ice-option:renomination
      • 说明：允许 ICE controlling 一方动态重新提名新的 candidate ，默认情况 Offer 一方为controlling 角色，answer 一方为 controlled 角色；同时 Lite 一方只能为 controlled 角色
  • QOS，Grouping传输描述
    • a=rtcp-fb，支持的RTC反馈类型报文，媒体级别描述作用域
      • 例子：
        a=rtcp-fb:111 transport-cc   // 对于111这个fmt支持transport-cc这个报文
a=rtcp-fb:106 transport-cc  // 同理
a=rtcp-fb:106 nack              // 对于106这个fmt在ARQ上支持nack
a=rtcp-fb:106 nack pli			// 对于106这个fmt在关键帧上支持pli处理
      • 注意：rtcp-fb不能用于会话级别描述，只能用于媒体级别描述，而且在m=描述的协议字段一定要有AVPF
    • a=group
      • 例子：a=group:BUNDLE 0 1
      • 说明：表示mid值为0和1的媒体会话描述(m=)进行复用端口传输
    • a=rtcp-mux
      • 说明：rtcp和rtp复用一个端口号

浏览器创建的本地Offer

通过SRS提供的RTC播放H5页面(http://localhost:8080/players/rtc_player.html?autostart=true)可以去拉取SRS上的RTC流（参考文章：SRS调试webrtc流），点击页面的播放视频，可以看到RTC播放页面请求了一个http接口，其中携带H5的local sdp。
播放页面请求的内容
local sdp的详细内容如下：

v=0
o=- 4052671107298259095 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:PTFm
a=ice-pwd:SjhcZkVwk0wlE9AAjAeFrv93
a=ice-options:trickle
a=fingerprint:sha-256 55:20:7B:84:80:3C:3A:95:17:C0:BE:0B:3C:23:DB:46:3A:58:29:87:1A:B1:E6:8C:53:9A:27:19:0C:BE:CF:86
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:126 telephone-event/8000
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 35 36 37 38 102 103 104 105 106 107 108 109 127 125 39 40 41 42 43 44 45 46 47 48 112 113 114 115 116 49
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:PTFm
a=ice-pwd:SjhcZkVwk0wlE9AAjAeFrv93
a=ice-options:trickle
a=fingerprint:sha-256 55:20:7B:84:80:3C:3A:95:17:C0:BE:0B:3C:23:DB:46:3A:58:29:87:1A:B1:E6:8C:53:9A:27:19:0C:BE:CF:86
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:35 VP9/90000
a=rtcp-fb:35 goog-remb
a=rtcp-fb:35 transport-cc
a=rtcp-fb:35 ccm fir
a=rtcp-fb:35 nack
a=rtcp-fb:35 nack pli
a=fmtp:35 profile-id=1
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:37 VP9/90000
a=rtcp-fb:37 goog-remb
a=rtcp-fb:37 transport-cc
a=rtcp-fb:37 ccm fir
a=rtcp-fb:37 nack
a=rtcp-fb:37 nack pli
a=fmtp:37 profile-id=3
a=rtpmap:38 rtx/90000
a=fmtp:38 apt=37
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:103 rtx/90000
a=fmtp:103 apt=102
a=rtpmap:104 H264/90000
a=rtcp-fb:104 goog-remb
a=rtcp-fb:104 transport-cc
a=rtcp-fb:104 ccm fir
a=rtcp-fb:104 nack
a=rtcp-fb:104 nack pli
a=fmtp:104 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:105 rtx/90000
a=fmtp:105 apt=104
a=rtpmap:106 H264/90000
a=rtcp-fb:106 goog-remb
a=rtcp-fb:106 transport-cc
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack
a=rtcp-fb:106 nack pli
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=106
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f
a=rtpmap:125 rtx/90000
a=fmtp:125 apt=127
a=rtpmap:39 H264/90000
a=rtcp-fb:39 goog-remb
a=rtcp-fb:39 transport-cc
a=rtcp-fb:39 ccm fir
a=rtcp-fb:39 nack
a=rtcp-fb:39 nack pli
a=fmtp:39 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=4d001f
a=rtpmap:40 rtx/90000
a=fmtp:40 apt=39
a=rtpmap:41 H264/90000
a=rtcp-fb:41 goog-remb
a=rtcp-fb:41 transport-cc
a=rtcp-fb:41 ccm fir
a=rtcp-fb:41 nack
a=rtcp-fb:41 nack pli
a=fmtp:41 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=f4001f
a=rtpmap:42 rtx/90000
a=fmtp:42 apt=41
a=rtpmap:43 H264/90000
a=rtcp-fb:43 goog-remb
a=rtcp-fb:43 transport-cc
a=rtcp-fb:43 ccm fir
a=rtcp-fb:43 nack
a=rtcp-fb:43 nack pli
a=fmtp:43 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=f4001f
a=rtpmap:44 rtx/90000
a=fmtp:44 apt=43
a=rtpmap:45 AV1/90000
a=rtcp-fb:45 goog-remb
a=rtcp-fb:45 transport-cc
a=rtcp-fb:45 ccm fir
a=rtcp-fb:45 nack
a=rtcp-fb:45 nack pli
a=rtpmap:46 rtx/90000
a=fmtp:46 apt=45
a=rtpmap:47 AV1/90000
a=rtcp-fb:47 goog-remb
a=rtcp-fb:47 transport-cc
a=rtcp-fb:47 ccm fir
a=rtcp-fb:47 nack
a=rtcp-fb:47 nack pli
a=fmtp:47 profile=1
a=rtpmap:48 rtx/90000
a=fmtp:48 apt=47
a=rtpmap:112 H264/90000
a=rtcp-fb:112 goog-remb
a=rtcp-fb:112 transport-cc
a=rtcp-fb:112 ccm fir
a=rtcp-fb:112 nack
a=rtcp-fb:112 nack pli
a=fmtp:112 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f
a=rtpmap:113 rtx/90000
a=fmtp:113 apt=112
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 ulpfec/90000
a=rtpmap:49 flexfec-03/90000
a=rtcp-fb:49 goog-remb
a=rtcp-fb:49 transport-cc
a=fmtp:49 repair-window=10000000

SRS返回的远端Answer

SRS在srs_app_rtc_api.cpp文件中的SrsGoApiRtcPlay类中处理offer请求，返回内容如下
SRS返回的远端Answer
远端Answer内容如下：

v=0  // 会话级描述：SDP协议版本，固定为0
o=SRS/4.0.245(Leo) 17778048 2 IN IP4 0.0.0.0   // 会话级描述
s=SRSPlaySession
t=0 0
a=ice-lite
a=group:BUNDLE 0 1
a=msid-semantic: WMS live/livestream
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=ice-ufrag:j0w47g4z
a=ice-pwd:879b5n40s824s1985h3z60s77a8132v1
a=fingerprint:sha-256 A8:83:2B:5D:FF:E2:5A:14:6C:0A:24:A0:11:C3:01:8A:4A:8E:AF:3F:AC:B6:67:EE:3C:4B:47:07:7E:7B:D9:6F
a=setup:passive
a=mid:0
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=sendonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=ssrc:3459677730 cname:648fef7tl720yj49
a=ssrc:3459677730 label:audio-8804l2a1
a=candidate:0 1 udp 2130706431 124.221.111.76 8000 typ host generation 0
m=video 9 UDP/TLS/RTP/SAVPF 106
c=IN IP4 0.0.0.0
a=ice-ufrag:j0w47g4z
a=ice-pwd:879b5n40s824s1985h3z60s77a8132v1
a=fingerprint:sha-256 A8:83:2B:5D:FF:E2:5A:14:6C:0A:24:A0:11:C3:01:8A:4A:8E:AF:3F:AC:B6:67:EE:3C:4B:47:07:7E:7B:D9:6F
a=setup:passive
a=mid:1
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=sendonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:106 H264/90000
a=rtcp-fb:106 transport-cc
a=rtcp-fb:106 nack
a=rtcp-fb:106 nack pli
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=ssrc:3459677731 cname:648fef7tl720yj49
a=ssrc:3459677731 label:video-7h7733ci
a=candidate:0 1 udp 2130706431 124.221.111.76 8000 typ host generation 0

总结

对比本地和远端SDP发现，浏览器提供的特性非常多，SRS提供的较少，SRS是Lite ICE客户端，无需进行连通性检测。

参考文档

https://blog.csdn.net/aggresss/article/details/109850434
https://www.livevideostack.cn/news/webrtc-sdp-details-and-analysis/
https://blog.csdn.net/zqxf123456789/article/details/109696266
RFC4566
从0打造音视频直播系统（李超）

xfc_1939
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
SRS流媒体服务器源码分析（一）：Rtmp publish流程
irainsa的博客
02-18 611
客户端Rtmp推流到服务器，服务器将消息缓存到各个客户端消费者自己的队列中，数据使用引用计数没有内存拷贝操作。过期数据将被清除。客户端消费者是SrsRtmpConnPlay类型，消费者播放流的流程在下一篇文章中介绍。SRS流媒体服务器源码分析（一）：Rtmp publish流程 - 简书。
webrtc-sdp:用于WebRTC的Rust SDP解析器
05-15
用Rust编写的SDP解析器专门用于处理WebRTC SDP的要约和答案。 依存关系 锈> = 1.45.0 日志模块 SERDE模块 丝氨酸衍生模块 第一次构建webrtc-sdp时，Cargo会自动安装缺少的模块。 webrtc-sdp API 主要功能是： ...
【网络通信 -- 直播】SRS 实战记录 -- SDP 协商 HTTP API 测试
CopperSun 技术博客
05-07 809
【网络通信 -- 直播】SRS 实战记录 -- SDP 协商 HTTP API 测试 【1】PostMan 使用指南 PostMan 发送 Json 请求 选择 post 请求方式，设置 header 的 content-type 设置为 application/json，设置 body 的编码方式为 raw，设置文本格式为 JSON 【2】SRS 中 SDP 协商的 HTTP API 接口测试记录 SRS 发布 HTTP-API 接口 接口格式与参数说明 Request: ..
srs源码分析(一)
qq_34062754的博客
10-26 599
由于工作中的需要，需要用到srs流媒体服务器，所以在此做个了解。 源码下载地址: https://github.com/ossrs/srs 先来看看整体流程架构，图片来自https://blog.csdn.net/adkada1/article/details/120583331
SRS4.0源码分析-序言
u012117034的博客
04-11 2647
《SRS4.0源码分析》专栏，会从 configure（配置），makefile（编译规则），main （入口函数）， 带你一步一步了解 SRS 的主干代码逻辑。 这里分享一个本人阅读开源项目源码的技巧，大部分比较好的开源项目 模块划分都比较完善，初学者开始只需要了解主干逻辑，其他各个模块的细节用到的时候再仔细研究即可，不需要一开始就把全部的代码逻辑吃透，下面是ffmpeg项目的主干逻辑以及各个模块的分布。 开源项目动辄几十万行代码，如果没有好的模块划分，会很难维护，在早期就会死掉，所以一般活下..
【网络通信 -- 直播】SRS 源码分析 -- RTMP 视频流转 WebRTC 视频流分析
CopperSun 技术博客
08-06 473
【网络通信 -- 直播】SRS 源码分析 -- RTMP 视频流转 WebRTC 视频流分析 SrsRtcFromRtmpBridger 类相关方法调用时机 创建并初始化 SrsRtcFromRtmpBridger 实例 SrsRtmpConn::publishing(SrsLiveSource* source) -> SrsRtmpConn::acquire_publish(SrsLiveSource* source) -> 寻找或创建一个 RTC 源，即 SrsRtcSource 实
SRS 代码分析
SK的博客
12-04 3844
SRS 代码分析 1.SRS 代码分析【服务器启动】 2.SRS 代码分析【RTMP连接请求响应】 3.SRS 代码分析【FLV文件解析】 4.SRS 代码分析【HTTP-FLV传输实现】 5.SRS 代码分析【HLS切片】
SRS4.0源码分析-CMake
u012117034的博客
04-11 1308
本文采用的 SRS 版本是 4.0-b8 ， 下载地址：github 《SRS4.0源码分析-调试环境搭建》 讲了 SRS 在Clion里面的调试，本文主要讲解srs-4.0-b8\trunk\ide\srs_clion目录下 的CMakeLists.txt文件的编译逻辑。 CMake是对makefile的一种封装，CMake最后会生成makefile文件，再执行make命令。 makefile可以看 左耳朵耗子的《跟我一起写Makefile》。 CMake能找到的简...
SRS4.0源码分析-SrsRecvThread::cycle
u012117034的博客
04-12 567
本文采用的 SRS 版本是 4.0-b8 ， 下载地址：github 从《SRS4.0源码分析-SrsRtmpConn::stream_service_cycle》 得知 ，真正接受客户端音视频流数据的地方是SrsRecvThread::cycle()。 那客户端推视频流来之后，服务器有没缓存？服务器缓存多少秒？怎么配置 SRS 让 RTMP 直播的延迟降低？ 带着这些疑问，开始研究。SrsRecvThread::cycle()函数 的 代码如下： 上面的变量pumper是SrsP...
js-sdp-parser:使用javascript来构建和解析sdp协议
06-18
`js-sdp-parser`是一个开源项目，它提供了使用JavaScript来构建和解析SDP协议的能力，这对于在浏览器环境中进行实时通信开发至关重要。 ### SDP协议简介 SDP协议的主要作用是描述多媒体会话的属性，如音频、视频...
SRS开源代码
04-17
SRS开源代码，用于直播点播系统，支持编解码，可用于搭建直播、录播系统
java版斗地主源码-EasyPR-SDP:EasyPR-SDP
06-04
java版斗地主源码 EasyPR EasyPR是一个开源的中文车牌识别系统，其目标是成为一个简单、高效、准确的非限制场景(unconstrained situation)下的车牌识别库。 相比于其他的车牌识别系统，EasyPR有如下特点： 它基于...
bt-sdp.rar_BT SDP
09-21
【BT SDP（蓝牙服务发现协议）详解】 蓝牙服务发现协议（Bluetooth Service Discovery Protocol, BT SDP）是蓝牙...在QEMU中，`bt-sdp.c`源码实现了SDP服务器，模拟了这一过程，对理解和调试蓝牙应用具有重要价值。
sdp文件解析源码，可以实现一般sdp文件解析
03-10
源码分析和学习SDP文件解析可以帮助我们理解多媒体会话的建立过程，这对于开发自定义播放器或者实现RTP通信系统至关重要。源码中的关键函数可能会涉及读取文件、分割行、解析键值对、处理媒体描述等操作。通过调试和...
SRS4.0源码分析-main
u012117034的博客
04-11 882
本文采用的 SRS 版本是 4.0-b8 ， 下载地址：github 本文开始讲解 SRS 的入口文件。SRS 源码里 其实有 3 个main()函数，分别在srs_main_ingest_hls.cpp，srs_main_mp4_parser.cpp，srs_main_server.cpp3 个文件里面，如图： 不过srs可执行文件，是srs_main_server.cpp生成的，所以先分析srs_main_server.cpp，其他两个文件不管。 main()函数的流程图如...
SRS4.0源码分析-RTMP入口
u012117034的博客
04-11 2447
本文采用的 SRS 版本是 4.0-b8 ， 下载地址：github 上篇文章《SRS4.0源码分析-main》讲解了 SRS main 函数的基本流程，但是可能有些朋友还是比较懵逼。说实话，其实对于SRS的具体逻辑流程，我现在也是比较懵逼。在这里，分享一个研究开源项目源码的经验，怎么快速跳出这种懵逼的状态。 首先，研究一个项目的源码，需要有一个目标。例如之前《RTMP协议分析》的系列文章，已经讲解了一个RTMP客户端的实现，我研究 SRS 的源码就是为了看一下RTMP服务器端是如何实现的。...
SRS的配置文件模块SrsConfig—SRS源码分析
u012117034的博客
12-25 353
SRS 的信号处理也是一个比较有趣的设计，他会把信号事件 传递给 pipe 管道，因为 pipe 是 IO 操作，所以就可以用协程来处理了。配置文件的代码还是比较简单的，稍微比较复杂的是 配置文件的 reload 功能。你看一遍他的代码注释，然后自己断点调试一下，就知道是解析处理之后的结果是怎样的了。以外的配置选项进行热加载，但是我测试下来还是有一些配置是不支持热加载的，例如。命令行参数的解析逻辑比较简单，这里就不说了，跳过。开头的，这是 SRS 的命名习惯。开头的，而订阅者里面的方法是。
SRS(simple-rtmp-server)流媒体服务器源码分析--启动
热门推荐
ManagerUser的博客
06-28 1万+
SRS(simple-rtmp-server)流媒体服务器源码分析--系统启动
SRS源码分析-读写类SrsStSocket
编码之路
11-05 917
关键类SrsStSocket封装了socket的读写操作，将负责将数据发送给对端(send)以及读取对端发送过来的数据（read）。 继承关系为： 相关源码如下： //使用协程的TCP class SrsStSocket : public ISrsProtocolReaderWriter { private: // The recv/send timeout in ms. // ...
AGK-SDP200
最新发布
02-22
AGK-SDP200是一款由AGK Robotics开发的自动化导航机器人。它具有先进的导航和感知能力，可以在室内环境中自主移动和执行任务。以下是AGK-SDP200配备了激光雷达和摄像头等传感器，可以实时感知周围环境并进行地图构建和定位，从而实现精确的导航和避障。 2. 自主移动：AGK-SDP200可以根据预设的任务和路径规划，在室内环境中自主移动，并且可以适应不同的地面和障碍物。 3. 任务执行：AGK-SDP200可以执行各种任务，如巡检、运输、送货等。它可以携带货物，并且具有自动装卸货物的功能。 4. 用户界面：AGK-SDP200配备了触摸屏和语音交互功能，用户可以通过简单的操作界面或语音指令与机器人进行交互和控制。 5. 安全性：AGK-SDP200具有多重安全保护机制，包括碰撞检测、紧急停止按钮等，以确保在操作过程中的安全性。 6. 可定制性：AGK-SDP200可以根据用户的需求进行定制和配置，以适应不同的应用场景和任务需求。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值