Consultation on the problem of screen blur after using the -o parameter.

[liutianye]

作者估计看不到，其他小伙伴们谁正好用到这个，咨询大家一下，我现在不用-o参数起来，12代i5 16G内存的机器直接三路画面就卡死机了，只开一路画面41%的CPU占用但是画面不会有花屏问题。一旦用-o参数起来，cpu使用不高，但是一动，画面就局部马赛克，如果码率调高画面优惠出现卡顿，这个情况我该怎么解决呢？是维持高帧率高码率换个工业级的路由器吗？

[mengxuezhixing]

我最近也在纠结这个问题，我是加了-o参数，分别尝试了修改SDP、传入options: rtptransport=tcp&timeout=60、修改摄像头码率、延时，只有第三种有些作用，但是效果依旧不太理想，还是有卡顿花屏

[liutianye]

我最近也在纠结这个问题，我是加了-o参数，分别尝试了修改SDP、传入options: rtptransport=tcp&timeout=60、修改摄像头码率、延时，只有第三种有些作用，但是效果依旧不太理想，还是有卡顿花屏

兄弟，我已经动手了，换了个工业级路由器+交换机+无线AP的网络配置套装，还是三个海康的无线IPC，现在码率可以调到8000到1W了，局部画面变化几乎不会在有马赛克情况，但是还是会有每隔几秒会丢帧的情况。查了一下文献资料之类说了udp就是保证低延迟但是会丢包，options改了rtp没效果，改了tcp后卡顿更明显了。

[mengxuezhixing]

可惜我公司同事不接受更换硬件，因为海康旷世摄像头给的页面是播放正常的，天天拿这个来比较目前的方案。 另外我看了下，海康摄像头是用的IE控件，旷世摄像头用的自己封装的webComponent.exe，将转出来二进制数据转换成canvas图片去渲染，如果有后续需要可以从这方面考虑

[liutianye]

可惜我公司同事不接受更换硬件，因为海康旷世摄像头给的页面是播放正常的，天天拿这个来比较目前的方案。 另外我看了下，海康摄像头是用的IE控件，旷世摄像头用的自己封装的webComponent.exe，将转出来二进制数据转换成canvas图片去渲染，如果有后续需要可以从这方面考虑

一样，我们领导也是直接问，为什么海康自己的摄像头地址打开预览不卡，我们还是用onvif接的摄像头，不只要显示海康，符合要求的大华，乐橙什么的都要集成进来，这个马赛克海康预览里也会有，但是码率高了之后人家的就没问题，webrtc-streamer出来的画面就会卡...都快疯了。

[mengxuezhixing]

可惜我公司同事不接受更换硬件，因为海康旺世摄影头给的页面是播放正常的，天天拿这个来比目前的方案，我把案外了。像头是用的IE控件，像头是用的自己封装的webComponent.exe，将转出来二次制作数据转成canvas图片去流染，如果有后续需要可以从这方面考虑

一样，我们领导也是直接问，为什么海康自己的摄像头地址打不开预览不卡，我们还是用onvif接口的摄像头，不要只显示晏晏的大康，乐橙什么的都要集合进来，这个马赛克海康预览里也会有，但是代码率高了之后人们家的就没有问题了，webrtc-streamer出来的画面就会卡...都快疯了。

海康、旷世这种专门做这种摄像头的，投入的资源不一样，有差异是正常的，优化也要时间。 一些公司会去搞自研定制化，比如旷世。 实在不行只能换一下方案，比如尝试下ffmepg转canvas显示，每一帧都去转成图片，但是这种方案也要时间去打通，不如当前这种webRtc-streamer即插即用

[liutianye]

mengxuezhixing

最初采用的是海康的SDK，后来改通用模式换了ffmpeg来推，那个延迟实在是接受不了，换了很多种方案，只有这个延迟最低。

[liusuyi2021]

检查你的带宽，试试局域网直连，我csdn名：吭吃瘪肚的万能工

[liutianye]

大佬，你没有印象了吗？你csdn里有个评论说丢包那个，就是我...

[mpromonet]

對不起，我的中文很有限

[Dnchua]

hello，i have a question，when i use rtsp over tcp，7mbps video，1920x1080，use -o param，one watch，the machine cpu cost 110%，when use rtsp over udp，it just cost 15%，Should the consumption of a system using TCP be so high？machine config xeon 4116，use docker mode

[Dnchua]

I also encountered this problem. When the single-channel code stream is greater than 6Mbps, in tcp mode, adding -o to pull three channels will cause 200+ CPU usage. If you use udp, it will be alleviated a lot, and it will be easy to pull for a long time. The hit limit of live555 appeared, but I also encountered another problem during use. Using udp method will generate 65S. In this way, the streamer will be disconnected from the video source, and the link with the player on the front-end page will still be maintained, but there is no The content has been pushed over