[参考译文] Linux/AM5728：摄像头和 SDK 错误

软件团队已收到通知。

我们预计将在9月中旬之后进一步深入探讨这一点。

您是否正在尝试运行9个解码器实例？ 解码器内存来自平铺池，限制为128 MB (硬件限制)。 似乎流水线正在从更倾斜的存储器中运行。

来自客户：

我们使用适用于此模块的 PROCESSOR-SDK-LINUX-AM57X 04_00_00_04。 有一个名为 am57xx-EVM-Linux-SDK-bin-04.00.00.04.tar.xz 的文件、其中包含 AM57xx Linux SDK 预编译的 BSP 二进制文件和根文件系统。 当我们使用此参考根文件系统时、我们在使用 GStreamer 播放来自 IP 摄像机的 H264视频流时观察到奇怪的行为。

我们的步骤如下：
1) 1)我们在系统启动后停止"矩阵"应用程序。
2) 2)我们启动 Weston-terminal、并以以下格式运行多条 GStreamer 管道：

GS-launch-1.0 playbin uri ="rtsp：//192.168.35.212/ axis-media/media.amp？videococodec=h264&h264profile=main&resolution=1024x768&fps=25" video-sink=waylandsink

3) 3)在从开始的随机间隔内、一个或多个流停止工作(在一帧上冻结)。 以上流水线启动的三个或四个流足以重现问题。 有时、我甚至可以通过简单地聚焦具有特定摄像头流(这通常是残桩)的窗口来强制这一问题。

我们的观察结果：
-视频卡滞时没有 GStreamer 错误消息。
-当使用不同的分辨率和/或 fps 时，问题相似。
－摄像头是轴 P3905，连接和摄像头本身似乎没有问题。
-根据对 tcpdump 实用程序输出的分析，由于网络数据流仍处于活动状态，因此似乎只能自由计算“映像”。
-我还尝试从 TI GIT repo (4.9.47)编译最新的内核和 SGX 驱动程序，但问题仍然存在。
Git：//git.ti.com/processor-sdk/processor-sdk-linux.git：ti-ls-linux-4.9.y
-到目前为止，当我使用 H264视频文件而不是摄像头实时流(即 UI=file：//)时，我没有发现此问题 管道中)

尊敬的支持团队

对此有任何反馈吗？

Bartosz、

很抱歉耽误你的时间。 我们这个问题的主要软件工程师 Manisha 目前不在办公室。 Manisha 下周返回办公室、然后我们可以与您一起解决此问题。

此问题是否仅在运行多个流而不 是使用 playbin 解码和显示的单个实例时发生？

您是否尝试使用单个元素而不使用 playbin 来创建 gstreamer 流水线？ 如果您使用 fakesink 或 h264avdec 插件而不是使用 landsink 或 ducatih264dec、会发生什么情况？

这里的窗口聚焦意味着什么"我有时甚至可以通过简单地聚焦具有特定摄像头流(通常是残桩)的窗口来强制这种卡住。" ？

Manisha、

感谢您的支持。  首先、请查看您的问题的答案以及客户的其他意见。 第二、我们有一个有关 H264视频解码的新问题。

1) 1)关于您的问题

a)     此问题是否仅在运行多个流时发生、而不是在使用 playbin 解码和显示的单个实例中发生？
不、不是。 我也在一个实例中观察到了这个问题。

b)     您是否尝试使用单个元素而不使用 playbin 来创建 gstreamer 流水线？
是的、我确实这么做了、但我在 gstreamer 元素中找到了一些新信息。 请参阅下面的内容。
 
c)     如果您使用 fakesink 或 h264avdec 插件而不是使用 landsink 或 ducatih264dec、会发生什么情况？
Fakesink 不起作用、因为我说过没有 gstreamer 错误。 只是图像卡住了。 我可以告诉大家、avdec_h264工作正常、但这是一个大的 CPU 开销。

d)     您能不能根据"我有时甚至可以通过简单地获取具有特定摄像头流(通常是残桩)的窗口的焦点来指示您的窗口焦点是什么意思。" ？
只需单击视频窗口或将此窗口拖动到屏幕上的其他位置即可。

关于 b)：
我发现、如果将 ducatih264dec 源设备简单连接到运水接收设备、结果是相同的。 但是、当我使用 VPE 后处理时、其分辨率与请求摄像头流中的分辨率相同(1024x768)、那么就我所能说的那样、它可以正常工作。 此外、我在同一个 gstreamer 管道中使用了详细模式。 我发现、在第一种情况下、它会将"错误"的大小/分辨率传递给航迹接收机(1152x864)、尽管最终视频窗口的尺寸似乎正确(1024x768)。 示例：
 
较短格式的常用变量>gst_common='gst-launch-1.0 rtspsrc location="rtsp：//192.168.35.212/ axis-media/media.amp？videococodec=h264&h264profile=main&resolution=1024x768&fps=25"！ rtph264depay！ h264parse'

********
错误行为：
$GST_common！ ducatih264dec！ 陆上接收机

/GstPipeline0/GstDucatiH264Dec：ducatih264dec0.GstPad：灌电流：cap ="VIDEO/x-h264\、\ STREAM -格式\=(STRING\) byte-stream \、\对齐\=(STRING\) au、\ LEVEL\=(STRING\) 4.1、\(BLEGSTE= 1024) x (PRIENDE-1)、PRIORIORILE= 1) x (PRILEGERE= 1)、x (BLEGERTIE= 1024 (PRILEGERE= 1)、PRILEGERENTIES、PRILE-768、PRILEGATE =(PRILEGERILE-GRI)、PRILEGERILE
/GstPipeline0/GstDucatiH264Dec：ducatih264dec0.GstPad：src：cap ="VIDEO/x-RAW\、\ format\\(string\) NV12\、\ width\=(int\) 1152\、\ height\(int\) 864\、\(begray\) v= 1 m/像素比例1、ture-ref 1 (try= 1)、turbegy= 1 m/帧(turbegray\(try\) m\(try\(try\)) m/像素1) mref)、turbegroy= 1) m/(turbegraint)
/GstPipeline0/GstWaylandSink：waylandsink.GstPad：SINK：SINK：SINK：SINK：CAPS ="VIDEO/x-RAW\、\ format\=(string\) NV12\、\ width\=(int\) 1152\、\ height\=(int\) 864\、frame\= 1) m/像素比率(traction = 1)、toleum1)、tore1 (begy1)  

********
"正确"行为：
$GST_common！ ducatih264dec！ VPE！ 'VIDEO/x-RAW、宽=1024、高=768'！ 陆上接收机

/GstPipeline0/GstDucatiH264Dec：ducatih264dec0.GstPad：灌电流：cap ="VIDEO/x-h264\、\ STREAM -格式\=(STRING\) byte-stream \、\对齐\=(STRING\) au、\ LEVEL\=(STRING\) 4.1、\(BLEGSTE= 1024) x (PRIENDE-1)、PRIORIORILE= 1) x (PRILEGERE= 1)、x (BLEGERTIE= 1024 (PRILEGERE= 1)、PRILEGERENTIES、PRILE-768、PRILEGATE =(PRILEGERILE-GRI)、PRILEGERILE
/GstPipeline0/GstDucatiH264Dec：ducatih264dec0.GstPad：src：cap ="VIDEO/x-RAW\、\ format\\(string\) NV12\、\ width\=(int\) 1152\、\ height\(int\) 864\、\(begray\) v= 1 m/像素比例1、ture-ref 1 (try= 1)、turbegy= 1 m/帧(turbegray\(try\) m\(try\(try\)) m/像素1) mref)、turbegroy= 1) m/(turbegraint)
/GstPipeline0/GstVpe：vpe0.GstPad：灌电容="VIDEO/x-RAW\、\ format\=(string\) NV12\、\ width\=(int\) 1152\、\ height\=(int\) 864\、\ framera\\=(string\) vide\(try\) 1m\(begroy\)、tex\(tex\(try\) 1) begybegroy\
/GstPipeline0/GstVpe：vpe0.GstPad：src：cap ="VIDEO/x-RAW\、\ format\=(string\) NV12\、\ width\=(int\) 1024\、\ height\=(int\) 768\、\像素-宽高比\=(string\) 1\(frate\)分次/帧速率
/GstPipeline0/GstWaylandSink：waylandsink.GstPad：SINK：SINK：SINK：CAPS ="VIDEO/x-RAW\、\ FORMAT\=(STRING\) NV12\、\ width\=(int\) 1024\、\ height\=(int\) 768\、\、\像素纵横比= 1)、帧速率= 1
********

客户问题-为什么在不需要缩放视频时需要调用 VPE 后处理？ 如果有必要、有哪些限制？ 现在、它看起来更像是一个错误。


2)关于 H264解码

我们使用 Debian "Jessie" armhf、我想自己使用存储库中的软件编译 GST-Ducati。 我从标准存储库安装了其他 GST 插件。 我从 TI git 存储库下载了 ipcdev、libdcce2和 gst-plugin-Ducati 的源代码。 在几个黑客之后、我能够编译、链接并最终使用 GS-Ducati-plugin 启动 gstreamer。 我使用了此管道：  

gst-launch-1.0 rtspsrc location="rtsp：//192.168.35.212/ ax-media/media.amp？videococodec=h264&h264profile=main&resolution=640x480&fps=24"！ rtph264depay！ h264parse！ ducatih264dec！ VPE！ 'VIDEO/x-RAW、FORMAT=YUY2、width=640、height=480'！ xvimagesink

问题是、该流水线似乎每启动大约10或20次就能工作一次。 通常情况下、它会失败并显示以下消息(设置 GST_DEBUG 变量)：
-------------------------- 启动--------------------------------------------------------
正在将管道设置为暂停...
 >> DCE_INIT
打开 omapdrm 设备
 >> DCI_IPC_INIT
打开(/dev/rpmsg-dce)-> 0x150780
>> Engine_open 参数：：：name = ivahd_vidsvr size = 12
管道处于活动状态，不需要 PREROLL...
进度：(打开)打开流
进度：(连接)连接到 rtsp：//192.168.35.212/ax-media/media.amp？videocodec=h264&h264profile=main&resolution=640x480&fps=24
进度：(打开)检索服务器选项
进度：(打开)检索介质信息
进度：(请求)设置流0
进度：(打开)打开的流
正在将管道设置为正在播放...
新时钟：GstSystemClock
进度：(请求)发送播放请求
进度：(请求)发送播放请求
进度：(请求)已发送播放请求
0：00：00.613931977  499 bb500ed80 warn        rtpjitterbufferrtpjitterbuffer.c：185：rtp_jit_buffer_set_clock_rate：时钟速率从0更改为90000
0：00：00.625204614  499 bbb5032e60 WARN                 Ducati gstducatih264dec：c：402：GST_Ducati_h264dec 设置灌电流_cap： 未在电容器上找到 num 个重新排序的帧、根据流参数计算得出的值为16
0：00：00.625272609  499 bbb5032e60 WARN                 Ducati gstducatih264dec：410：GST_Ducati_h264dec 设置灌电流_cap： 使用16帧重新排序
0：00：00.632206112  499 bb5032e60 warn                 ducati gstducatividdec：c：552：codec_process： ERR=1、扩展错误=00208001
0：00：00.632252960  499 bbb5032e60错误                Ducati gstducati.c：63：GST_Ducati_log_extended _error_info：位0 (00000001)：无错误片
0：00：00.632283379  499 bb5032e60错误                Ducati gstducati.c：63：GST_Ducati_log_extended _error_info：位15 (00008000)：致命
0：00：00.632310219  499 bb5032e60错误                Ducati gstducati.c：63：GST_Ducati_log_extended _error_info：位21 (00200000)：不支持的分辨率
0：00：00.632718838  499 bb5032e60 WARN                 Ducati gstducatividdec：c：572：codec_process： 将电容器中的最大参考帧更改为18
---------------------------- 结束------------------------------------------

如果管道成功启动(很少)、则会正确显示视频流。 在更改 fakesink 而不是 xvimagesink 时行为相同。 解码器和后处理(VPE)在成功启动流水线的情况下似乎可以正常工作-当使用具有 fakesink 的流水线和摄像机几乎静态场景时、CPU 使用率约为4%。  您是否知道问题可能出在哪里？

谢谢你。

您好、Bartosz、

感谢您回答我的问题。 我们将深入研究这个问题、并在10月的第一周左右返回

您能为 H.264解码问题打开另一个 e2e 标签吗？ 让我们不要将一个 TT 杂乱地处理多个问题。 对于有相同问题的其他客户、搜索变得困难。

此致、
Manisha

您好、Bartosz、

同时、您能否要求客户在流水线中包含队列元素。 某些队列可能已满 或 src 元素开始丢弃帧、导致死锁。

还包括 GST 调试。 它们还可以生成具有基本配置文件或其他没有 B 帧的配置文件的流并对其进行测试吗？

较短格式的通用变量>GST_common='GST-launch-1.0 -v --GST-debug=2 rtspsrc location="rtsp：//192.168.35.212/axis-media/media.amp？videocodec=h264&h264profile=main_resolution =1024x768&fps=25"！ 排队！ rtph264depay！ 排队！ h264parse！ 队列"

********

$GST_common！ 排队！ ducatih264dec！ 排队！ 陆上接收机

Manisha、

客户根据您的请求调整了管道、并使用主配置文件和基线配置文件再次对其进行了测试。 遗憾的是、结果是相同的。 您可以在下面找到包含输出消息的日志文件：

/cfs-file/__key/communityserver-discussions-components-files/791/gst_5F00_h264_5F00_stuck_5F00_main.log

/cfs-file/__key/communityserver-discussions-components-files/791/gst_5F00_h264_5F00_stuck_5F00_baseline.log

大家好、Manisha 和 Team

请查看客户的最新反馈：

"我们的目标是：
-与 Xserver 一起使用的标准通用分发(Debian8)。
-我们为另一个硬件平台的此配置调整了多个应用程序，如果可能，我们应该在 AM572X 上对它们进行最小的更改。
-我们主要使用 OpenGL + Glu + GLX；SFML、GTK+。

了解 AM572x：
- TI/PowerVR 不支持 SGX544的 Xserver。
- Xserver -我们使用了 GC320 - FOSS 内核驱动程序 Etnaviv + xserver 视频驱动程序，实现了 XV 扩展。 因此、可以在 Gstreamer 中使用 xvimagesink。
- MESA/OpenGL DRI (GC320)-与 libGL 配合使用的位置、仅软件渲染。
- GST-PLUGE-Ducati 在某些黑客(ducatih264dec + VPE)下部分发挥作用。 问题是 gstreamer 流水线似乎每启动大约10或20次就能工作一次。 如果成功启动了流水线(ducatih264dec + VPE + xvivimagesink)(很少)、则会正确显示视频流、但仍然存在很高的 CPU 开销。 我想这是因为解码器+VPE => xviv磁 通之间的缓冲区复制。
从 debian 存储库和 PVR 库测试 Wayland/Weston 失败，显然是因为库不兼容。
总之，这种办法似乎是死的

推荐的解决方案？
- Linux 发行版-现在是 Debian 8 (armhf)=>迁移到 Arago 项目？
- 2D 图形应用程序-现在是 OpenGL + Glu =>重新写入 OpenGLES？
-图形后端-现在 SFML 和 GTK+=>重新写入 Qt5？
-视频图像处理(缩放、旋转、翻转、触发)-现在是 OpenGL 纹理(一线希望链接)操作=>航迹接收器+什么或"glesimagesink"？
"

大家好、Manisha、

感谢您的大力支持以及 IVI shell 的提示。 我们对您的信息有几个问题：

1) 1) PLSDK rootfs 中的 Qt5是否支持 IVI-application 协议？

2) 2)是否可以将 gstreamer 视频(landsink)呈现到 Qt widget 中？

我们发现使用类似的代码段可能会实现这一目标：

QPlatformNativeInterface *本机= QGuiApplication：:platformNativeInterface()；

struct wL_surface * surface = statical_cast (nativeResourceForWindow("surface"，the->windowHandle())；

 

GST_VIDEO_OVERLAY_SET_WINDOW_Handle (

      GST_VIDEO_OVERLAY (GST_MESSAGE_SRC (消息))、

      (光子)表面

    )；

GST_VIDEO_OVERRY_SET_Render 矩形(

      GST_VIDEO_OVERLAY (GST_MESSAGE_SRC (消息))、

      rect.x()、rect.y()、

      rect.width ()、rect.height ()

    )；

 

您对此功能是否有任何经验？

提前感谢您。

此致、

Bartosz

您好、Bertuz、
我们无法找到根本原因、但为什么引入 VPE 会注意到重现问题。
当您在管道中的 VPE 元素之后未添加任何 capsfilter 时、您能否检查问题是否可重现？

RAM

[引用 user="Bartosz Marcinkowski]1) PLSDK rootfs 中的 Qt5是否具有 IVI 应用协议支持？

QT 应用程序也可以在 IVI shell 上运行。 我们尚未使用 PLSDK 对其进行测试。 请在您的结尾处尝试、并让我们知道它是如何发展的。

2)是否可以将 gstreamer 视频(waylandsink)呈现到 Qt widget 中？

我们对此功能没有任何经验。

"我注意 到发布了新的 SDK (PROCESSOR-SDK-LINUX-AM57X 04_01_00_06)。 我下载了一个新的参考根文件系统。 其中应包括解决您提到的 Waylandsink 问题的补丁。 不幸的是，不良行为依然存在。

使用具有 VPE 但没有 capsfilter 的管道时、也会观察到不良行为：
gst-launch-1.0 -v rtspsrc latiter=1000 location="rtsp：//192.168.35.212/ axis-media/media.amp？videococodec=h264&h264profile=main&resolution=1024x768&fps=25"！ rtph264depay！ h264parse！ ducatih264dec！ VPE！ 陆上接收机

您可以再次观察到 Waylandsink 接收器的宽度和高度错误：
/GstPipeline0/GstWaylandSink：waylandsink.GstPad：SINK：SINK：SINK：CAPS ="VIDEO/x-RAW\、\ format\=(string\) NV12\、\ width\=(int\) 1152\、\ height\=(int\)分数\、\像素纵横比= 1) 864 (frate\) 1/frate

我们是否能够在终端的 IP 摄像机上重现此问题？

此致、

Bartosz

[引用用户="Bartosz Marcinkowski"]

我下载了一个新的参考根文件系统。 其中应包括解决您提到的 Waylandsink 问题的补丁。 不幸的是，不良行为依然存在。

[/报价]

Processor SDK Linux 选择了6周前发生的内核版本进行集成。 因此、在该季度结束前六周内应用的任何内核补丁都未能集成到 PLSDK 版本中。 Waylandsink 问题修复补丁错过了集成周期。 请离线应用、然后继续测试。

[引用 user="Bartosz Marcinkowski">使用具有无 capsfilter 的 VPE 的管道时、也会观察到不良行为：
gst-launch-1.0 -v rtspsrc latiter=1000 location="rtsp：//192.168.35.212/ axis-media/media.amp？videococodec=h264&h264profile=main&resolution=1024x768&fps=25"！ rtph264depay！ h264parse！ ducatih264dec！ VPE！ 航迹接收器[/报价]

使用 capsfilter 可以很好地工作？？

[引用 user="Bartosz Marcinkowski"]我们是否能够在最终使用 IP 摄像机时重现此问题？

我们没有使用 IP 摄像机进行测试的设置。

大家好、Manisha、团队、

我们仍然坚持使用 AM57XX、因为视频窗口的定位是此应用中的关键功能、我们的客户无法以任何方式做到这一点。

请参阅以下反馈、并向我们提供任何推进指南。

谢谢。

"在带有默认桌面 shell 后端的 Weston 中、根本无法从脚本定位窗口。 尽管使用 IVI shell 可以实现此功能、但启动带 Waylandsink 的 Gstreamer 会结束断句故障。 您的最终是否有此问题的进展？

如果我们无法定位具有硬件加速视频的窗口、则无法使用 AM57XX。 如果您有任何建议、请发送。 "

关于前面的问题：

"我们的设置包括本期内的 TI 硬件(EVM)+ TI 软件(SDK)(Gstreamer Waylandsink + IVI shell)。 那么、您能否复制它呢？

[引述]"Waylandsink 问题修复补丁错过了集成周期。 请离线应用、然后继续测试。"   [/报价]

据我所知、您提供的 Waylandsink 补丁只是对 userspace gstreamer 插件的"更新"、与 Linux 内核无关。 是这样吗？

最新 SDK 版本的软件清单显示、gstreamer1.0-plugins-bad-waylandsink 安装在版本1.8.3-R5.0中、其中1.8.3是特定软件的版本、R5.0是应用其他补丁等的 TI 配方的版本。 根据 Arago GIT 存储库、修补程序应该已经应用于安装在最新版本 SDK 中的 gstreamer1.0-plugins-bad-waylandsink 中。 但可能我错了？

您好、Bartosz、

我丢失了您之前的帖子、无法获得关于座机问题的大量历史记录。 它不再是该 e2e 线程的一部分。 尝试拆分 POST 以创建新线程、因为问题与最初创建的线程不同。 您是否可以打开主题为 gstreamer 的新线程、其中包含航迹接收器和 IVI 外壳。 请在新创建的 e2e 帖子中发布上一个问题及以上一个问题。