为什么我的pygst (python )代码呈现的不可靠？

Question

TLDR:我正在使用PyQt并将pygst呈现嵌入到窗口中。当我把我所有的系统移到Ubuntu16.04(从14个我想？)Qt应用程序中的pygst呈现不再可靠。根据系统的不同，我得到了一个空白窗口，或者看起来像是未初始化的内存缓冲区呈现。

例如，代码在我的very X1 (使用nvidia驱动程序)上呈现测试源时更频繁，但是只有当我使用nouveau视频驱动程序时，代码才能在我的T61P上工作，而且不太可靠。T61P从不与nvidia驱动程序一起工作。

我的最初的测试代码为pygst 0.1。我尝试移植到pygst 1.0，但这似乎没有什么区别。这个帖子建议增加队列。我试着加了一些，但没有得到任何明显的区别。但是这个帖子也没有给出非常具体的(或自信的)建议，所以我不认为我不知道该把它们添加到哪里。

链接示例中提到的一个有趣的实验是延迟player.set_state(播放)或交换QMainWindow.show()与player.set_state(PLAYING)的顺序会影响可靠性。

编辑:我想我已经解决了！或者说，至少事情和以前一样好。观察:在我的一个系统上，当ssh -X‘’ing到beagle (BBB)并运行LinuxCNC图形用户界面(使用OpenGL呈现ssh之后)，问题会严重得多。回忆起来，记得T61 BBB i是在hadlibgl1-Mesa-swx 11(软件OpenGL呈现)上进行测试，试图解决Ubuntu16.04 nvidia驱动程序的渲染问题。然而，BBB软件OpenGL似乎在T61上搞砸了gstreamer，直到T61重新启动。在这一点上，我没有一个明确的解决办法，但我确实有一个坚实的理解，是什么导致了回归。T61现在似乎对Ubuntu16.04和Ubuntu12.04都有作用。我将尝试接受下面的答案，因为虽然它没有解决这个问题，但它确实提供了一些有用的信息。谢谢!

Answer 1

我相信这个“不可靠”的错误--将覆盖视频绘制到一个隐藏的窗口，充其量是不起作用的，而且在最坏的情况下，可能会导致水槽中的错误，从而使管道停止工作。当它确实起作用时，是因为比赛条件对你有利。

您根本不需要同步消息处理程序；只需在启动管道之前显示()窗口并在接收器上设置窗口句柄即可。

对于一个平台上的故障，尝试使用0作为窗口句柄(因此接收器创建自己的)来分割问题。如果它不工作，那么覆盖视频很可能不会与那个驱动程序一起工作。试试qwidgetvideosink。