为什么gStreamer从waylandsink抛出错误？

Question

我正在研究Smart Birdfeeder项目（https://github.com/google-coral/project-birdfeeder）当在开发板上使用Coral摄像机运行birdfeeder.sh时，我得到：

**（python3：3933）：严重**：16：37：50.961：无法刷新Wayland连接

错误在“终端”窗口中向上传播，使输出不堪重负，直到I ^ Z退出程序。对于给定的运行，“ python3：”后的数字是恒定的，但在不同的运行中将有所不同。如果将视频监视器插入板上的HDMI插座并运行程序，则监视器中将显示来自摄像机的实时图像；如果将鸟的照片放在摄像机前面，则该程序将起作用，并且保存来自摄像机的图像，并将正确的鸟类识别信息写入日志文件。这是管道代码：

def run_pipeline(user_function,
                     src_size=(640,480),
                     appsink_size=(320, 180)):
        PIPELINE = 'v4l2src device=/dev/video0 ! {src_caps} ! {leaky_q}  ! tee name=t'
        if detectCoralDevBoard():

        # Test framerate of 1/1 on 200212 (line 69), then 10/1 back to 30/1

            SRC_CAPS = 'video/x-raw,format=YUY2,width={width},height={height},framerate=30/1'
            PIPELINE += """
                t. ! {leaky_q} ! glupload ! glfilterbin filter=glcolorscale
                   ! {dl_caps} ! videoconvert ! {sink_caps} ! {sink_element}
                t. ! {leaky_q} ! glupload ! glfilterbin filter=glcolorscale
                   ! rsvgoverlay name=overlay ! waylandsink
            """

我对gstreamer经验不足，可以使用任何帮助。谢谢。

Answer 1

很好的问题，但我对程序不熟悉，并且珊瑚板上没有显示器。但是，这里有一些想法供您开始调查。我只是进入gstreamer（GST），我认为它非常酷！

1. PIPELINE字符串被送入GST解析器以构建处理数据流。管道的每个步骤都由bang（！）分隔，并且可以是插件或内部功能。该示例中的管道相当复杂，我怀疑其中一些步骤是不必要的。似乎只有一个来源-珊瑚板相机和两个水槽。每个对t.的引用都是一个新的处理线程：一个进入{sink_element}（这是在python脚本中某个位置定义的字符串），另一个进入waylandsink。源和接收器之间的元素将管道中先前元素的接收器作为源，并进行某种转换。例如，videoconvert插件经常用于神奇地将源视频信号转换为接收器可以使用的信号。 glupload是一个opengl插件，可将视频转换为opengl阴影（不清楚是否必要。）我无法识别其他一些插件。

2. 我的猜测是waylandsink插件引发了您的错误。您可以在waylandsink查看文档。您可能需要查看C源代码，以了解为什么它会产生CRITICAL错误，但是如果视频是在本地监视器上显示的，则不应为CRITICAL。]]]

3. python3:NNN字符串中的NNN号是python线程的进程ID。对您来说可能没有意义，但是GST是多线程的，因此对调试很有帮助。

祝你好运！