1. qtiqmmfsrc 不支持 num-buffers

现象

在 gst-launch-1.0 命令中加入：

qtiqmmfsrc camera=0 num-buffers=1

报错：

WARNING: erroneous pipeline: no property "num-buffers" in element "qmmfsrc0"

结论

qtiqmmfsrc 不是标准 videotestsrc 一类元素，不支持 num-buffers 属性。

处理方式

改用：

  • timeout 控制时长
  • 或后续用 identity / multifilesink / 后处理方式控制帧数

2. 直接 image/jpeg + filesink 生成空文件

现象

下面这类命令可以跑起来，但输出的 jpg 是 0 字节：

qtiqmmfsrc camera=0 ! 'image/jpeg,width=3840,height=2160' ! filesink location=/tmp/snapshot.jpg

原因

filesink 本身只是写字节流，不适合直接拿来当“单张拍照”的最终输出方式。

处理方式

改用：

... ! multifilesink location=/tmp/snapshot%d.jpg

然后再挑选某一帧复制成最终文件。

3. 前几十帧是黑图

现象

直接启动摄像头后保存的前几帧是黑的，后面帧才正常。

原因

摄像头初始化阶段，AE / AWB / ISP 还没稳定。

处理方式

采用“丢掉前 N 帧”的策略：

  • 先保存多帧
  • 再选择第 60 帧或更靠后的帧作为最终照片

经验

后来验证发现：

  • 丢前 60 帧后，图像正常
  • 有些场景下 120 帧更稳，但也会带来额外文件处理问题

4. pidof gst-pipeline-app / pidof gst-launch-1.0 产生错误日志

现象

测试 setup / cleanup 阶段会出现类似：

[Send] adb -s xxx shell pidof gst-pipeline-app
[Error]

原因

pidof 找不到进程时会产生错误日志，不影响主流程，但日志很吵。

处理方式

暂时把 stop_preview() 改成空操作，避免这类噪音日志。

5. 1080p 和 4K 拍照看起来都模糊

现象

把拍照分辨率改成 4K 后，视觉效果和 1080p 差不多，仍然模糊。

原因推测

可能是以下一个或多个原因：

  • 镜头本身成像质量有限
  • 当前镜头没有对上焦
  • AE / AWB 没完全稳定
  • 实际输出被 ISP 缩放或统一处理
  • 4K 分辨率只是“链路上声明了 4K”，不代表最终画面更清晰

结论

分辨率提高，不代表一定更清晰；画质取决于整个摄像头链路和镜头本身。

6. 4K 视频录制 MP4 无法播放

现象

录制出的 .mp4 文件存在，但无法播放。

原因

大概率是：

  • mp4mux 没有正常收尾
  • timeout 结束太硬，文件没写完整
  • 容器结构不完整，播放器无法识别

处理方式

改为尝试：

  • .mkv
  • .ts
  • 裸 .h264

其中 .ts 相对更稳。

7. 4K 视频录制文件时长不对，文件太小

现象

录制 30 秒后，输出文件只有几 MB，明显不像完整 30 秒视频。

原因推测

可能是：

  • 录制命令提前退出
  • timeout 影响收尾
  • 4K 负载太高导致持续录制不稳定
  • 实际帧率没达到预期

处理方式

先降负载测试：

  • 先用 1080p 验证链路
  • 再把 4K 帧率从 30fps 降到 15fps

8. 1080p 视频录制成功，4K 不稳定

现象

1080p TS 视频可以录出并播放，文件大小合理；4K 版本不稳定。

结论

说明：

  • 编码链路基本正常
  • 4K 主要问题是负载压力更大

经验

先用 1080p 建立基线，再逐步把 4K 拉回 30fps。

9. 并行录制的压力问题

现象

计划让 camera 0/1/2/3 并行录制时，需要考虑设备压力。

风险

四路同时跑 4K 可能会：

  • 丢帧
  • 编码失败
  • 文件不完整
  • 播放异常

建议

并行测试优先从 1080p 开始，确认并行逻辑稳定后，再考虑 4K 并行。

10. format! 字符串参数错位导致编译错误

现象

编译时出现类似：

unexpected token `duration_secs`

原因

format! 多行字符串中漏了逗号，或参数数量与占位符不匹配。

典型修复

检查：

format!(
    "... {} ... {} ...",
    duration_secs,
    output_path
);

是否遗漏了：

  • 字符串后面的逗号
  • 参数个数
  • 占位符顺序

11. 最终比较稳定的方案

拍照测试

稳定做法是：

  • qtiqmmfsrc
  • raw NV12
  • jpegenc
  • multifilesink
  • 丢掉前 60 帧
  • 复制目标帧为最终 snapshot

视频测试

较稳做法是：

  • 优先用 1080p 验证
  • 容器用 .ts
  • 编码链路保持简单
  • 4K 先降 fps 再调回 30fps

12. 经验结论

  1. 拍照链路比视频链路更容易稳定。
  2. 前几帧黑图是常见现象。
  3. 4K 的问题往往不是“有没有输出”，而是“负载和封装是否足够稳定”。
  4. 1080p 成功后，再逐步往 4K 提升，是最稳的调试路径。
  5. 视频录制优先追求“可播放、可稳定生成”，再追求更高画质。

13. 当前推荐脚本/用例

拍照

  • examples/camera_test.rs：1080p 拍照
  • examples/camera_test_4k.rs：4K 拍照

视频

  • examples/camera_video_test_1080p.rs：1080p 视频基线
  • examples/camera_video_test_4k.rs：4K 视频测试
  • examples/camera_video_parallel_1080p.rs：并行 1080p 视频测试

拉取脚本

  • pull_camera_snapshots_1080.bat
  • pull_camera_snapshots_4k.bat
  • pull_camera_videos.bat

14. 后续可继续优化的方向

  • 给视频测试增加独立日志文件
  • 给并行测试增加更清晰的结果汇总
  • 4K 视频录制再尝试更保守的编码参数
  • 增加拉取文件前的存在性检查
  • 增加自动转码脚本（ts/h264 -> mp4）