结论：loggerd 的相机/编码表是进程静态对象，不是运行时可重建的配置：encoderd 与 loggerd 各自加载同一头文件并构造本进程的静态表，运行中改参数不会重建配置表。RecordFront=false 在这条路径只代表「不写本地媒体文件」，座舱流仍会发布 cabinEncodeData 并可能写派生索引；RecordAudio 至少参与两个独立时刻的读取，二者不在同一事务。直播是独立的 stream_encoderd 进程与主题，录制与直播的保留/远程访问策略必须独立设计。
静态描述表与进程边界
EncoderSettings 给出编码参数：主流按输入宽度选 5/10 Mbps、GOP 20/30；qcamera 为 H.264、256 kbps、GOP 15；直播默认 H.264、5 Mbps、GOP 5，默认 B 帧数为 0。EncoderInfo/LogCameraInfo 由 topic、文件名、录制/音频/直播标志、输出尺寸、FPS 和 Cap’n Proto union 读写函数指针组成。
| 编码目标 | 编码与码率 | GOP | 默认 B 帧 |
|---|---|---|---|
| 主流（按输入宽度） | 5/10 Mbps | 20/30 | 0 |
| qcamera | H.264、256 kbps | 15 | 0 |
| 直播默认 | H.264、5 Mbps | 5 | 0 |
cameras_logged 含窄路面主流与 qcamera 两个编码器（共享同一路 VisionIPC 帧），广角与座舱各一个；stream_cameras_logged 是三路独立直播主题，record=false，没有媒体文件名也不配置缩略图。encoderd main() 无参数使用录制表，--stream 使用直播表，两种是同一可执行文件的不同进程模式。
录制策略不是编码生产开关
RecordFront 在座舱编码信息的静态初始化期间读一次，用作 record 字段。encoderd 的编码线程没用该字段过滤编码器：座舱流一旦被发现，仍会发布 cabinEncodeData。loggerd 也仍订阅非直播编码主题；record=false 时不创建 dcamera.hevc writer，但通过关键帧门后仍写 cabinEncodeIdx。
因此源文档的结论是：「关闭座舱录制」在这条路径代表不写本地媒体文件，不是停止座舱图像采集/编码，也不是证明下游没有索引。直播座舱流使用独立 topic 和进程，不能由 RecordFront 的本地文件策略自动推导其权限。
RecordAudio 的两个读取时刻
RecordAudio 至少参与两个独立时刻：qcamera 编码信息的 include_audio 在各进程静态初始化时读取；loggerd_thread() 建订阅时再次读取，只有当时为真才订阅原始音频。micd 的 callback() 本身持续发布 rawAudioData，并不以 RecordAudio 阻止采集。
在正常一致的启动快照下，loggerd 收音频后把它同时作为 rlog 普通事件和 qcamera 音轨输入。但两次 Params 读取不在同一事务，运行中切换也不会刷新已有订阅或配置表：若启动窗口内值变化，静态 include_audio 与实际订阅可能不一致。源文档指出，例如等待音频的 qcamera writer 未得到音频初始化包，会走有界包数的等待/丢包路径，是否在常规 manager 时序下可达需故障注入验证。
平台格式、直播与时间边界
| 项 | 静态行为 |
|---|---|
MAIN_ENCODE_TYPE |
依 Hardware::PC() 选择 PC 的 BIG_BOX_LOSSLESS 或设备的 FULL_H_E_V_C；固定 fcamera.hevc 文件名不能单独证明实际编码为 HEVC。 |
| 直播输出尺寸 | livestream_width()/height() 对 TIZI 为 1152×720、MICI 为 1280×720，其他设备返回 -1；VideoEncoder 构造器对非正输出尺寸退回输入尺寸。 |
STREAM_BITRATE |
用 atoi 读取且无配置层范围校验；运行时 LivestreamEncoderBitrate 由上层逐帧读 Params，PC 后端不支持动态调整。 |
SEGMENT_LENGTH |
通常固定 60 秒；LOGGERD_TEST 存在时改用 atoi(LOGGERD_SEGMENT_LENGTH)，是测试配置入口，不应作为生产插件 API。 |
直播三个 EncoderInfo 都没有文件名，且 loggerd 订阅时明确排除以 livestream 开头的 EncodeData，WebRTC 另行消费这些主题。录制与直播可以同用相机源，但数据保留/远程访问策略必须独立设计。两个进程各自加载同一头文件并构造本进程的静态对象，因此不能把它们的 Params 快照视为原子一致。
验证与重构要求
已有测试检查多路段媒体与索引、座舱文件有无、qcamera 音轨和 rlog 原始音频；源文档指出它们未直接断言 RecordFront 运行中变化时生产端是否继续编码、跨进程 RecordAudio 快照竞争、直播/录制权限隔离或静态表重建。本轮未运行这些测试。
插件宿主应将「采集许可、编码生产、本地存储、音频复用、上传、远程直播」拆为不同能力，并在一个版本化配置事务中确认生效时刻。隐私开关变更需要可观察的撤销/排空及下游回执，而不是只写 Params；录制与直播要按 topic、相机和车辆状态独立授权。台架验收应覆盖启动竞态、开关热变、进程重启不一致、qcamera 等音频、座舱关闭录制但仍发布 EncodeData、直播单独启停及文件/索引残留。
常见问题
关闭座舱录制（RecordFront=false）会停止座舱图像采集吗？
不会。源文档明确 encoderd 的编码线程没有用该字段过滤编码器，座舱流一旦被发现仍会发布 cabinEncodeData；record=false 只是不创建 dcamera.hevc writer，但通过关键帧门后仍写 cabinEncodeIdx。
RecordAudio 关掉后麦克风就停止采集了吗？
不会。源文档指出 micd 的 callback() 本身持续发布 rawAudioData，并不以 RecordAudio 阻止采集；RecordAudio 只影响 qcamera 的 include_audio 与 loggerd 是否订阅原始音频。
固定文件名 fcamera.hevc 能否说明实际编码是 HEVC？
不能。MAIN_ENCODE_TYPE 依 Hardware::PC() 选择 PC 的 BIG_BOX_LOSSLESS 或设备的 FULL_H_E_V_C，源文档明确固定文件名不能单独证明实际编码为 HEVC。
运行中修改录制/音频参数会立即生效吗？
不会。源文档指出配置在进程静态初始化时读取，运行中切换不会刷新已有订阅或配置表；两次 RecordAudio 读取也不在同一事务，启动窗口内值变化可能造成 include_audio 与实际订阅不一致。
延伸阅读
- 视频编码链路 —— 编码器内部的码率、GOP 与关键帧处理。
- LogReader 解码迭代生命周期 —— 录制产物的读取与解码侧契约。
- 崩溃收集与隐私 —— 隐私开关与下游回执的对照设计。
- V4L 解码器重配置与 surface 生命周期 —— 输出尺寸变化时的重配置边界。
参考资料
- 项目 02 ——
openpilot-research/ENCODER_CONFIG_RECORDING_LIVESTREAM_SNAPSHOT_DEEP_DIVE.md（取用了静态编码配置表、录制/音频/直播的进程快照边界、平台格式与时间边界、重构验证要求）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复