第15章视频流安全

课程目录第15章视频流安全

15、视频流安全：帧丢失检测、时间戳校验、数据损坏恢复机制

视频流安全，说白了就是保证摄像头传过来的每一帧数据都是“对的”。

我在车载项目里遇到过最头疼的问题，不是图像不清晰，而是图像“看起来没问题，但时间戳乱了”。你想想看，如果环视系统的四路摄像头时间戳不同步，拼接出来的画面就会像喝醉了一样，左右晃动。更严重的是，如果帧丢失了，ADAS系统可能直接误判障碍物距离。

所以这一章，我们重点聊三个核心机制：帧丢失检测、时间戳校验、数据损坏恢复。这三个东西，是视频流安全的“三道防线”。

15.1 帧丢失检测：别让摄像头“偷懒”

帧丢失，就是摄像头该传30帧，结果只传了28帧。为什么会这样？

硬件传输不稳定（比如CSI接口信号抖动）
ISP处理超时（HDR合成太慢）
内存带宽不足（DDR被其他模块抢占了）

我个人的习惯是，在HAL层做一个帧序列号计数器。每个buffer进来时，检查它的sequence ID是否连续。

核心思路：用单调递增的帧序号做“心跳检测”。

// 伪代码：帧丢失检测
static uint32_t last_seq = 0;

int on_frame_received(buffer_t *buf) {
    uint32_t curr_seq = buf->sequence_id;
    
    if (curr_seq != last_seq + 1) {
        uint32_t lost = curr_seq - last_seq - 1;
        log_warn("帧丢失检测: 丢失 %u 帧 (seq %u -> %u)", lost, last_seq, curr_seq);
        // 触发恢复机制
        trigger_recovery();
    }
    last_seq = curr_seq;
    return 0;
}

避坑指南：我曾经遇到过一个问题——ISP在HDR模式下会偶尔跳过一帧，但sequence ID仍然是连续的。后来发现是ISP内部做了帧合并，把两帧合成了一帧。所以光靠sequence ID不够，还要结合时间戳做双重校验。

15.2 时间戳校验：别让“时间”骗了你

时间戳是视频流的“身份证”。如果时间戳错了，整个系统的同步逻辑就崩了。

在车载Android系统里，时间戳通常来自三个地方：

硬件时间戳：由Sensor驱动在中断服务里打上的，精度最高
ISP时间戳：ISP处理完图像后打上的，可能有延迟
应用层时间戳：App收到buffer后打上的，最不可靠

我建议的做法是：以硬件时间戳为准，其他时间戳只做参考。

// 时间戳校验逻辑
bool validate_timestamp(uint64_t hw_ts, uint64_t isp_ts, uint64_t app_ts) {
    // 1. 检查硬件时间戳是否单调递增
    static uint64_t last_hw_ts = 0;
    if (hw_ts <= last_hw_ts) {
        log_err("时间戳异常: 硬件时间戳未递增");
        return false;
    }
    
    // 2. 检查ISP时间戳与硬件时间戳的差值
    int64_t delta = (int64_t)(isp_ts - hw_ts);
    if (delta < 0 || delta > MAX_ISP_DELAY_US) {
        log_warn("时间戳偏差过大: ISP延迟 %ld us", delta);
        // 这里可以降级处理，但不一定丢弃
    }
    
    last_hw_ts = hw_ts;
    return true;
}

注意：千万不要在应用层修改时间戳！我见过有工程师为了“对齐”时间戳，在App里直接覆盖了硬件时间戳。结果导致整个Camera HAL的时间同步逻辑崩溃，环视画面直接错位。硬件时间戳是“圣旨”，只能读，不能写。

15.3 数据损坏恢复：坏帧来了怎么办？

数据损坏，就是图像数据在传输过程中被“污染”了。比如：

CRC校验失败（DDR比特翻转）
数据长度不对（DMA传输截断）
图像内容异常（全黑、全绿、花屏）

嗯，这里要注意：不是所有坏帧都需要丢弃。在车载场景下，有些坏帧可以“抢救”一下。

15.3.1 硬件级恢复：重传机制

如果底层驱动支持，可以请求Sensor或ISP重传当前帧。但重传有代价——会引入延迟。我个人建议：只在关键帧（比如ADAS决策帧）上启用重传。

// 重传请求示例
int request_retransmit(int stream_id, uint32_t seq) {
    // 向ISP发送重传命令
    struct isp_cmd cmd = {
        .type = CMD_RETRANSMIT,
        .seq = seq,
    };
    int ret = ioctl(isp_fd, ISP_IOC_SEND_CMD, &cmd);
    if (ret != 0) {
        log_err("重传请求失败: seq=%u, err=%d", seq, ret);
        return -1;
    }
    // 等待重传完成（超时机制）
    return wait_for_retransmit(seq, 100); // 100ms超时
}

15.3.2 软件级恢复：帧插值与降级

如果硬件不支持重传，或者重传超时了，那就得靠软件了。

帧插值：用上一帧的数据填补当前帧。适合预览场景，但不适合ADAS。
降级处理：比如从HDR模式降级到普通模式，减少ISP处理压力。
错误标记：在buffer的metadata里标记“此帧数据可能损坏”，让上层自己决定怎么处理。

我的经验：在某个项目中，我们遇到了DDR的“软错误”——比特翻转导致图像出现随机噪点。硬件CRC检测到了错误，但重传又超时了。最后我们采用了一个折中方案：把坏帧标记为“低置信度帧”，ADAS系统看到这个标记后，会降低该帧的权重，而不是直接丢弃。这样至少保证了系统不会因为一帧丢失而“断崖式”降级。

15.4 整体架构：三道防线

把上面三个机制串起来，就构成了视频流安全的完整架构。我画了一张图，方便你理解：

15.5 实战中的权衡

说实话，视频流安全不是“越严格越好”。你想想看，如果每丢一帧都触发重传，系统延迟会急剧增加。如果每个时间戳偏差都报错，log会被刷爆。

我个人的经验是：区分场景，分级处理。

场景	帧丢失容忍度	时间戳精度要求	数据恢复策略
ADAS/自动驾驶	极低（丢帧即降级）	微秒级	硬件重传 + 降级
环视/全景	中等（可容忍偶发丢帧）	毫秒级	帧插值 + 错误标记
DVR/行车记录	较高（可容忍少量丢帧）	帧级	直接丢弃，不恢复
预览/显示	高（用户不易察觉）	帧级	直接丢弃，不恢复

一个小技巧：在调试阶段，可以把所有检测到的异常都打印出来，甚至故意制造异常来测试恢复逻辑。我曾经写过一个测试工具，每隔100帧就伪造一次帧丢失，看看系统能不能稳定恢复。结果发现重传逻辑里有个死锁bug——嗯，还好是在实验室发现的，不是在路上。

最后说一句：视频流安全没有银弹。你需要根据具体的硬件平台、ISP能力、系统负载来调整参数。但不管怎么调，帧丢失检测、时间戳校验、数据损坏恢复这三个机制，一个都不能少。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

15、视频流安全：帧丢失检测、时间戳校验、数据损坏恢复机制

15.1 帧丢失检测：别让摄像头“偷懒”

15.2 时间戳校验：别让“时间”骗了你

15.3 数据损坏恢复：坏帧来了怎么办？

15.3.1 硬件级恢复：重传机制

15.3.2 软件级恢复：帧插值与降级

15.4 整体架构：三道防线

15.5 实战中的权衡