使用智能盒子例程，RDK X5 运行6路hobot_rtsp_client.launch.py文件时，会会隔一段时间随机一路会出现容器崩溃错误

通用
,
5

既然单路/三路能稳定运行 3 天，而 6 路并发时才出现随机崩溃，问题定位就清晰了：这是 多路并发解码时的硬件资源竞争/瓶颈 问题，而非网络或编码格式问题。

核心结论

RDK X5 的 VDEC（硬件解码单元）通道数量有限，6 路 30fps H.265 并发可能超出硬件解码能力或触发资源竞争条件。

exit code -11 段错误是因为某路解码通道在资源不足时返回了非法指针，而 hobot_codec ROS 节点没有做空指针检查直接访问导致崩溃。

排查步骤

1. 确认 VDEC 硬件资源上限

RDK X5 的 VDEC 资源是有限的，需要确认：

  • 最大并发解码路数
  • H.265 vs H.264 的资源占用差异
  • 30fps vs 10fps 的带宽压力
# 查看当前 VDEC 通道使用情况
cat /proc/hb_vdec/status

# 或查看系统多媒体资源
sudo hb_sys show_vdec

关键问题：单路 1080P@30fps H.265 解码占用的 VDEC 资源是 10fps 的 3 倍。6 路 × 30fps 的总吞吐量可能接近或超过 VDEC 的设计上限。

2. 验证帧率影响（关键变量）

既然 3 路@30fps 稳定，建议测试：

  • 6 路 @ 15fps：如果稳定，说明是吞吐量瓶颈
  • 6 路 @ 10fps：如果稳定，进一步确认是帧率问题
  • 6 路 H.264 @ 30fps：对比 H.265 的资源占用差异

修改 launch 文件快速测试：

# 将 output_framerate 从 30 改为 15
{'output_framerate': 15},

3. 查看崩溃时的 VDEC 状态

在崩溃瞬间（或重启后立即）查看 VDEC 状态：

# 保存崩溃时的 VDEC 状态
cat /proc/hb_vdec/status > vdec_status_crash.txt

# 查看是否有通道报错或超时
dmesg | grep -i vdec | tail -50

关注点：

  • 是否有 vdec channel timeout 或 vdec resource busy
  • 崩溃的是否总是同一通道（如 ch_5）
  • 是否有 HB_VDEC_GetFrame 返回错误码

4. 检查 ROS 2 容器内资源竞争

6 路并发时，ROS 2 的 component_container_isolated 可能遇到：

  • CPU 调度延迟：6 路解码线程 + ROS 2 调度，可能导致某些线程饥饿
  • 内存带宽瓶颈：6 路 NV12 图像数据同时传输，可能触发内存访问冲突
# 监控运行时的 CPU 和内存带宽
top -H -p $(pgrep -f tros_container)

# 查看是否有线程长时间处于 D 状态（不可中断睡眠）
ps -eLo pid,tid,state,wchan | grep -i vdec

解决方案

方案 A：降低帧率（推荐优先测试）

将 6 路统一降为 15fps 或 20fps，观察是否稳定：

{'output_framerate': 15},  # 从 30 改为 15

原理：降低 VDEC 吞吐量需求，给硬件留出缓冲余量。

方案 B：分批次启动 + 延时

避免 6 路同时初始化解码通道，减少瞬间资源争抢：

# 在 launch 文件中为每路添加启动延时
from launch.actions import TimerAction

# 第 1 路立即启动
# 第 2-6 路各延迟 0.5 秒
TimerAction(
    period=0.5,
    actions=[LoadComposableNodes(...)]  # 第 2 路
),

方案 C：启用 VDEC 低延迟模式（如果 SDK 支持）

某些 SDK 版本支持配置 VDEC 的工作模式：

# 尝试添加低延迟参数（需确认 SDK 是否支持）
{'low_latency_mode': 1},
{'frame_drop_policy': 'oldest_first'},  # 忙时丢旧帧

方案 D：增加看门狗 + 自动重启

如果无法彻底解决，至少保证系统自愈：

# 使用 systemd 管理 ROS 2 launch 进程
sudo systemctl edit --full rdk_rtsp.service

# 添加重启策略
[Service]
Restart=on-failure
RestartSec=5
StartLimitBurst=3

社区相关案例

根据搜索结果：

下一步行动建议

  1. 立即测试：将 6 路帧率从 30fps 降为 15fps，运行 24 小时观察是否崩溃。
  2. 收集日志：下次崩溃时，立即执行 cat /proc/hb_vdec/status 和 dmesg | tail -100，保存日志。
  3. 补充信息到原帖：将你的测试结果（3 路稳定、6 路崩溃）和 vdec_status 日志回复到 原帖，方便官方开发确认是否为 VDEC 资源限制 Bug。

如果 15fps 能稳定运行：说明是硬件吞吐量瓶颈，建议生产环境控制在 15-20fps，或考虑用多块 RDK X5 分担负载。

如果 15fps 仍崩溃：可能是 SDK 层面的并发 Bug，需要官方介入排查。

CPU占满原因确认