从ffmpeg通过Janus流式传输的H264 WebRTC视频在播放时非常不稳定 [英] H264 WebRTC video streamed from ffmpeg through Janus is very choppy on playback
问题描述
尝试通过以下链流传输视频:本地实例存储(AWS)上的h264/mp4文件-> ffmpeg-> rtp->同一实例上的Janus-> WebRTC播放(Chrome/mac).即使没有资源似乎过载(所涉及的任何系统上的CPU/内存/网络带宽)，所产生的视频也不稳定.我还使用了Coturn TURN服务器，它也没有完全加载并且带宽充足.
Trying to stream video through following chain: h264/mp4 file on local instance storage (AWS)->ffmpeg->rtp->Janus on same instance->WebRTC playback (Chrome/mac). Resulting video is choppy even as none of the resources seem overloaded (CPU/memory/network bandwidth on any of the systems involved). I also use a Coturn TURN server, it is also not loaded at all and bandwidth is plentiful.
尝试了切换编解码器，除了vp8不能工作之外，vp8仍在工作(有点-断断续续，但非常罕见且可以接受)，导致如此高的CPU消耗，实际上这是不可接受的.
Tried switching codecs and it didn't help apart from vp8 which while worked (kind of - choppiness was still there but very rare and acceptable), resulted in such a high CPU consumption that practically it's unacceptable.
ffmpeg -re -stream_loop -1 -i ./short.mp4 -s 426x240 -c:v libx264 -profile:v baseline -b:v 1M -r 24 -g 60 -an -f rtp rtp://127.0.0.1:5004
产生的SDP是:
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 127.0.0.1
t=0 0
a=tool:libavformat 58.20.100
m=video 5004 RTP/AVP 96
b=AS:1000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1
使用Janus API将流设置为
stream is set up with Janus API as
"janus" : "message",
"transaction" : 'Transaction',
"body": {
"request" : "create",
"type" : "rtp",
"id" : newId,
"name": streamId+newId,
"audio": false,
"video": true,
"description" : streamId+newId,
"videoport" : 5000+newId*4,
"videopt" : 96,
"videortpmap": "H264/90000",
"secret" : "adminpwd"
}
}
尝试了bw的各种选项，完全没有帮助.将-g(GOP大小)更改为较低的值可以使断续时间更短，但更频繁.在-g 3或4时可以接受，但是可以预见的可忍受质量的比特率变得疯狂.
Tried various options of bw, doesn't help at all. Changing -g (GOP size) to lower values can make choppiness shorter in duration but more frequent. At -g 3 or 4 it is acceptable but the bitrate for tolerable quality, predictably, becomes insane.
预期结果:视频播放时没有断断续续.
Expected result: video plays without choppiness.
我的理论是它可能是以下之一:
My theory of it is it could be one of the following:
-
这两种ffmpeg都以缓冲区太小的方式提供数据，因此有时Janus需要在尚未准备就绪时发送下一个数据包，使缓冲区饿死并导致中断-因此也许有一种方法可以使ffmpeg编码为某种短的(半秒左右的缓冲来调节流量).怎么样?
Either ffmpeg provides data in a way buffer is too small so sometimes Janus needs to send a next packet while it's not ready yet, starving buffer and resulting in interruption - so maybe there is a way to make ffmpeg encode into some kind of a short (half-second or so? buffer to regulate flow). How?
或者H264在UDP上无法正常工作，我无能为力.然后我必须切换到TCP，但到目前为止，尝试执行此操作均未成功.
Or H264 works too poorly over UDP as it is and there is nothing i could do. Then i got to switch to TCP, but so far attempts to do this has been unsuccessful.
推荐答案
事实证明该解决方案很漂亮. ffmpeg将流作为RTP发送给Janus，Janus将其进一步发送给查看者，显然是SRTP，因为它是WebRTC，并且始终是加密的.这给每个数据包增加了一堆字节作为加密开销.在某些情况下，这意味着数据包经过MTU并被丢弃-每次发生时，视频中都会出现明显的跳动.
The solution proved to be beautiful in it's obviousness. ffmpeg sent stream to Janus as RTP, Janus sent it further to viewers, obviously, as SRTP, because this is WebRTC and it is always encrypted. Which added a bunch of bytes to each packet as encryption overhead. In some cases, it meant packets going over the MTU and discarded - each time it happened, there was a visible jerk in video.
简单地添加?pkt_size = 1300以输出ffmpeg的RTP URL即可解决此问题.
Simple addition of ?pkt_size=1300 to output RTP URL of ffmpeg removed the problem.
感谢Meetecho的Lorenzo Miniero弄清楚了这一点.
Thanks to Lorenzo Miniero of Meetecho for figuring this out.
这篇关于从ffmpeg通过Janus流式传输的H264 WebRTC视频在播放时非常不稳定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
