【问题标题】:How to solve a RAW stream playback problem with GStreamer and VAAPi如何使用 GStreamer 和 VAAPi 解决 RAW 流播放问题
【发布时间】:2020-02-19 10:03:19
【问题描述】:

我目前在使用 GStreamer 时遇到了一个小问题,这里有更多详细信息:

配置:

  • 英特尔 i7-6700
  • 英特尔高清显卡 530
  • Ubuntu 18.04 LTS
  • GStreamer1.0
  • VAAPI 插件

我从视频源收到UDP 流,该流以RAW UYVY 格式发送。这是我的命令行来解码它:

gst-launch-1.0 -v udpsrc port="1234" caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string)1080, colorimetry=(string)BT709-2, payload=(int)96, ssrc=(uint)1188110121, timestamp-offset=(uint)4137478200, seqnum-offset=(uint)7257, a-framerate=(string)25" ! rtpvrawdepay ! decodebin ! queue ! videoconvert ! xvimagesink

我们可以在下面的屏幕截图中看到问题,CPU 负载(右)对于此类任务来说太高了,我们可以看到GPU 负载(左)几乎为零。

为了克服这个问题,我想使用 VAAPI 图形加速,就像我在之前的项目中使用 H264 所做的那样,下面是命令行:

gst-launch-1.0 -v udpsrc port=1234 caps= "application/x-rtp, media\=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)640028, payload=(int)96, ssrc=(uint)2665415388, timestamp-offset=(uint)3571350145, seqnum-offset=(uint)18095, a-framerate=(string)25" ! rtph264depay ! queue ! vaapih264dec low-latency=1 ! autovideosink

上面的行完美运行,CPU 几乎没有更多负载。所以我调整了这个命令行来使用RAW流,这里是命令:

gst-launch-1.0 -v udpsrc port="1234" caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string)1080, colorimetry=(string)BT709-2, payload=(int)96, ssrc=(uint)1188110121, timestamp-offset=(uint)4137478200, seqnum-offset=(uint)7257, a-framerate=(string)25" ! rtpvrawdepay ! vaapidecodebin ! videoconvert ! xvimagesink

它与开头的那一行相同,但我将元素 decodebin 更改为 vaapidecodebin,因为我已将 avdec_h264 替换为 vaapih264dec 用于我的 H264 流。不幸的是它不起作用,我最终得到了这个错误:

WARNING: wrong pipeline: unable to connect rtpvrawdepay0 to vaapidecodebin0

我该如何解决这个问题?你有什么线索可以解决这个问题吗?

【问题讨论】:

    标签: linux ubuntu video gstreamer vaapi


    【解决方案1】:

    您究竟想在这里加速什么? CPU负载可能是由于videoconvert,因为它在软件中运行以将UYVY转换为渲染器支持的格式(希望这是另一种YUV格式而不是RGB),或者是来自CPU内存的未压缩数据的数据传输到 GPU 内存。

    请注意,传输未压缩的图像数据的数据速率高于压缩的 H.264 视频。

    如果您认为 videoconvert 是昂贵的部分,您可能想尝试使用 OpenGL 进行转换和显示:.. ! glupload ! glcolorconvert ! glimagesink

    如果你不想走OpenGL路线,也许vaapipostproc可以帮助你进行颜色转换。

    【讨论】:

    • 您好,感谢您的回复。我通过用 OpenGL 替换 videoconvert 来尝试命令行,这稍微改善了结果,但 CPU 的核心仍然加载在 40% 左右,而其他 3 个核心在 6-7% 左右。我希望所有内核的电荷大致相同,以便均匀。
    • 好吧,不用担心,这种情况下vaapidecodebin设置不起作用?
    • 您正在处理原始图像数据 - VAAPI 应该在这里“解码”什么?
    • 我找到了另一种使用 taskset 命令协调我的 CPU 的解决方案。现在我的三个核心几乎都加载到了相同的级别。
    猜你喜欢
    • 2016-08-01
    • 1970-01-01
    • 2013-08-04
    • 1970-01-01
    • 2018-12-15
    • 1970-01-01
    • 2014-10-26
    • 1970-01-01
    • 2011-04-19
    相关资源
    最近更新 更多