错误:仅发送-1个字节
已查看 86 次
蜥蜴人
2021年3月13日上午6:33:55
收件人 meetecho-janus
你好,
我遇到一个问题,其中将流插件与RTP GStreamer管道一起使用会导致出现严重的卡顿现象。输出显示许多错误,这些错误沿以下方向读取内容:
[ice.c:janus_ice_outgoing_traffic_handle:4494] [1174500298337307] ...仅发送了-1个字节?(原为1328年)。
我已经使用VLC进行了验证,RTP流本身可以完美地工作而不会结结巴巴。有没有人有任何潜在的解决方案。我认为它必须与数据包或MTU有关。我可以在Janus配置或Linux本身中调整任何设置以最大化性能吗?
谢谢,
彼德
蜥蜴人
2021年3月13日上午6:59:54
收件人 meetecho-janus
有趣的是,这是入站和出站统计数据的样子。
屏幕快照2021-03-12 at 5.59.26 PM.png
蜥蜴人
2021年3月14日上午4:38:56
收件人 meetecho-janus
我还应该添加我的GStreamer脚本本身。
gst-launch-1.0 -v file:///opt/janus3/share/janus/streams/beat.mp4!qtdemux!队列 !h264parse!rtph264pay mtu = 1300 config-interval = 1 pt = 96!udpsink主机= 192.168.1.229端口= 8004
亚历山德罗·托普(Alessandro Top)
2021年3月14日下午6:51:29
收件人 meetecho-janus
janus收到很多麻烦,所以我想您应该尝试了解为什么客户端没有收到那么多数据包。
蜥蜴人
2021年3月15日上午2:47:36
收件人 meetecho-janus
谢谢。我感到困惑的一件事是它是否是摄入问题。为什么会出现错误“:janus_ice_outgoing_traffic_handle”?这只是说Janus没有发送任何数据包吗?另外,此过程是在同一台PC上进行的,因此我不确定为什么不会接收到任何数据包。我已经使用VLC作为RTP流的播放器测试了此确切的管道,并且运行良好。
蜥蜴人
2021年3月15日下午1:57:17
收件人 meetecho-janus
感谢Lorenzo对另一个用户对类似问题的评论,我设法找到了影响该问题的内容。在Linux中更改这些值可能会影响我在控制台中看到的错误数量。像10000这样的低点,错误数量大大增加。我已将其默认值增加到500000,将最大值增加到1000000,这似乎已经解决了大多数问题。您是否知道我应该将其设置为在Janus中获得最佳性能?为什么Janus在需要时不使用最大值?我尝试仅增加最大值,但是并不能解决问题。默认值是需要更改的值。但是,我不知道更改此值是否会对系统产生其他有害影响。
我的默认值是所有四个的默认值262144
#sysctl -w net.core.rmem_default = 500000
#sysctl -w net.core.wmem_default = 500000
#sysctl -w net.core.rmem_max = 1000000
#sysctl -w net.core.wmem_max = 1000000
这是在1080p 60 FPS时具有50000 kbps H264视频的情况。我将必须运行其他测试,并报告是否可以解决我之前遇到的其他高比特率问题。
洛伦佐·米尼罗(Lorenzo Miniero)
2021年3月15日下午6:01:27
收件人 meetecho-janus
你们请不要再说它适用于VLC吗?WebRTC和VLC的工作方式不同,并且功能不相同!
L.
亚历山德罗·托普(Alessandro Top)
2021年3月15日下午8:19:08
收件人 meetecho-janus
50000 kbps是50 mbps的视频流!
我希望像您一样对套接字缓冲区进行调整,以达到良好的性能。
还要记住,Janus并未针对如此高的比特率流进行过测试。
蜥蜴人
2021年3月16日上午2:45:57
收件人 meetecho-janus
是的,说它可以与VLC一起使用几乎是毫无意义的。我只是说这是为了表明我认为问题不在于RTP流本身,因为它具有平滑播放的能力,但最后还是有缺陷,因为正如您所说,VLC可以在做事在幕后制作自己的缓冲之类的东西。
我花了相当长的时间才知道需要调整套接字缓冲区。既然你们俩显然都知道很多,那么对于在Janus中绝对最佳的性能(尤其是在高比特率/带宽方面)应该进行调整的任何事情,你们中的任何一个是否有其他建议?我已经在sendmmsg分支上。