[参考译文] AM62A7：AM62A SDK 10.05 - H.264 双流解码+编码问题

尊敬的 Yeoncheon Yi：

您能否分享解码器挂起/停止处理时看到的日志？  

问题是否仅在 1920x1080@30fps 流时发生。 您能尝试将其中一个分辨率降低到 1280x720 吗、并尝试一次、而我这边也重现了这个问题。

解码器方面没有已知问题、我们应该能够解码多个解码流而不出现任何伪影/性能问题。

您正在使用 10.01.00.05 SDK 发布的软件进行测试、对吗？

此致、

Suren

我目前正在 TI SDK（版本 10.01.00.05）上使用 GStreamer 测试视频解码、并且遇到了解码器流水线在一段时间后意外停止的问题。

问题摘要

• 消息 :两条解码管道同时运行。

• 效率较低 ：一个是 1920x1080、另一个是 640x360 或 640x480。

• 问题 :其中一条管道意外停止,通常在几分钟内,并且不会超过一个小时。 另一个流水线继续运行。

• 调整为 0 :重新启动出现故障的流水线不会恢复正常操作。

• 按 Ctrl+C :有时,当使用 Ctrl+C 停止时,GStreamer 进程不会完全终止,并保持为僵尸进程。

• GStreamer 日志 :当增加 GStreamer 调试日志级别时,视频播放无法正常工作,并且没有显示有意义的日志。

• 内核日志 :流水线停止后,将出现以下内核消息:

由于这些日志、我怀疑问题与解码器 (wave5 VPU) 有关。

问题

• 您能解释一下该信息的result not ready: 0x800could not get output info含义吗？

• 这是解码器或固件的已知问题吗？

• 是否有任何建议的权变措施或修复方法来避免此行为？

提前感谢您的帮助。

您好：

我们目前正在使用以下网站上提供的软件映像使用直接从 TI 网站购买的官方 TI 评估板进行测试：

 https://www.ti.com/tool/PROCESSOR-SDK-AM62A

使用的版本为 10.01.00.05 、我们刷新了提供的 SD 卡映像、但未进行修改。

测试设置

• 输入流 ：

  • 功率 5000 ：H.264 编码流、位于 1920x1080 @ 30fps

  • 功率 6000 ：H.264 编码流、位于 640x360

• 使用 GStreamer 接收这两个数据流、然后使用单独的流水线将其重新传输到远程端点。

• 最初、两个数据流都被正确接收、解码和发送。 使用 GStreamer 的远程接收器也可以显示流、而不会出现任何问题。

问题

经过随机周期后运行、有时是如此 短至 2–3 分钟 ,而且最多 一小时之内 — 两个流水线之一停止传输 。 故障并不一致；任一流水线都可能随机停止。

虽然两者都正常运行、但每个 GStreamer 流水线的功耗约为 5% CPU 如所示top。 但是、一旦其中一个停止、其 CPU 使用率就会下降到 0% 、表示它不再处于活动状态。

恢复为低电平

第一个窗口 Ctrl-C 、其中一条管道退出并打印以下日志：

[   43.753540] audit: type=1334 audit(1753926992.689:21): prog-id=20 op=LOAD
[   43.901166] audit: type=1334 audit(1753926992.837:22): prog-id=20 op=UNLOAD
[  682.139715] vdec 30210000.video-codec: wave5_vpu_firmware_command_queue_error_check: result not ready: 0x800
[  682.149678] vdec 30210000.video-codec: wave5_vpu_firmware_command_queue_error_check: result not ready: 0x800
[  682.159515] vdec 30210000.video-codec: wave5_vpu_dec_finish_decode: could not get output info.
[  682.159658] vdec 30210000.video-codec: wave5_vpu_firmware_command_queue_error_check: result not ready: 0x800

。 其他流水线根本不会退出 ,并保持在一个僵尸般的状态。

重启行为

如果我们尝试使用以下命令重新启动发生故障的流水线：

gst-launch-1.0 -v udpsrc port=5000 caps="application/x-rtp, media=video, clockrate=90000, encoding-name=H264, payload=96" ! rtph264depay ! h264parse ! queue ! v4l2h264dec capture-io-mode=4 ! queue ! v4l2h264enc output-io-mode=5 extra-controls="controls,h264_i_frame_period=60,video_gop_size=60" ! h264parse config-interval=1 ! rtph264pay pt=96 ! udpsink host=192.168.123.180 port=7000

—有 无错误、无日志消息、无视频传输 。 流水线只是出现卡住且无响应。

摘要

• 问题似乎与vdec (wave5 VPU) 解码器块有关。

• 错误result not ready: 0x800并could not get output info仅显示 之后 流停止。

• 我们怀疑解码器挂起或固件队列死锁、但希望有任何见解。

问题

• 这是此 SDK 版本中 Wave5 解码器的已知问题吗？

• 是否有可用的解决方法或修补程序？

• 我们如何在不重新启动整个系统的情况下恢复解码器管道？

感谢您的帮助。

尊敬的 Yi Yeoncheon：

请在即将推出的 SDK 版本中对此进行测试。 计划在两周后发布。 有解码器修复。  

此致、

Suren

您好、Suren、

感谢您的更新。

我已经使用最新的 SDK 版本进行了测试 11.01.07.05 、它似乎是最近发布的。 遗憾的是、此版本仍然存在相同的解码器问题。

您能否确认您提到的修复程序是否包含在计划在接下来两周内发布的 SDK 版本中？ 我想确保此版本确实能够解决解码器问题。

此致、
李延川

尊敬的 Yi Yeoncheon：

我在主机 PC 上运行以下命令：

gst-launch-1.0 -v videotestsrc! video/x-raw、格式=NV12、宽度=1920、高度=1080、帧速率=30/1！ x264enc！ 排队！ rtph264pay！ TEE name=t t.！ 排队！ udpsink 主机=128.247.75.79 端口=5000 t ！ 排队！ udpsink 主机=128.247.75.79 端口=6000

目标 EVM：

gst-launch-1.0 -v udpsrc port=5000 CAP =“application/x-rtp、media=(string) video、clock-rate=(int) 90000、encoding-name=(string) H264、payload=(int) 96“！ rtpjitterbuffer 延迟=50！ rtph264depay！ h264parse！ v4l2h264dec！ kmssink driver-name=tidss sync=false

gst-launch-1.0 -v udpsrc port=6000 CAP =“application/x-rtp、media=(string) video、clock-rate=(int) 90000、encoding-name=(string) H264、payload=(int) 96“！ rtpjitterbuffer 延迟=50！ rtph264depay！ h264parse！ v4l2h264dec！ kmssink driver-name=tidss sync=false

一个多小时左右、 我没有观察到挂起或卡住的问题。 但有时第二个数据流会在显示屏上出现一些延迟。

我将尝试在已发布的 11.1 SDK 上运行。 您不应再看到这些警告、因为提交已经是 11.1 SDK 的一部分

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/media/platform/chips-media/wave5?h=ti-linux-6.12.y&id=eb39ef7d05eb995c941a74cb627f3a72b7458f61

此致、

Suren

亲爱的 Suren

您的测试似乎是通过使用将同一视频流拆分为两个分支进行的tee、在这种情况下、不会出现问题。
但是、要重现问题、您需要使用进行测试 两个完全不同的视频流 、每个端口都发送到一个单独的端口。

虽然我不确定根本原因、但我还确认、在两个端口上使用相同的流时、一切都正常工作。 但是、当使用两个完全不同的流时、问题几乎立即发生。

另外、请确保添加output-io-mode=5到编码器设置中。
这可确保测试充分利用硬件编码器、这对于准确验证至关重要。

您能以这种方式尝试吗？

BRS

Yeoncheon Yi

n 我的情况下,我测试了解码后重新编码,所以我不得不添加output-io-mode=5.
但是、由于您在kmssink解码后直接使用、因此您可能不需要output-io-mode在设置中使用。

gst-launch-1.0 -v \
udpsrc port=5000 buffer-size=524288 caps=“application/x-rtp, media=video, clockrate=90000, encoding-name=H264, payload=96“！ \
rtph264depay！ h264parse！ 排队！ \
v4l2h264dec capture-io-mode=4！ \
队列 max-size-buffers=4 泄漏=1！ v4l2h264enc output-io-mode=5 extra-controls=“controls,h264_I_frame_period=30,video_gop_size=30"！“！ \
h264parse config-interval=1！ rtph264pay pt=96！ \
udpsink host=192.168.123.180 端口=7000

gst-launch-1.0 -v \
udpsrc port=6000 buffer-size=524288 caps=“application/x-rtp, media=video, clockrate=90000, encoding-name=H264, payload=96“！ \
rtph264depay！ h264parse！ 排队！ \
v4l2h264dec capture-io-mode=4！ \
队列 max-size-buffers=4 泄漏=1！ v4l2h264enc output-io-mode=5 extra-controls=“controls,h264_I_frame_period=30,video_gop_size=30"！“！ \
h264parse config-interval=1！ rtph264pay pt=96！ \
udpsink host=192.168.123.180 端口=8000

我已在流水线上测试过。

谢谢

尊敬的 Yi Yeoncheon：

我在 11.1 SDK 软件上进行了验证、未在解码器上看到挂起或卡住问题。 此外、在停止流水线后、我不再看到这些警告。

附件是我从主机 PC 和目标 EVM 上运行的脚本。

主机 PC：  

./ send.sh（修改脚本中的主机 IP 地址以指向目标 EVM）。

e2e.ti.com/.../send.sh

receive.sh

e2e.ti.com/.../receive.sh

目标 EVM：

multistream.sh

e2e.ti.com/.../multistream.sh

我在大约一小时的跑步中没有看到任何问题。

此致、

Suren

亲爱的 Suren

首先、感谢您的测试和支持。
我已经使用您提供的脚本进行了测试。

使用带有移动球的测试图形或视频时、没有出现问题。
即使我从 MP4 文件创建 RTP 流,并通过不同的 UDP 端口发送两个不同的流,解码工作正常,没有任何问题。

不过、我们的实际用例涉及从摄像头接收实时视频并重新传输。 我们使用实际的摄像头输入进行了测试。
我们配置了两台摄像机、通过 UDP 输出 H.264,1080p、30fps。 使用单个摄像头输入进行测试时、没有问题。 但一旦添加了第二个摄像机流、两个解码器就会在几分钟内停止工作。

与 MP4 或测试图形输入不同、我们怀疑实时摄像头输入的各种因素可能会影响解码器。
该问题不仅限于特定的摄像机型号—我们在不同的摄像机品牌中发现了相同的问题、所有配置均相同 (H.264/1080p/30fps)。

如果可能、您是否还可以尝试使用实际的摄像头输入进行测试？
在我们的测试中、我们通过 RTSP 使用 IP 摄像头、然后重新编码、并通过 UDP 将数据流发送到 AM62A 器件。

再次感谢您的支持。

此致、

延川市  

尊敬的 Yeoncheon：

我也尝试了 2 个摄像头输入、没有发现任何问题。

这是我的设置。

一个 AM62A 板（电路板 A）（有 4 个通过 FPD Link 连接的摄像头、全部为 1080p @30ps） 、我使用 H.264 编码器捕获摄像头输入和编码、并通过 UDP 将其流式传输到另一个 AM62A 板（电路板 B）。

在电路板 B (AM62A) 上、我运行 multistream.sh 脚本（它正在解码来自电路板 A 的传入 UDP 流）并使用 H.264 编码器进行编码、并通过 UDP 将其流式传输到主机 PC。

进行编程。 我运行昨天附加的 receive.sh 脚本、在运行 3 个多小时后看不到任何崩溃。

我假定您的设置或网络有问题、这可能是导致问题的原因。

此外、如果解码器崩溃/解码器停止工作、GStreamer 日志将会捕获到它。

此致、

Suren

您好、Suren。

在我们的 AM62A 设置中处理实时摄像头流式传输时、他们遇到解码器错误和视频冻结。

根据他们的观察、可能的原因包括网络延迟、UDP 上的数据包丢失、缓冲问题以及流之间的时序/同步错误。 这些问题仅在实时摄像头输入时出现、而不在测试模式或基于 MP4 的流中出现。

您能否提供指导或建议最佳实践、以提高此环境中多摄像头实时流媒体的稳定性？

对于解码器的网络处理、缓冲参数和错误恢复设置、我们将不胜感激。

如果一个信道的数据流由于网络流量而延迟且解码器超时、是否实施了恢复机制？

目前似乎无法在您的环境中重现此问题。 是否可以通过调整超时值或缓冲大小来人为触发问题进行测试？

此致、

插孔

您好、Suren

我花了相当多的时间尝试在 SDK 11.x 上同时播放两个流,但结果没有成功。 没有网络问题或配置错误。 我使用商用摄像头进行了测试、这些摄像头直接连接到网络交换机、然后连接到 EVM、因此不会丢失数据包。

摄像机分辨率为 1920×1080 和 640×360。 低分辨率流始终停止。

我尝试了许多方法来解决这个问题、并最终确认流式传输在 SDK 9.02 上可以正常工作。 但是、SDK 9.02 存在一个关键问题：在对 1920×1080 进行解码和重新编码时、输出视频的前 8 个像素出现损坏。 10.xx 或 11.xx 上不会出现此问题。

如果 SDK 9.02 上有补丁可解决此问题、请告知我。

谢谢

BRS

Yeoncheon Yi

您好、

由于在 10.x 或 11.x 上未看到问题、您是否可以使用 10.x 或 11.x 中的 Wave5 驱动程序？

此致、

Suren

亲爱的 Suren

10.xx 和 11.xx 版本与 9.xx 版本不兼容、因为内核版本不同、导致 wave 驱动程序不兼容、wave 固件版本也不同、因此无法使用。

谢谢

BRS

Yeoncheon Yi

尊敬的 Yeoncheon：

请分享您正在使用的确切渠道？  

此致、

Suren

您好、Suren

这是我们的管道。

第一个流：1920x1080 (30fps)
gst-launch-1.0 -e \
rtspsrc location=rtsp：//admin：quopin1234@192.168.123.202/Streaming/Channels/101 delay=200 protocols=tcp！ 排队！ \
rtph264depay！ h264parse config-interval=–1！ \
v4l2h264dec capture-io-mode=4！ \
v4l2h264enc output-io-mode=5 \
Extra-controls='controls, video_bitrate_mode=0、video_bitrate=2000000、vbV_buffer_size=3000、frame_level_rate_control_enable=1、video_GOP_size=30、h264_MB_LEVEL_rate_control=1'！ \
h264parse config-interval=1！ rtph264pay pt=96 config-interval=1！ \
udpsink host=192.168.123.180 端口=8000 sync=false

第二串流： 640x360(30fps)

gst-launch-1.0 -e \
rtspsrc location=rtsp：//admin：quopin1234@192.168.123.202/Streaming/Channels/102 delay=200 protocols=tcp！ 排队！ \
rtph264depay！ h264parse config-interval=–1！ \
v4l2h264dec capture-io-mode=4！ \
v4l2h264enc output-io-mode=5 \
Extra-controls='controls, video_bitrate_mode=0、video_bitrate=2000000、vbV_buffer_size=3000、frame_level_rate_control_enable=1、video_GOP_size=30、h264_MB_LEVEL_rate_control=1'！ \
h264parse config-interval=1！ rtph264pay pt=96 config-interval=1！ \
udpsink host=192.168.123.180 端口=8000 sync=false

“如有必要、我们可以打开 RTSP 服务器、以便您可以访问这两个数据流。 如果您可以指定确切的时间、我可以设置一个环境、在该环境中、您可以测试流大约 12 小时。 这是可能的吗？“

谢谢  

BRS

YeoncheonYi

亲爱的 Suren

我已经为你准备好了。
如果您可以使用以下链接进行测试、我将不胜感激：

第一：

RTSP：//admin：quopin1234@115.94.118.69/Streaming/Channels/101

第二个:

RTSP：//admin：quopin1234@115.94.118.69/Streaming/Channels/102

请在版本 11.xx 上进行测试

期待取得积极成果。 非常感谢

BRS Yeoncheon Yi

尊敬的 Yeoncheon：

感谢您进行设置。 我将在今天或明天稍后时间尝试使用我的 AM62A 进行验证、然后回复您。  

根据我的理解、您正在对这两个 rtsp 流进行解码和编码、并通过网络将它们作为 UDP 流发送、是吗？

此致、

Suren

您好、Suren

正确。 目的是接收 RTSP、对其进行解码、更改比特率、然后通过 UDP 重新传输。
此外、由于我们需要更强大的 AI 功能、我们购买了 AM67A 并使用 SDK 版本 11.xx 对其进行了测试、但也会出现相同的问题。 供您参考。 谢谢你。

BRE

Yeoncheon Yi

尊敬的 Yeoncheon：

我在安装 11.1 SDK 时运行了这两个数据流、没有发现任何问题。

此致、

Suren

亲爱的 Suren

测试并不会立即失败、因此如果您能运行大约 2-3 小时、我将不胜感激。

谢谢

此致

Yeoncheon Yi

尊敬的 Yeoncheon：

我已经给了它一个通宵的运行。 让我在上午查看并更新。  

此致、

Suren

您好、Suren

好的。 谢谢。我期待取得积极成果

BRS

Yeoncheon Yi

尊敬的 Yeoncheon：

运行超过 18 个小时后仍能正常运行。 没有观察到伪影。

此致、

Suren

亲爱的 Suren

感谢您的测试。

您能否分享您使用的渠道？

我会再试一次的。 此外、您能否确认您使用的 SDK 版本是否为 11.01.07.05？

谢谢

BRS

Yeoncheon Yi

是的、我使用 11.1 SDK 发布的软件和默认映像。

附件是我用于测试的脚本。

e2e.ti.com/.../rtsp_5F00_scripts_5F00_two_5F00_streams.sh

e2e.ti.com/.../5415.receive.sh

希望这有所帮助。  

此致、

Suren

亲爱的 Suren

我在相同的条件下进行了测试。
但是、在观看视频时、顶部的计时器应不断增加、但在运行发送流水线几分钟后、所有计时器都不会继续增加。
我使用从 TI 网站下载的 SDK 版本 11.01.07.05 对此进行了测试。
在这两个视频中、计时器都停止了。
无论如何、即使在 18 小时后、计时器是否仍在不断增加？

谢谢

BRS

Yeoncheon Yi

我看了看时间。  现在我没有运行设置。

让我知道您是否仍在跑步中看到神器？

此致、

Suren

亲爱的 Suren

是的。 视频左上角的计时器应持续向上计数。
如果视频不可见或一直卡住、则表示视频未传输。
在相同的设置下、我们始终观察到视频一直冻结。

谢谢你。

BRS

YeoncheonYi

尊敬的 Yeoncheon：

您是否可以将摄像机放置到具有运动而非静态图像的物体上、这样您就可以了解其是否冻结。

如上所述、我已经尝试使用 2 个 AM62A 板进行解码和编码、然后流式传输到我的 PC、而没有之前分享的任何问题。

此致、

Suren

亲爱的 Suren

现在我将要离开工作岗位、但大约一个小时后、我将把摄像机移动到一个有动作的地方。

谢谢

BRS

YCYI

好的、将等待您的测试运行更新。

此致、

Suren

我已将摄像头设置为指向风扇。 请检查并告诉我。

BRS

YeoncheonYi

RTSP SRC 是否仍然完好且正确？

此致、

Suren

是的。 RTSP 源正常工作。

谢谢
BRS

YeoncheonYi

亲爱的 Suren

e2e.ti.com/.../KakaoTalk_5F00_20250918_5F00_092427748.mp4

源仍然 工作正常。

谢谢

BRS

YeoncheonYi

我今天已经离开了工作。 会在明天尝试测试。 同时、请告诉我您的测试结果。

此致、

Suren

尊敬的 Yeoncheon：

今天我尝试玩设置,但我只能看到一个相机源。 看不到这两者。

此致、

Suren

亲爱的 Suren

我刚刚检查过、两个数据流都正常传输。 您这边可能会出现问题吗？ 如果可能、请尝试与 VLC Player 核对以确认流是否正确传输。

谢谢

BRS

YeoncheonYi

是的、延川  

我能够看到这两个流。 它运行正常了一段时间。  

您是否发现在使用 11.1 SDK 的最终版本中报告了任何问题？

此致、

Suren

亲爱的 Suren

即使使用您提供的流水线、一个流仍正常工作、但低分辨率视频始终停止解码、并在一段时间后（通常在一小时内）冻结。 此外、版本不是 11.1、而是 11.01.07.05。

正如我已经多次提到的那样、较小的视频完全冻结、没有任何移动、日志中也不会打印任何信息。 发送 GStreamer 的时间戳也会停止、并且不会再进行任何进展。

谢谢

最好的应届毕业生  

Yeoncheon Yi