Media Foundation：Intel硬件MFT的SPS/PPS提取问题

我之前也遇到过完全一样的问题——Intel硬件MFT返回的序列头和软件编码器逻辑不一样，它用的是**AVCC格式（长度前缀分隔）**而非我们熟悉的字节流格式（00 00 00 01起始码分隔），这就是你找不到起始码的核心原因。

核心原因解析 #

Intel硬件MFT的MF_MT_MPEG_SEQUENCE_HEADER存储的是H.264的序列参数集（SPS）和图像参数集（PPS）的AVCC格式数据：每个NAL单元（SPS/PPS）前面会带4字节的大端长度前缀，用来标识后续NAL数据的字节数，而不是用00 00 00 01的起始码做分隔。

拆分SPS和PPS的具体实现 #

拿到sequenceHeaderData之后，你可以按照以下逻辑提取独立的SPS和PPS，适配Live555的要求：

// 假设sequenceHeaderData已经从MF_MT_MPEG_SEQUENCE_HEADER成功获取
vector<byte> spsData, ppsData;

if (sequenceHeaderData.size() >= 8) { // 至少需要两个4字节长度前缀的空间
    // 读取SPS的长度（大端字节序转32位整数）
    UINT32 spsLen = (static_cast<UINT32>(sequenceHeaderData[0]) << 24) |
                    (static_cast<UINT32>(sequenceHeaderData[1]) << 16) |
                    (static_cast<UINT32>(sequenceHeaderData[2]) << 8) |
                    static_cast<UINT32>(sequenceHeaderData[3]);

    // 检查剩余数据是否足够容纳SPS和PPS的长度前缀
    size_t spsEndPos = 4 + spsLen;
    if (spsEndPos + 4 <= sequenceHeaderData.size()) {
        // 提取SPS原始NAL数据（包含0x67开头的NAL头）
        spsData.assign(sequenceHeaderData.begin() + 4, sequenceHeaderData.begin() + spsEndPos);

        // 读取PPS的长度
        UINT32 ppsLen = (static_cast<UINT32>(sequenceHeaderData[spsEndPos]) << 24) |
                        (static_cast<UINT32>(sequenceHeaderData[spsEndPos + 1]) << 16) |
                        (static_cast<UINT32>(sequenceHeaderData[spsEndPos + 2]) << 8) |
                        static_cast<UINT32>(sequenceHeaderData[spsEndPos + 3]);

        // 检查剩余数据是否足够容纳PPS
        if (spsEndPos + 4 + ppsLen <= sequenceHeaderData.size()) {
            // 提取PPS原始NAL数据（包含0x68开头的NAL头）
            ppsData.assign(sequenceHeaderData.begin() + spsEndPos + 4, 
                           sequenceHeaderData.begin() + spsEndPos + 4 + ppsLen);

            // 现在可以把spsData和ppsData传给Live555
            // 例如调用H264VideoRTPSink的setSPSandPPS方法：
            // sink->setSPSandPPS(spsData.data(), spsData.size(), ppsData.data(), ppsData.size());
            cout << "Successfully extracted SPS (" << spsLen << " bytes) and PPS (" << ppsLen << " bytes)" << endl;
        }
    }
}

关键注意事项 #

1. 字节序处理：长度前缀是大端字节序，必须正确转换为本地整数类型，否则会得到错误的NAL长度。
2. 时机正确性：必须在处理MF_E_TRANSFORM_STREAM_CHANGE事件、调用SetOutputType更新输出媒体类型之后，再从新的媒体类型中提取序列头，否则拿到的可能是旧的无效数据。
3. Live555适配：Live555的H264VideoRTPSink需要的是原始NAL单元数据（带NAL头），不需要添加起始码——它会自动处理RTP封装和RTCP中的SPS/PPS同步信息。

验证你的序列头数据 #

你提供的序列头大小是50字节，按照这个方法拆分后，应该能得到以0x67开头的SPS和0x68开头的PPS（如果数据记录格式无误的话）。如果拆分后还是找不到正确的NAL头，可能是数据记录时混合了十进制和十六进制表示，但拆分逻辑是通用的。

内容的提问来源于stack exchange，提问作者iamrameshkumar