[参考译文] AM5728：平铺机中的 SGX 缓冲器

您好 Ramprasad、

谢谢、这对您有所帮助。 我们有一些问题：

我们发现、它还应与其他 SDK 的源代码一起使用、但对于是否计划同时为适用于 AM57XX 的 SDK 更新 SGX 器件的问题、没有直接的答案。 对于上述 PSDKLA、此修复程序的严重程度为 S2。

2.[引用用户="Ramprasad"]

您可以尝试在内核和 SGX 配方补丁上应用第三个补丁、它应该也适用于基于4.9K 的 SDK (但您可能会错过 TI-img-SGX/1.14.3699939分支中的几个 SGX-DDK-um 错误修复、这是 SDK 的当前分支)
如果 SGX 用户空间库没有依赖关系、则可以使用。

[/报价]

 请您详细说明/澄清 "不依赖 SGX 用户空间库"的含义吗？

谢谢、

此致、

Bartosz

您好 Ramprasad、

我们是否可以信赖您对上述两个问题的反馈？

谢谢、
Bartosz

尊敬的团队：

对上述2个问题有任何反馈？

谢谢、

此致

您好！

让我与专家核实一下、然后再与您联系。

此致、
玛格丽塔

您的 gstreamer 流水线和用例是什么？ 您将 SGX 用于什么用途？谁拥有它？  需要这些信息来引导您选择正确的路径和方法。  

大家好、Manisha、

用例显示来自 IP 摄像机(CCTV 系统)的视频。 因此、有必要启动多条 gstreamer 管道。 示例：

gs-launch-1.0 rtspsrc latiter=200 location="rtsp：//192.168.35.212/ axis-media/media.amp？videococodec=h264&h264profile=main&resolution=1024x768&fps=25"！ rtph264depay！ h264parse！ ducatih264dec！ VPE！ 'VIDEO/x-RAW、宽=1024、高=768'！ 陆上接收机

需要使用具有 capsfilter 的 VPE、因为没有该视频图像就会像我之前报告的那样卡住。

据我们所知、Weston、Waylandsink、解码器和 VPE 的存储器现在来自 tiler、这对我们的用例来说是非常有限的。 每个实例都"占用"大量平铺内存。 仅 Weston 就占20MB 以上的瓷砖(固定大小为218MB)。

感谢你的帮助。

此致、

Bartosz

大家好、Manisha、

祝您2018年一切顺利。 回到我们的讨论：

1.在 dra7.dts 中禁用 DMM 的 Hack 会导致 gstreamer 插件初始化中出现以下错误：

MmRpc_create：错误：连接失败
./git/libdce.c：416：DCI_IPC_init 错误：失败 eError == DCE_Eok 错误 val -4../git/libdce.c：479：

您是否有任何指导原则、为什么会发生这种情况/如何克服这种情况？

2.我们发现、如果我们按照编解码器文档中的说明更改 gstreamer 插件、我们可以使用更少的平铺存储器：  

解码器会分配较大的缓冲区来处理帧的重新排序、这不是必需的、因为它已经由源/jitterbuffer 元素处理。 ipumm/textrel/ti/ivahd_codecs/packages/ti/sdo/codecs/h264vdec/docs 中的文档包含有关通过减少 DDR 使用量的部分。 Gstreamer 插件将这些参数设置为自动。 是否可以为 gstreamer 插件添加该内容？

感谢您的帮助、
此致、Bartosz

谢谢 Bartosz！ 祝你新年快乐！！

[引用用户="Bartosz Marcinkowski"]

在 dra7.dts 中禁用 DMM 的 Hack 会导致 gstreamer 插件初始化中出现以下错误：

MmRpc_create：错误：连接失败
./git/libdce.c：416：DCI_IPC_init 错误：失败 eError == DCE_Eok 错误 val -4../git/libdce.c：479：

您是否有任何指导原则、为什么会发生这种情况/如何克服这种情况？

[/报价]

这是否适用于没有 Ducati 编解码器的流水线？

[引用 user="Bartosz Marcinkowski">解码器会分配大型缓冲区来处理帧的重新排序、而这不是必需的、因为它已经由源/jitterbuffer 元素处理。 ipumm/textrel/ti/ivahd_codecs/packages/ti/sdo/codecs/h264vdec/docs 中的文档包含有关通过减少 DDR 使用量的部分。 Gstreamer 插件将这些参数设置为自动。 是否可以为 gstreamer 插件添加该功能？[/quot]

我认为 jitterbuffer 元素不能处理 H.264标准强加的缓冲区重新排序。 如果您知道编码器的配置并且知道编码器不使用任何长期参考帧、则可以降低解码器缓冲器的要求。 如果应用程序应该作为通用解码器运行、能够对给定配置文件和级别的任何 H.264流进行解码、那么您将需要遵守该缓冲器上的解码器要求。  

[引用 user="Ondrej Bilka">通过 hack、我还遇到了陆地撞车事件、我最近才确认过这一点。 之前、我使用了来自源的 X 分支、该分支提供了该错误并预编译了 wayland 分支。 对于 wayland、我不确定这是否是由不兼容的内核引起的。 编译陆地分支、以查看存在相同的问题。

通过"hack"、您是否指的是在 DTS 文件 hack 中禁用 DMM？ 您运行了哪个应用程序来确认航迹是否崩溃？ 您看到了哪种类型的错误日志？ 您说的是陆地分支是什么意思？

[引用 user="Ondrej Bilka"] Jitterbuffer 处理 RTP 流的网络重传/重定序，在该帧与编码器的顺序相同之后，如果数据未及时到达，则会标记为丢失帧。

与显示延迟/重新排序相比、网络数据重新排序有所不同。 您可能会对这两者感到困惑。

有两个参数需要控制以减小 H.264解码器 DDR 存储器封装。 IH264VDEC_Params：：dpbSizeInFrames。

IVIDDEC3_Params：：displayDelay ->当帧的编码顺序(因此、解码顺序)与显示顺序不同时。  

H264VDEC_Params：：dpbSizeInFrames ->最大参考帧数(过去)编码器可以引用编码来编码当前帧。 对于5.1级、这被指定为16、但并非所有编码器都需要使用它。 大多数编码器最多可使用2到3个参考帧。  这个 wiki 页面可能有助于加深理解。  

  [引用 user="Ondrej Bilka">在本例中，我们发现摄像机默认使用 GOP=32，这会导致大量缓冲区使用。 减小该值是一种不理想的解决方法、因为它会增加网络负载。

降低脚部印花的重要因素不是 GOP 尺寸、而是 GOP 结构。 从 H.264随编解码器用户指南附录 F 部分提供-

"对于简单的 GOP 结构、通常、如果 dpbSizeInFrame 配置为 M+1、就足够了。 显示延迟设置为 M、其中 M = SPS -> max_num_ref_frames。"

您可能可以检查编码流的 SPS NAL 单元中的最大参考帧、并 相应地设置 viddecParams 字段值。