Skip to main content
版本：7.0 (Unstable) 🚧

GB28181

支持GB28181是正确的事情，可能也是困难的事情，因为困难所以有趣。

重要说明：SRS 5.0已经是beta或更稳定的版本，推荐使用SRS 5.0的GB，而不要使用4.0的GB，因为虽然4.0是稳定发布版本，但是4.0的GB是实验性的和不稳定的。

研发的详细过程请参考#3176。

Usage

首先，编译和启动SRS，请确认版本为5.0.74+：

./configure --gb28181=on
make
./objs/srs -c conf/gb28181.conf

Note: 如果你是公网服务器，一定要配置对Candidate，请参考Candidate的说明。

然后，在摄像头配置中，选择AAC编码，然后在平台中配置SIP服务器为SRS，如下图所示：

  • 必须是AAC编码，在音频编码中，选择AAC，采样率44100HZ。
  • 必须是GB-2016标准，否则不支持TCP，在协议版本中选择GB/T28181-2016。
  • 必须是TCP协议，不支持UDP，在传输协议中选择TCP，并使用GB-2016标准。

摄像头注册后，SRS会自动邀请摄像头推流，可以打开下面的链接播放：

Note: 请把流名称换成你的设备名称，然后点播放。

Candidate

如果服务器IP不是内网IP，比如部署在公网，则SRS无法获取自己的出口IP，需要配置：

stream_caster {
    enabled on;
    caster gb28181;
    listen 9000;
    sip {
        enabled on;
        listen 5060;
        candidate a.b.c.d;
    }
}

Note: 请将stream_caster.sip.candidate换成摄像头能访问到你的服务器的IP，不管是内网还是公网IP，摄像头能访问到就可以。

GB的Candidate定义和WebRTC: Candidate概念上一致，都是需要暴露一个客户端能访问的IP地址，在SDP中传递给客户端。比如：

  1. 在SRS配置中设置stream_caster.sip.candidate，SRS启动会读取这个配置，比如192.168.1.100。
  2. GB设备通过SIP注册到SRS，SRS发起INVITE消息，消息的Body就是SDP，SDP会指定这个IP地址，比如IN IP4 192.168.1.100。
  3. GB设备连接这个IP地址tcp://192.168.1.100:9000，并发起媒体请求。

Note: 媒体的端口是配置在stream_caster.listen中的，目前只支持TCP端口。

这个CANDIDATE就是媒体服务器的IP，它和SIP的服务器地址可以是不同的，SIP服务器地址是在Usage中配置在客户端的。

Note: 由于GB的SIP协议，在REGISTER时To字段并没有带服务器的地址，所以导致服务器无法从SIP中发现自己的地址，只能依靠服务器配置。

当然，如果网卡配置了客户端可以访问的地址，可以把CANDIDATE配置为*，让SRS自己发现。

Latency

与普遍认知相反，安全摄像头并非天生就是低延迟系统。它们的主要目的是长期存储。在平移-倾斜-缩放（PTZ）场景中，可能存在一定的延迟要求， 但这并不是我们通常所说的低延迟。PTZ摄像头的延迟通常在1秒左右，这被认为是可以接受的，而实时通信（RTC）中的低延迟通常在200ms左右。

延迟不仅与服务器有关，还涉及到整个链路。关于详细的延迟优化，请参考Low Latency。 我使用默认配置测试了海康威视摄像头的延迟，如下所示：

  • 流类型：子流
  • 视频类型：复合流
  • 分辨率：640x480
  • 码率类型：可变码率
  • 图像质量：中等
  • 视频帧率：25fps
  • 码率限制：1024Kbps
  • 视频编码：H.264
  • 编码复杂度：中等
  • I帧间隔：50
  • SVC：禁用
  • 平台接入协议：GB/T28181-2016
  • 平台传输协议：TCP，即通过GB/TCP将流推送到SRS
  • 观看：WebRTC(UDP)
  • SRS版本：v5.0.100
  • 摄像头和服务器：内网
  • 延迟：358ms

Features

目前SRS支持的GB的功能清单：

  1. 摄像头通过SIP注册。srs-gb28181支持。SRS 5.0 支持。
  2. 自动邀请摄像头推流。srs-gb28181支持。SRS 5.0 支持。
  3. GB/2016转RTMP协议。srs-gb28181支持。SRS 5.0 支持。
  4. 基于TCP的SIP信令。srs-gb28181支持。SRS 5.0 支持。
  5. TCP单端口传输媒体。srs-gb28181支持。SRS 5.0 支持。

目前还没有支持的GB功能：

  1. 基于UDP的SIP信令。srs-gb28181支持。SRS 5.0 不支持。
  2. UDP单端口传输媒体。srs-gb28181支持。SRS 5.0 不支持。
  3. GB/2011转RTMP协议。srs-gb28181支持。SRS 5.0 不支持。
  4. UDP/TCP多端口传输媒体。srs-gb28181支持。SRS 5.0 不支持。
  5. HTTP API查询GB流。srs-gb28181支持。SRS 5.0 不支持。
  6. HTTP API云台摄像头。srs-gb28181支持。SRS 5.0 不支持。
  7. Web管理页面。srs-gb28181支持。SRS 5.0 不支持。
  8. GB下级服务器。srs-gb28181不支持。SRS 5.0 不支持。
  9. GB语音对讲。srs-gb28181不支持。SRS 5.0 不支持。
  10. GB回看。srs-gb28181不支持。SRS 5.0 不支持。
  11. GB加密传输。srs-gb28181不支持。SRS 5.0 不支持。

希望大家降低期望，GB的坑太难填了，希望不要期待SRS能做多好。

Protocols

GB相关的协议如下：

External SIP

Note: SRS 6.0.144+支持外部SIP，若需要使用这个功能，请升级到这个版本。

目前SRS内置的SIP服务器仅实现了简单的Register、Invite指令，而要实现GB/T-28181的全部功能，势必会引入复杂的上层业务逻辑。 因此，我们开发了一个独立的外置的SIP服务器。而SRS，只需开放几个简单的API接口，这样既保证了其媒体转发服务器的单一属性， 又兼顾了与第三方SIP信令服务器对接的需求。

播放器请求SRS-SIP，SRS-SIP向SRS Server申请媒体端口，然后邀请GB28181 Device设备推流。设备推流到SRS后，播放器直接从SRS播放流。 下面是几个组件的关系图，详细的交互时序图参考srs-sip

     +-------------API/Media--------------------+
     |                                          |
+----------+       +------------+        +------+------+             +----------------+
| Player   +--API--+  SRS-SIP   +---API--+  SRS Server +----Media----+ GB28181 Device +
+----------+       +-----+------+        +-------------+             +-------+--------+
                         |                                              |
                         +------------------SIP-------------------------+

Note: 暂时没有实现鉴权功能，敬请期待。

摄像头上面的配置方法同上，仅需将SIP服务器地址从SRS改成SRS-SIP。

首先启动SRS，请确认版本为6.0.144+，使用配置conf/gb28181-without-sip.conf，参考Usage。

./objs/srs -c conf/gb28181-without-sip.conf

然后启动SRS-SIP，参考srs-sip。

./bin/srs-sip -sip-port 5060 -media-addr 127.0.0.1:1985 -api-port 2020 -http-server-port 8888
  • -sip-port是SIP服务器的端口，默认是5060。GB摄像头和这个SIP服务器通信，完成设备注册等能力。
  • -media-addr是SRS的媒体服务器地址，SIP服务器返回这个地址给GB摄像头，GB摄像头推流到这个地址。
  • -api-port是SIP服务器的API端口，默认是2020。这个API是给Player和用户使用的，比如查询设备列表、要求摄像头推流等。
  • -http-server-port是SIP服务器的Web端口，默认是8888。这个HTTP服务器是提供网页的web服务器，用户通过网页访问摄像头。

启动GB28181设备，将SIP服务器地址改成SRS-SIP的地址，端口为5060。

现在，可以通过SRS-SIP内置的网页播放器测试 http://localhost:8888

SIP Parser

SRS本身也内嵌了一个简单的SIP服务器，支持部分SIP协议的解析；不过C++没有特别好的SIP库，这也是之前SIP处理不稳定的一个原因。

调研发现，SIP协议和HTTP协议结构非常一致，因此SRS采用http-parser解析SIP，这个库是nodejs维护的，之前好像是NGINX中扒出来的，所以稳定性还是非常高的。

当然用HTTP解析SIP，需要有些修改，主要是以下修改：

  • Method：需要新增几个方法，比如REGISTER、INVITE、ACK、MESSAGE和BYE，这是GB常用的几个消息。
  • RequestLine：解析path时需要修改，SIP是sip:xxx格式，会被认为是HTTP完整URL格式导致解析失败。
  • ResponseLine：生成Response时需要修改，主要是协议头，从HTTP/1.1改成SIP.2.0。

基本上改变非常小，所以协议稳定性是可以保障，可以算是解决了一个难题。

SIP和HTTP不同的是，在同一个TCP通道中，并不一定就是一个Request对应一个Response，比如INVITE之后，可能会有100和200两个响应，而SRS也不固定就是Server，也有可能是Client。而这些情况，http-parser可以设置为BOTH方式，这样可以解析出Request和Response：

    SrsHttpParser* parser = new SrsHttpParser();
    SrsAutoFree(SrsHttpParser, parser);

    // We might get SIP request or response message.
    if ((err = parser->initialize(HTTP_BOTH)) != srs_success) {
        return srs_error_wrap(err, "init parser");
    }

Note: 从HTTP消息来看，并没有规定只能一个Request对应一个Response，因此这个也不会带来额外问题。

在实际解析中，发现有时候发送的头有空格，比如：

Content-Length:         142\r\n

这实际上是符合规范的，但如果手动解析可能会有问题，而HTTP-Parser能正确处理这种情况。

REGISTER

GB的注册流程：

  1. 在设备设置好SIP服务器为SRS。
  2. 设备发送SIP格式的REGISTER消息。
  3. SRS回应200/OK，注册成功。

GB的心跳：

  1. 设备后面会不断发送MESSAGE作为心跳消息。
  2. SRS回应200/OK，心跳成功。

SRS若重启后，由于没有保存任何状态，所以收到的可能是设备的MESSAGE消息，而没有REGISTER消息，所以希望设备能重新注册。向各位同学以及SIP和GB的专家请教后，重新注册的可能方法包括：

  • 不回应MESSAGE消息，一般3次心跳超时（在设备配置上有设置）。验证发现，海康设备心跳周期默认60秒，所以大概在3分钟左右会重新注册。
  • 对MESSAGE回应403或者其他消息。验证发现，效果和不回应一样，设备并不会特别处理。
  • 给设备发送重启指令，参考A.2.3 控制命令，远程启动是<TeleBoot>Boot</TeleBoot>，尝试重启设备后会重新注册。这个还没验证。
  • 回应REGISTER消息时，将EXPIRE设置短一些，缩短注册的间隔，比如改成30秒。验证发现，尽管设置为30秒，但还是会在一个心跳时间才会重新注册，也就是60秒。
  • 在设备的配置上，将心跳周期改短一些，默认60秒，最小是5秒，这样超时会更快。验证发现，心跳改5秒，最短可以26秒左右重新注册。
  • 加一层SIP Proxy，让Proxy来保存相关的信息，将状态转移到Proxy。这个方案应该可行，不过SRS不太合适，引入额外组件会让开源很复杂，大家自己的实现中可以尝试。
  • 重启前发消息。这个方案在SRS Gracefully Quit时有效，但有时候会kill -9或者系统OOM，不会给程序机会清理，所以这个不能适应所有场景。不过在主动升级时，一般会用Gracefully Quit，这时可以有机会处理这个问题，大家可以尝试。

总之，是没有特别可靠的办法能让摄像头立刻重新注册，SRS必须在逻辑上处理这个问题：SRS启动或重启后，摄像头还在已经注册，甚至在传输流的状态。

Note: 由于很多问题都是持续长时间运行，而系统的某一方重启了，导致状态不一致，引起各种问题。因此，在SRS重启或者启动时，若发现有摄像头是在注册或传输流的状态，那么应该尝试让摄像头重新走一次流程，比如重新注册和重新推流，这样让双方的状态一致，可靠性会更高。

Note: 验证发现，重新注册，对正在传输的媒体流不影响。设备会探测端口可达性，如果TCP断开，或者UDP端口不可达，则会停止流传输。

TCP or UDP

在使用TCP或UDP协议上，我们选择先支持TCP协议，包括SIP信令和PS媒体。

根据SIP协议的规定，TCP是必须要支持的，也是RFC3261比RFC2543一个重要的更新，参考RFC3261: Transport。

至于媒体协议，GB由于使用了PS格式，其实PS一般是用于存储格式，而TS是网络传输格式，或者说TS考虑了更多的网络传输问题，而PS则更多假设像磁盘读写文件一样可靠，因此，PS基于TCP传输也会更加简单。

GB 2016中对于TCP的描述在附录L，即基于TCP协议的视音频媒体传输：

实时视频点播、历史视频回放与下载的TCP媒体传输应支持基于RTP封装的视音频PS流，封装格式参照IETF RFC 4571。

在实际应用中，大部分也是使用TCP，而不是用UDP，特别在公网上UDP会有丢包，而GB没有设计重传或FEC。使用TCP的好处：

  • UDP由于无状态，在服务器重启时，设备感知不到服务重启，可能还能继续传输数据，导致两边状态不同步，长久持续这样可能会导致问题，比如设备会提示请求超过上限。
  • GB的信令和媒体分离，如果使用TCP则可以很好的同步状态，比如信令可用媒体不可用或断开，媒体可用信令不可用，这些最终都反应到连接的断开。具体请参考Protocol Notes。
  • 服务器重启后，可以使用缩短REGISTER的Expires，缩短心跳间隔，让设备重新注册，重新进入推流状态。服务器重启后，设备可以快速感知到媒体链路断开。
  • 传输过程中，若出现网络抖动导致链接断开，服务器和设备都可以很快感知到，进入异常处理流程。

因此，SRS先支持TCP，而不支持UDP。也就是先支持GB28181 2016，而不是支持GB28181 2011。

Note: 需要显式开启GB28181-2016，并开启TCP协议才可以。

Protocol Notes

SIP协议上特别需要注意的地方：

  • Via的branch必须是z9hG4bK开头，参考Via的说明。
  • INVITE的200(OK)的ACK消息，ACK的Via的branch必须是新的，ACK并不是INVITE的transaction，参考Via和Example。
  • INVITE的Contact是自己的地址，而不是GB设备的，也就是Contact应该由From生成而不是To，参考Contact和Example。
  • INVITE的Subject，定义为媒体流发送者ID:发送方媒体流序列号,媒体流接收者ID:接收方媒体流序列号，参考附录K。对于s=Play实时观看的场景，接收方媒体流序列号(SSRC)其实没有定义；根据各位同学反馈，一般这个字段填0。

SDP协议上特别注意的地方：

  • y字段: 为十进制整数字符串, 表示SSRC值。格式如下:dddddddddd。其中, 第1位为历史或实时媒体流的标识位, 0为实时, 1为历史；第2位至第6位取20位SIP监控域ID之中的4到8位作为域标识, 例如13010000002000000001中取数字10000; 第7位至第10位作为域内媒体流标识, 是一个与当前域内产生的媒体流SSRC值后4位不重复的四位十进制整数。

Note: SDP中的y=字段，是GB扩展的字段，在WebRTC中是用a=ssrc:xxxx表达的SSRC。

信令和媒体配合：

媒体协议：

  • 解析媒体流时，可能会出现各种错误，此时会丢弃整个pack的数据，直到下一个pack到来(00 00 01 ba)。其中包括RTP解析失败，非法的PS头(非00 00 01开头)，部分PES头(比如在前一个TCP包的尾部)，甚至还有RFC4571的包解析失败(头两个字节代表的长度信息是0)。
  • SRS支持恢复模式，遇到解析摄像头的包失败会进入恢复模式，但有时候也会出现无法恢复的情况，因此会限制每次最大的恢复次数，如果连续多个包还不能恢复，那就断开媒体连接，进入信令重新INVITE的过程。若包长度异常，很大概率是无法恢复，则关闭恢复模式，直接进入重新INVITE流程。
  • 媒体使用MPEGPS流，其中length为16位，也就是PES最大长度为64KB。PS是对超过64KB的帧直接分包，分成多个PES，按照时间戳组合；另外，一个pack中只有一个Video，可能会有多个Audio，因此Audio每帧不超过64KB。示例如下所示：

媒体PS组包，超过64KB的情况：

PS: New pack header clock=2454808848, rate=159953
PS: New system header rate_bound=159953, video_bound=1, audio_bound=1
PS: Got message Video, dts=2454808848, seq=22204, base=2454808848 payload=29B, 0, 0, 0, 0x1, 0x67, 0x4d, 0, 0x32
PS: Got message Video, dts=0, seq=22204, base=2454808848 payload=8B, 0, 0, 0, 0x1, 0x68, 0xee, 0x3c, 0x80
PS: Got message Video, dts=0, seq=22204, base=2454808848 payload=9B, 0, 0, 0, 0x1, 0x6, 0xe5, 0x1, 0x2b
PS: Got message Video, dts=0, seq=22250, base=2454808848 payload=65471B, 0, 0, 0, 0x1, 0x65, 0xb8, 0, 0
PS: Got message Video, dts=0, seq=22252, base=2454808848 payload=2112B, 0x48, 0x4c, 0xf2, 0x94, 0xaa, 0xbc, 0xed, 0x3d
PS: Got message Audio, dts=2454812268, seq=22253, base=2454808848 payload=99B, 0xff, 0xf9, 0x50, 0x40, 0xc, 0x7f, 0xfc, 0x1
PS: Got message Audio, dts=2454814338, seq=22254, base=2454808848 payload=96B, 0xff, 0xf9, 0x50, 0x40, 0xc, 0x1f, 0xfc, 0x1

PS: New pack header clock=2454812448, rate=159953
PS: Got message Video, dts=2454812448, seq=22283, base=2454812448 payload=39457B, 0, 0, 0, 0x1, 0x61, 0xe0, 0x8, 0xbf
PS: Got message Audio, dts=2454816498, seq=22284, base=2454812448 payload=101B, 0xff, 0xf9, 0x50, 0x40, 0xc, 0xbf, 0xfc, 0x1
PS: Got message Audio, dts=2454818568, seq=22285, base=2454812448 payload=107B, 0xff, 0xf9, 0x50, 0x40, 0xd, 0x7f, 0xfc, 0x1

Note: 这两有两个pack，每个pack只有一个Video帧（不算编码头），每个都有两个Audio包。 Note: 第一个pack，前三个Video(Seq=22204)，是编解码信息，一般在I帧前面都是编码头，SPS/PPS等信息。 Note: 第一个pack，后两个Video(Seq=22250/22252)实际上就是一个关键帧，第一个是00 00 01开头，第二个直接就是接续的视频数据；第一个超过64KB，所以分成了两个。 Note: 第一个pack，最后两个Audio消息，它们时间戳是不同的。 Note: 第二个pack，只有一个Video，没超过64KB，而且没有system header和PSM，所以一般不是关键帧（具体以NALU解析为准）。 Note: 第二个pack，后面两个是Audio消息，时间戳也不同。 Note: 两个pack的Video间隔，是2454812448-2454808848=3600，也就是40ms，也就是视频FPS=25。而Audio之间的间隔，是2454810198-2454808128=2070，也就是23ms。

Wireshark

Wireshark默认就能解析GB的SIP的包，5060端口认为是SIP的默认端口。而GB媒体则需要操作下，这小节总结下如何用Wireshark解析媒体包。

SRS使用TCP传输媒体，所以格式是RFC4571: RTP & RTCP over Connection-Oriented Transport，就是前两个字节是长度，后面是RTP包。

Note: Wireshark支持RFC4571，它的Dissecotr是rtp.rfc4571。

有两种方法，一种直接打开包后，输入过滤tcp.port==9000，然后右键包，选择Decode as > RTP，就可以看到解析成了RFC4517，如下图所示：

还有一种方法，直接加载SRS的research/wireshark/gb28181.lua插件，将TCP/9000数据解析为RFC4571格式，执行如下命令：

cd ~/git/srs/trunk/research/wireshark
mkdir -p ~/.local/lib/wireshark/plugins
ln -sf $(pwd)/gb28181.lua ~/.local/lib/wireshark/plugins/gb28181.lua

Note: Wireshark的插件目录，不同平台会不同，请百度下在哪里，直接把插件拷贝进去也可以。

解析成功后，直接过滤rtp包，可以看到GB的媒体数据，如下图所示：

Note: 注意RTP的Payload就是MPEG-PS，开头是00 00 01 BA的标识符，不过Wireshark不支持PS流解析。

工具准备好了，分析起来也会更方便。

Lazy Sweep

GB存在和Source清理一样的问题。在GB中，存在SIP连接协程，媒体连接协程，会话协程等多个协程，这些协程之间会互相引用对象，而它们的生命周期是不一致的。

比如：SIP连接，需要持有会话对象的指针，当设备连接到SRS时，需要更新会话协程的SIP连接对象，这样会话需要发送信令消息，就可以走最新的SIP连接发送。

比如：媒体连接，收到媒体PS pack时，需要通知会话协程处理，转成RTMP流。媒体连接断开时，需要通知会话协程，会话协程会发送BYE和重新INVITE，通知设备重新推流。

比如：会话对象，有自己的生命周期，简单设计就是和Source一样永远不清理，这样它生命周期就会比SIP和媒体协程活得更长，这样它们引用会话对象时就是安全的，但这样就会有内存不释放的问题。同样，SIP连接一定需要清理，所以会话对象就可能会持有野指针问题。

Source清理的问题，本质上是多个协程之间生命周期不同步，所以如果释放Source后可能有些协程活得比Source更久，就可能出现野指针引用。详细请查看#413的描述。

SRS 6.0引入了Smart Pointer，解决了Source清理的问题，具体参考SmartPtr for GB的修改。

Benchmark

GB缺乏工具链，基本上是空白的，而没有工具，就只能借助真实的摄像头测试，这基本上就是原始时代：

  • 摄像头只能覆盖基本的正常流程，以及一些能操作的异常流程，无法覆盖SRS设计的状态机，会导致某些状态下异常。
  • 摄像头的断开和重推流周期太慢，估计得15秒左右，而工具比如utest或benchmark，可以做到1秒就能重推，这样效率才能提高。
  • 摄像头无法实现utest和回归测试，这次测试完是好的，但未来不知道什么时候就改坏了，这样出现问题后排查的效率就非常低。

和WebRTC一样，SRS也会完善GB的工具链，参考srs-bench，我们会基于Go的各种库实现GB的自动测试，也可以用作模拟摄像头。使用到的库包括：

  • ghettovoice/gosip：SIP协议栈，这个库WebRTC段维伟也有贡献，模拟GB的SIP。
  • gomedia/mpeg2：打包PS流，包括Pack头、System头、PSM包、音视频PES包等。
  • pion/rtp：打包RTP头。由于GB的SDP不标准，所以没用pion的SDP解析，直接字符串查找SSRC即可。
  • pion/h264reader: 读取h264格式的视频文件，在压测工具中，使用FFmpeg将FLV转成h264格式的视频文件，方便测试时分开测试音视频。
  • go-oryx-lib/aac: 读取AAC格式的音频文件，在压测工具中，使用FFmpeg将FLV转成ogg/aac等音频文件格式，方便测试时分开测试音视频。

Go的库一致性比C++的高，当然风格也有差别，调试很方便，用作Benchmark工具是足够了。

使用方法，下载代码后编译，执行--help可以看到参数和实例，注意依赖Go编译环境请先安装Go：

git clone -b feature/rtc https://gitee.com/ossrs/srs-bench.git
cd srs-bench
make && ./objs/srs_bench -sfu gb28181 --help

模拟一个摄像头推流：

./objs/srs_bench -sfu gb28181 -pr tcp://127.0.0.1:5060 -user 3402000000 -random 10 \
  -server 34020000002000000001 -domain 3402000000 -sa avatar.aac \
  -sv avatar.h264 -fps 25

Note: SRS使用user字段作为设备标识，转成RTMP也作为流名称，压测工具支持随机10位数字的user，通过random指定，这样可以每次模拟不同的设备。如果希望模拟一台固定的设备，不指定random，而指定完整的user即可。

Note: 需要先启动本机SRS。压测工具自带了测试样本avatar.h264和avatar.aac，如果需要其他的测试样本，可以用FFmpeg生成。

同样，SRS的回归测试，也会执行GB的回归测试，每次提交都会检查是否GB正常，也可以手动执行回归测试：

cd srs-bench
go test ./gb28181 -mod=vendor -v

Note: 测试前需要先启动SRS服务器，参考前面压测的说明。

Go最厉害的是这些控制机制，覆盖得非常全面，比如：

  1. 启动三个协程，必须等三个协程结束后才能退出，并判断错误结果，决定测试是否成功。
  2. 推流和播放协程，必须等待主协程初始化完毕才能启动。
  3. 播放协程，必须等待推流建联后才能建联。
  4. 所有协程，都不能超过测试用例的超时时间，比如5秒。
  5. 若有协程异常，应该立刻结束，比如播放异常，推流就算正常也应该结束。
  6. 若所有正常，也应该在一定包数之后结束，比如收发100个包，这样尽快可以跑完测试，比如100ms，而不是每个必须5秒（会导致整体测试时间太长）。

这些全都是控制机制，Go用了select+chan、WaitGroup、Context三个基础组件就全部支持了，不得不佩服Go这个设计还是非常非常牛逼的。

Commits

和GB相关的修改：

Thanks

特别感谢夏立新等同学，两年前让SRS支持了GB功能，经过这两年的积累，我们形成了GB的开源社区，了解了GB的应用场景，以及主要的发展方向。

经过这两年对GB的理解，我们也终于有信心把GB合并到SRS 5.0，除了夏立新和陈海博，其中有非常多的同学的贡献，很抱歉无法一一表达。

在合并GB进SRS 5.0过程中，对于其中的难点和疑点，也有很多同学给与了帮助，包括王冰洋、陈海博、沈巍、周小军、夏立新、杜金房、姚文佳、潘林林等等同学。

©2013~2024 OSSRS 京ICP备19056366号-1