0


webrtc sfu性能压测

1. 前言

    不少网友最近私信我,咨询webrtc sfu服务端性能问题,SRS开源服务能支持多少路webrtc流,mediasoup单房间能支持多少个人,推流能接入多少路,拉流能拉取多少路?720p能支持多少路,360p能支持多少路?

   这里介绍一下如何测试webrtc sfu服务器的性能,介绍原理和实际操作。最后以srs和mediasoup两个流行的webrtc sfu开源进行举例,如何压测其性能。

    阅读后,相信你今后能够自己针对自己的视频质量来进行对应的压测。

2. whip和whep的出现

   webrtc虽然有一套标准协议族:信令sdp交互/stun/dtls/rtp/rtcp等,但是每个开源的sfu都有自己定义的信令交互方式。也就是信令的交互方式都是开源sfu自定义的,比如
  • SRS(国内最流行的流媒体服务器之一)https post方式进行sdp交换

  • MediaSoupwebsocket传输信令,信令把sdp进行拆分: 1)stun/dtls信息;2)音频/视频的rtp/rtcp信息;

    这个时候whip协议的规范出来,就提供了一个webrtc信令交互的标准。rfc已经有了draft文档:
    

https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html。

   whip全称: WebRTC-HTTP ingestion protocol,也就是webrtc推流协议,有了这个协议,基本上就有了webrtc的推流标准,很多sfu的开源都支持该协议,客户端OBS推流也支持该协议(可以用webrtc进行推流,来进行直播)

   whep全称: WebRTC-HTTP Egress Protocol,就是webrtc拉流协议,下行拉流协议。rfc的draf文档地址: 

https://www.ietf.org/archive/id/draft-murillo-whep-03.txt。

   本文主要就是基于whip/whep进行webrtc sfu压测。

3. 基于cpp_streamer工具进行压测

   cpp streamer是基于C++11开发的音视频组件,使用者可以把组件串联起来实现自己的流媒体功能。支持多种媒体格式,流媒体直播/rtc协议。

   网络开发部分,采用高性能,跨平台的libuv网络异步库。

  支持webrtc的推流/拉流,并且代码并未使用libwebrtc(chrome内部webrtc源码,依赖较多,库比较大),而是笔者基于webrtc协议族规范(stun/dtls/rtp/rtcp等)开发的webrtc组件,代码非常的轻量。

   下面介绍,如何使用cpp_streamer进行压测。

4. SRS的webrtc性能压测

   笔者推荐使用开源cpp_streamer进行webrtc压测,下面介绍两个方向的压测:
  • 推流压测(whip)
  • 拉流压测(whep)

4.1 推流压测

4.1.1 媒体源文件

压测的源文件采用mpegts格式,因为其能支持对opus音频编码的封装,具体的要求:

  • 视频编码H264, profile必须是baseline;
  • 音频编码Opus,采样率48000,通道2

推荐使用ffmpeg生成媒体源文件:

ffmpeg -i src.mp4 -c:v libx264 -r 25 -g 100 -profile baseline -c:a libopus -ar 48000 -ac 2 -ab 32k -f mpegts webrtc.ts

用户可以自己编码制作自己想要测试的视频分辨率,I帧间隔和帧率;

4.1.2 压测

在linux服务器上编译后,会生成whip_srs_bench执行文件,执行:

./whip_srs_bench -i webrtc.ts \-o "http://10.0.24.12:1985/rtc/v1/whip/?app=live&stream=1000" \-n 100

注意:

  • -i的参数为测试源文件,mpegts格式,视频H264 baseline profile,音频opus且采样率48000,通道数为2;
  • -o的参数为srs的webrtc地址,地址要加引号,如10.0.24.12是srs的地址,1985是srs的信令http端口号
  • -n为并发whip session个数,也就是推流的个数,推荐小于100,如果需要测试多于100的个数,推荐开启多个whip_srs_bench命令行,以确保准确度

4.2 拉流压测

在linux服务器上编译后,会生成whep_srs_bench执行文件,执行:​​​​​​​

./whep_srs_bench \ -i "http://10.0.8.5:1985/rtc/v1/whip-play/?app=live&stream=1000" \ -n 100
  • -i的参数为srs的webrtc的whep拉流地址,地址要加引号,如10.0.8.5是srs的地址,1985是srs的信令http端口号
  • -n为并发whep session个数,也就是拉流的个数,推荐小于100,如果需要测试多余100的个数,推荐开启多个whep_srs_bench命令行,以确保准确度

5. Mediasoup性能压测

5.1 推流压测

   压测源文件如何生成,见4.1.1。注意:当前也仅仅支持H264+Opus的编码格式。

在linux服务器上编译后,会生成mediasoup_push_bench执行文件,执行:​​​​​​​

./mediasoup_push_bench -i webrtc.ts \ -o "https://xxxxx.com:4443?roomId=200&userId=1000" \ -n 100
  • -i的参数,webrtc.ts为源文件:mpegts格式,视频h264 baseline;音频opus 采样率48000,通道数为2;

  • -o的参数,mediasoup的broadcaster接入模式,xxxx.com:4443为sfu的域名地址,roomId为房间号,userId为用户名。

  • -n的参数为整数,测试并发的数量,推荐小于100,如果需要测试大于100的,开启多个命令行,以保证拉流的准确度;

     mediasoup sfu的demo中,推流有个“坑”,注意:
    
     推流所在的roomId必须提前存在(也就是websocket端已经有人推流上来),否则broadcaster创建失败。如果需要房间Id不存在的前提下命令行推流能成功,需要修改mediasoup-demo的源码server.js,如下:​​​​​​​
    
expressApp.param(  'roomId', (req, res, next, roomId) =>  {    queue.push(async () =>      {        consumerReplicas = 0;        req.room = await getOrCreateRoom({ roomId, consumerReplicas });        next();      }).catch((error) =>        {          logger.error('room creation or room joining failed:%o', error);          reject(error);        });  });
   原有代码:在http api检测roomId的房间是否存在,若不存在,拒绝创建broadcaster;

  新代码: 在http api检测roomId的房间是否存在,若不存在,创建该roomId的新房间;

5.2 拉流压测

在linux服务器上编译后,会生成mediasoup_pull_bench执行文件,执行:​​​​​​​

./mediasoup_pull_bench \ -i "https://xxxxx.com.cn:4443?roomId=100&apid=7689e48c-09ae-48ca-8973-ad5de69de5e8&vpid=aadbbb0b-2e4e-4ed8-8bd6-22e3c50b9fc1" \ -n 100 \ -l 1.log
  • -i的参数,mediasoup的broadcaster接入模式,xxxx.com:4443为sfu的域名地址,roomId为房间号,apid为推流audio的producerId, vpid为推流video的producerId;
  • -n的参数为整数,测试并发的数量,推荐小于100,如果需要测试大于100的,开启多个命令行,以保证拉流的准确度;
  • -l的参数为日志文件(可选,如果不填写,输出到控制台)
标签: webrtc srs mediasoup

本文转载自: https://blog.csdn.net/sweibd/article/details/140242590
版权归原作者 runner365.git 所有, 如有侵权,请联系我们删除。

“webrtc sfu性能压测”的评论:

还没有评论