Gstreamer pipeline的CPU使用率和内存
我使用 gstreamer 从网络摄像头捕获视频，使用 x264 对其进行编码，并使用 gstrtpbin 对其进行流式传输。效果很好。然而，它使用了我所有四个核心的大约 50% 以及大量内存。有什么办法可以降低 CPU 和内存使用率吗？这是管道。
pipeline_description = "gstrtpbin latency=0 max-latency=100 drop-on-latency=true use-pipeline-clock=true ntp-sync=true name=rtpbin " \
"autovideosrc ! video/x-raw-yuv,width=640,height=480,framerate=30/1 ! " \
"tee name=t_vid ! queue ! fpsdisplaysink name=fpssink text-overlay=false video-sink=xvimagesink signal-fps-measurements=true t_vid. ! " \
"queue ! videorate ! ffmpegcolorspace ! x264enc pass=qual tune=zerolatency quantizer=40 ! queue ! rtph264pay ! rtpbin.send_rtp_sink_0 " \
"rtpbin.send_rtp_src_0 ! udpsink port=%d host=%s sync=false async=false rtpbin.send_rtcp_src_0 ! " \
"udpsink port=%d host=%s sync=false async=false name=vrtcpsink udpsrc port=%d ! " \
"rtpbin.recv_rtcp_sink_0 autoaudiosrc ! queue ! audioresample ! audioconvert ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_1 " \
"rtpbin.send_rtp_src_1 ! udpsink port=%d host=%s sync=false async=false rtpbin.send_rtcp_src_1 ! " \
"udpsink port=%d host=%s sync=false async=false udpsrc port=%d ! rtpbin.recv_rtcp_sink_1" % (VRTP_SEND_PORT, DEST,
VRTCP_SEND_PORT, DEST, VRTCP_RECV_PORT, ARTP_SEND_PORT, DEST, ARTCP_SEND_PORT, DEST, ARTCP_RECV_PORT)
I'm using gstreamer to capture video from a webcam, encode it with x264 and stream it using a gstrtpbin. It works great. However, it uses about 50% of all four of my cores and a lot of memory. Is there anything I can do to lower the CPU and memory usage? Here's the pipeline.
pipeline_description = "gstrtpbin latency=0 max-latency=100 drop-on-latency=true use-pipeline-clock=true ntp-sync=true name=rtpbin " \
"autovideosrc ! video/x-raw-yuv,width=640,height=480,framerate=30/1 ! " \
"tee name=t_vid ! queue ! fpsdisplaysink name=fpssink text-overlay=false video-sink=xvimagesink signal-fps-measurements=true t_vid. ! " \
"queue ! videorate ! ffmpegcolorspace ! x264enc pass=qual tune=zerolatency quantizer=40 ! queue ! rtph264pay ! rtpbin.send_rtp_sink_0 " \
"rtpbin.send_rtp_src_0 ! udpsink port=%d host=%s sync=false async=false rtpbin.send_rtcp_src_0 ! " \
"udpsink port=%d host=%s sync=false async=false name=vrtcpsink udpsrc port=%d ! " \
"rtpbin.recv_rtcp_sink_0 autoaudiosrc ! queue ! audioresample ! audioconvert ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_1 " \
"rtpbin.send_rtp_src_1 ! udpsink port=%d host=%s sync=false async=false rtpbin.send_rtcp_src_1 ! " \
"udpsink port=%d host=%s sync=false async=false udpsrc port=%d ! rtpbin.recv_rtcp_sink_1" % (VRTP_SEND_PORT, DEST,
VRTCP_SEND_PORT, DEST, VRTCP_RECV_PORT, ARTP_SEND_PORT, DEST, ARTCP_SEND_PORT, DEST, ARTCP_RECV_PORT)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我也见过这个问题 - 使用sync=false 似乎会触发 100% CPU。还有另一个线程 Streaming RTP/RTSP:sync/timestamp issues 讨论这。华泰
I've seen this issue as well - using sync=false seems to trigger 100% CPU. There is another thread Streaming RTP/RTSP: sync/timestamp problems that talks about this. HTH
我会运行 oprofile/sysprof 来查看哪个代码最有问题。您也许可以通过使用更少的抽象接收器和源来节省一些（例如，直接使用 xvimagesink 而不是 fpsdisplaysink）。如果可以的话，避免使用 ffmpegcolorspace （原则上颜色空间转换，如果不需要，该元素不会执行任何操作，只会造成很少的开销）。
I would run oprofile/sysprof to see which code the biggest offender is. You might be able to save a little by using less of the abstract sinks and sources (e.g. use xvimagesink directly instead of fpsdisplaysink). If you can, avoid ffmpegcolorspace (colorspace conversion in principle, the element won't do anything if not needed and only cause little overhead).
如果您不需要帧速率计算等，因此它是叠加的，您可以通过这种方式减少一些 CPU 消耗，但正如 joeforker 所指出的，h264 的计算量相当大，因此尽管管道中进行了所有优化，我怀疑你会看到超过 10-15% 的改进，除非其中一个元素有问题。这就是 ensonic 对分析的评论非常有用的地方，特别是如果您愿意重写某些元素，即用您自己的元素替换附带的元素。
If you don't need the frame-rate computation and more so it's overlay, you could shave off some CPU consumption that way, but as pointed out by joeforker, h264 is computationally quite intensive, so inspite of all the optimization in your pipeline, I doubt you'd see an improvement of more than 10-15%, unless one of the elements is buggy. Which is where ensonic's comment on profiling would be quite useful, especially if you are open to rewriting some of the elements i.e. replacing the ones shipped, with your own.