[参考译文] Linux/AM5728：GStreamer Ducati 插件在 X11上失败

软件团队已收到通知。 他们将在这里作出回应。

它对我们的用例没有帮助。
我们考虑将我们的应用移植到 Sitara。 这些工具主要使用 gtk 和 X11，并且只需进行最小的更改。 这些应用使用组件在屏幕的特定区域播放视频。 其中一个应用是显示4个 IP 摄像机输出的 CCTV 系统，另一个应用是播放广告。

我们希望在 X 运行时使用多个 gstreamer 流水线。 此外、我们还希望使用能够有效显示在部分屏幕上的接收器(理想情况下为一线性链接)来显示它们。 通过 ximagesink、我们达到了 CPU 瓶颈(部分原因是视频转换)。

这是可行的还是死端？

使用 X11时使用 gstreamer 流水线没有问题。 您运行的问题是，您在运行 X11时使用 kmsink 显示。 DRM (显示子系统驱动程序框架)资源应由单个主器件拥有。 当您将 X11与 kmssink 一起运行时，这两个文件都尝试拥有 DSS DRM 资源，因此应用程序会发生冲突并失败。 您需要使用特殊插件 ，该插件不会尝试打开 DRM 资源，而是与 X11 Windows 管理器共享。 例如、在 Processor SDK 版本中、我们支持 Wayland Manager。 要使用 Wayland Manager 运行 gstreamer 流水线、您需要使用 landsink、但不能将 kmsink 与之一起使用。  

google 位表示 X 视频接收器的 gstreamer 插件是 ligesink。 我们不会将其打包到文件系统中。 您可以尝试使用 Arago 构建它并使用它、看看它是否有用。  

这里是使用 Arago 构建 SDK 的链接。 检查 gstreamer 插件编译的方法、看看是否可以将 ximagesink 添加到列表中并编译它。  

这不是问题。 问题是在 X 正在运行时无法使用 libdce、不涉及接收器。
即使是对编解码器版本的简单查询也失败、因为 GST-Inspect 1.0 ducatih264dec 在 libdce 初始化时失败。
kmssink 仅用于验证是否正确编译了插件、以便在没有 X Work 的情况下测试等效命令。
然后、对于 libdce 的 drmopen hack、使用 Ducati 的 gstreamer 管道似乎可以正常工作。 它使用了血氧饱和度、并且速度很慢、因为它还需要对 VPE 输出进行视频转换。

好的、我忽略了 Ducati 插件。 当视频缓冲器从称为平铺器的专用存储器中分配时、IVA-HD 编解码器能够以最佳方式工作。 平铺存储器由 OMAP DRM 驱动程序管理、因此 libdec2在找到 OmapDrm_FD 值为-1时尝试打开"omapdrm"驱动程序。 libdce 中有一个名为 DCE_SET_FD()的 API，通过该 API，它可以从拥有 DRM 资源的其他用户层组件接收 omapdrm 句柄(在您的情况下为 X11)。

请参阅 viddec3test 源文件，其中应用程序拥有 DRM 资源，然后使用 DCE_SET_FD() API 将 omapdrm FD 传递到 libdce。

git.ti.com/.../viddec3test.c

在您的情况下，X11管理器实现可能拥有 DRM 资源，您可能需要在该后端组件中调用 DCE_SET_FD。

无法编译该示例。 我无法测试此解决方案是否有效或问题是否仍然存在。

由于系统中没有 libdriv2、只有 xcb-driv2、本地编译失败。  

在 Arago 中、omapdrmtest 仅针对航迹进行编译。 对于 X、由于依赖 关系、使用了 ti-xsgx-ddk-um 而不是 ti-SGX-DDK-um、因此失败。 当我试图改变它时... bitbake omapdrmtest 结束时出现以下错误：

错误：不提供'virtual/libgl'(但/home/devel/ti/tisdk/sources/oe-core/meta/recipes-graphics/mesa/libglu_9.0.0.bb、/home/devel/ti/tisdk/sources/oe-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb 依赖于或以其他方式需要它)
错误：Mesa 提供了虚拟/libgl、但跳过了：preferred_provider_virtual/libgl 设置为 mesa-gl、而不是 mesa
错误：Mesa-gl 提供虚拟/libgl、但跳过：preferred_provider_virtual/mesa 设置为 mesa、而不是 mesa-gl
错误：Mesa 提供了虚拟/libgl、但跳过了：preferred_provider_virtual/libgl 设置为 mesa-gl、而不是 mesa

Ping、自上次答复开始已过了一周。 是否有任何可以编译的示例？

处理器 SDK 仅支持 Wayland 管理器、因此请勿期望开箱即用示例将为 X11编译或运行。 提供了对 videc3test.c 源代码的引用、以研究应用程序如何将 DRM 器件 FD 传递到 libdce 层的代码。

为了更好地理解您的问题、可能让我返回一步并询问更多信息。 DRM 器件可以多次打开。 DRM 器件上的限制仅限于 DRM 内核模式设置(KMS)、而不是缓冲区管理。 只能有一个主器件用于执行 KMS、但缓冲器管理可由多个主器件完成。 在涉及 X 的应用程序中，从内部 drmopen 本身发出的调用似乎失败了。

在 hack 中，必须放置"do {} while ()"循环。 如果您不放置 while 循环、会发生什么情况？ DRM 驱动程序是否当时已安装？

我还在尝试了解 DRM() API 调用中的第二个参数是否会导致一些冲突。 您是否知道 X 是如何调用 drmopen() API 的？？

正如我在上一篇文章中所写的那样，这是一个完全无用的示例，因为它根本无法获得您所说的文件描述符，因为它需要驱动程序2。 它获取文件描述符并执行以下操作：

DRI2Connect (dpy、root、DRI2DriverDRI、&driver、&device) 

GLOBAL_FD =开路(器件、O_RDWR)； 

drmGetMagic (global_fd、&magic)； 

DRI2Authenticate (dpy、root、magic)； 

OMAP-DEVICE_NEW (GLOBAL_FD)； 

如果没有具有这些 DRI2调用的库、这是不可能的 

我在这里没有看到环路问题。 这是先前尝试将 libdce 移植到 debian 的结果、其中 open 随机失败。 

我不知道 X 是如何使用它的、因为它仅作为二进制包提供。 

您好 Ondrej、

您似乎是指 display-x11.c 文件。 请不要引用它，因为它在需要删除的应用程序中已失效的旧代码。 我刚才引用了该应用程序的 viddec3test 源文件。

您可能需要将 drmOpen(“omapdrm”、“platform:omapdrm:00”)替换为 drmOpen(“omapdrm”、NULL)调用，并检查其行为。  /dev/dri/card0是一个控制节点。 如果应用程序在有人打开 card0后打开它、它将自动作为渲染节点打开、即不允许模式设置。 但是、如果该应用程序(libdcce2)仅需要缓冲区管理、则不应打开 card0、因为如果碰巧是第一个打开它的应用程序、它可能会获得完全控制。

说这个例子是坏的，而不是找借口更容易。 该文件和显示 kms/wayland 仅是设置文件描述符的位置、kms/wayland 在此不相关。

drmOpen ("omapdrm"、NULL)提供的错误与之前相同。