[参考译文] Linux/PROCESSOR-SDK-AM57X：H.264 GStreamer 流水线的大延迟

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/653853/linux-processor-sdk-am57x-big-latency-of-h-264-gstreamer-pipeline

器件型号：PROCESSOR-SDK-AM57X

工具/软件：Linux

我正在评估板上使用最新的预编译 SDK (am57xx-EVM-Linux-SDK-bin/04.02.00.09.tar.xz)。我们遇到了硬件 h264解码器导致不可接受的大延迟的问题。软件解码器显示相同的流、延迟低于100ms (但 CPU 使用率为80%)。如果我们不在 rtsp 源代码中使用延迟参数(无论是否使用 jitterbuffer)、硬件加速视频的延迟约为三秒

如果我们使用延迟参数、则需要400ms 才能使摄像机分辨率1024x768正常工作。但较小的分辨率更糟糕、解码320x200、640x480或800x600需要至少600ms 的延迟。

具有较小延迟的 gstreamer 每秒只渲染一个帧、并显示以下警告

警告：从元素/GstPipeline:Pipine0/GstlandWaySlink：waylandsink0：大量缓冲区正在丢弃。
其他调试信息：
./../../../gstreamer-1.8.3/libs/gst/base/gstbasesink.c (2854)：gst_base_sink_ies_s_too_elate ()：/GstPipeline0/GstWaylandSink：waylandsink0：
可能存在时间戳问题、或此计算机速度太慢。

正确工作的软件解码流水线如下：

Cx=1024
CY=768
X=1024
Y=768
延迟= 100
gst-launche-1.0 rtspsrc latiter=$latency location="rtsp：//192.168.33.46/axis-media/media.amp？videococodec=h264&h264profile=main&resolution=$｛cx｝x$｛cy｝&fps=25"！ \
rtpjitterbuffer！ rtph264depay！ h264parse！ avdec h264！视频转换！ fpsdisplaysink 视频接收器=kmssink

硬件加速之一是以下流水线(问题与 kmsink 和 landsink 相同)：

延时= 500
Cx=320
CY=200
X=320
Y=200
gs-launch-1.0 rtspsrc latiter=$latency location="rtsp：//192.168.33.46/axis-media/media.amp？videococodec=h264&h264profile =main&resolution=$｛cx｝x$｛cy｝&fps=25"！\
rtpjitterbuffer！ rtph264depay！ h264parse！ ducatih264dec！ VPE！ 'VIDEO/x-RAW、width='$｛X｝'、height='$｛Y｝！陆上接收机

8 年多前

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

请在流水线中添加几个队列元素。
例如、您可以在此处添加以下元素：

gst-launche-1.0 rtspsrc latiter=$latency location="rtsp：//192.168.33.46/axis-media/media.amp？videococodec=h264&h264profile=main&resolution=$｛cx｝x$｛cy｝&fps=25"！排队！
rtpjitterbuffer！ rtph264depay！排队！ h264parse！排队！杜拉蒂哈264decvpe！ 'VIDEO/x-RAW、width='$｛X｝'、height='$｛Y｝！排队！陆上接收机

请告诉我结果。

BR
玛格丽塔

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

是的、这很有帮助。但它看起来与较小分辨率速度较慢无关。它将每个地方的延迟减少了大约200ms、我可以播放1024x768、延迟200ms、但320x200、640x480、800x600需要400ms (原始帖子中的问题现在发生在延迟100和300)

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

您可以尝试以下操作：
...！杜拉蒂哈264decvpe！ 'VIDEO/x-RAW、width='$｛X｝'、height='$｛Y｝！队列最大大小缓冲区=2！陆上接收机
如果较小的分辨率仍然有问题、可以尝试设置 rtspsrc 属性 drop-on-latiter=true。默认值为 false。
请告诉我结果。

BR
玛格丽塔

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

大家好、使用这些工具没有变化。还尝试设置"DO－retransmission = false"以消除这种可能性

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

我还可以使用 GS-rtsp-server 中的 rtsp 服务器示例复制此内容、即此示例
github.com/.../test-video.c

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

您可以尝试设置这些 rtpjitterbuffer 属性 later=100和 drop-on-later=true。

我不确定您尝试的管道是什么、但您可以在解码器和 VPE 之间添加队列。
可以设置 VPE 的 num-input-buffers=8属性。
rtspsrc 元素不是 TI 元素。我建议您搜索有关它和延迟属性的更多信息。

BR
玛格丽塔

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

不管用。 Ducati 插件的分辨率是否存在任何已知限制？它看起来像解码器及其时间戳处理中的问题、因为用 avdec 替换它会更好

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

您可以检查此文件 gstducatih264dec．c 以了解分辨率。请发布您正在使用的最新管道。
如果未在流水线中设置 SYNC=false、请设置它(...！ landwaysink 同步=假或....！ kmssink sync=false)。

gst-launch-1.0 rtspsrc latiter=200 location="rtsp：//…… videocodec=h264&h264profile=main&resolution=1024x768&fps=25"！排队！ rtph264depay！排队！ h264parse！！！排队！ ducatih264dec！ VPE！ 'VIDEO/x-RAW、宽=1024、高=768'！ landwaysink 同步=错误

BR
玛格丽塔

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

我的问题更多地是关于分辨率的硬件限制。 gstducatih264dec 是 libdce 上的包装器、它接受带有16至2048参数的任何分辨率、并且只执行一些填充。它引用了 libdce ti/sdo/codec/h264dec /ih264vdec.h、但我在那里没有找到有关分辨率的详细信息。

由于延迟和 SYNC=false，这是由于我们的应用程序是 CCTV 系统而造成的问题。流水线可能会累积数秒延迟(或者在最坏的情况下会卡在一个帧上)、并且用户采取错误操作的风险、因为他认为可预测延迟/看不到时间变化比可预测延迟差得多。

我试过很多管道、但没有发现效果、最后一个是
(笑声) ！！ rtpjitterbuffer latiter=200 drop-on-later=true！ rtph264depay！排队！ h264parse！排队！ ducatih264decvpe num-input-buffers=8！ 'VIDEO/x-RAW、width='$｛X｝'、height='$｛Y｝！排队！陆上接收机

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

您可以查看解码器用户指南、了解有关分辨率和解码器本身支持的更多信息。
git.ti.com/.../docs
您是否在我的上一个帖子中检查了删除了 rtpjitterbuffer 元素的管道。

BR
玛格丽塔

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

谢谢、手册帮助我理解了这里的问题。

对于分辨率文档、仅支持16-2048范围内的任意分辨率。

根据文档、我发现解码器保留多个帧用于重新排序的可能原因。对于 RTP 流而言、它是无用的、因为源和 rtpjitterbuffer 已经处理重发送和重排序。 ducatih264dec 中有 max-reorder-frames 属性，但在可以从流中推理时不使用该属性。

它在解码器 API 中看起来是可访问的、但不能在 gstreamer 插件1中访问。请参阅减少 DDR 使用量部分。可以对其进行修补吗？如果在一个排气管中运行多个管道时、随机存储器管道将会崩溃(发生在陆地上的4个1024x768解码器上)、这也将有助于解决我们的另一个问题。

返回管道使用或不使用 jitterbuffer 没有区别、您的最后一个示例也不包括其中一个、所有东西在1024x768下都需要200ms 的延迟、在320x200和其他分辨率下需要400ms 的延迟。

在接收端使用 SYNC=false 时、很容易产生几秒的延迟并不断增加。我可以通过添加导致软件转换的视频转换来实现它。

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

GST ducatih264dec 具有最大属性重新排序帧默认值为16。范围为[0-16]、0表示不重新排序。此外、display_delay 和 dpbSizeInFrames 设置为 auto (检查 gstducatih264dec)。

BR
玛格丽塔

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

它看起来会忽略最大重新排序帧、而是使用流中的值。

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

当我在另一个线程中写入时、我现在确定这个问题是由解码器中太大的缓冲器引起的。

它仅使用从 GOP 大小派生的值。
当摄像机使用基线轮廓时、这毫无意义、这意味着没有 B 帧、而文档显示只有在 B 帧存在时此参数才有意义。或者、如果我们从摄像头文档中了解正确的重新排序参数。在 gstreamer 中、网络错误/重新排序由 jitterbuffer 处理。帧将与源帧具有相同的顺序、如果由于时间限制而无法实现、帧将标记为丢失。

在本例中、摄像头使用 GOP=32作为默认值、这会导致这些问题。将摄像头 GOP 更改为较低值可消除此问题。

由于它与观测到的一帧/秒一致、可能会发生以下情况：

GOP 中的第一个帧是即时显示的 I 帧。
没有显示其他帧、因为在接下来的16帧(大约500ms)之前、为了填充解码器缓冲器到达接收器检测到帧太晚、并将信号发送到丢弃帧。

0 admin 8 年多前

TI__Guru**** 2609955 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

我在我的一侧进行了几次测试、以下是观察结果：

-default libgstducati.so

我使用此流水线解码了视频：

gst-launch-1.0文件 rc location=b_test.avi！救世主！ h264parse！ video/x-h264、stream-format=byte-stream、num-reorder-frames=0、！ ducatih264dec ！ VPE！ VIDEO/x-RAW、FORMAT=NV12、width=1280、height=720、framerate=30/1！陆上接收机

在日志中、我观察到以下情况：

0：00：00.151752383 1343 0x159030 WARN Ducati gstducatih264dec：410：GST_Ducati_h264d_dec_set_sink_cap： 使用0帧重新排序
/GstPipeline0/GstDucatiH264Dec：ducatih264dec0.GstPad：sink：cap ="VIDEO/x-h264\、\ stream-format\=(string\) byte-stream \、num-int-frames\\\\\\\\、variant\=(trlected=)、randlensore=(trl针对字符串)、rality= 1) ralignment (trlectured、randwidth = 1)、ralignment (trature= 1) rand/frature=(ralignment) x (trl、rand/trature= 1) x (true/true/frature=) rand/true/true/true/true/true/true/true/true/true/tr

0：00：00.498532665 1343 0x159030 WARN Ducati gstducatividdec：c：590：codec_process： 将电容器中的最大参考帧更改为11

Max-ref=帧在我的情况下设置为11。它取决于流。解码器根据流属性决定要锁定的帧数。

此外、这些参数在 gstducatih264dec 文件中设置为 Auto：

self->params->displayDelay = IVIDDEC3_display_delay_Auto；
params->dpbSizeInFrames = IH264VDEC_DPB_NUMFRAMES_AUTO；

我将两个参数都更改为 IVIDDEC3_DISPLAY_DELAY_1和 IH264VDEC_DPB_NUMFRAMES_1。这种情况的结果如下：

0：00：01.087428941 1099 0x212490 WARN Ducati gstducatividdec：c：594：codec_process： 将电容器中的最大参考帧更改为3
/GstPipeline0/GstDucatiH264Dec：ducatih264dec0.GstPad：src：cap ="video/x-ray\、\ format\=(string\) NV12\、\ width\=(int\) 1408\、\ height\=(int\) 816\、\、try=(frame=) m/(max3) me-mref)、toleurbl

您可以尝试更改这些参数(有关详细信息、请参阅 h264dec 用户指南)。
希望这对您有所帮助。

BR
玛格丽塔

处理器（参考译文帖）

处理器（参考译文帖）(Read Only)

[参考译文] Linux/PROCESSOR-SDK-AM57X：H.264 GStreamer 流水线的大延迟