ffmpeg - 如何将多个 H.264 流合并为单个 H.264 流

Question

我使用 FPGA 中的几个并行 H.264 基线仅 I 帧编码器内核对相机图像进行编码(需要更多并行内核才能在没有外部存储器的情况下足够快地完成编码)。我使用开源 encoder .在模拟器上，我使用 352x288 yuv420 输入图像并将其切成 2 个水平半部分。
解码器在另一个嵌入式设备上，我可以正确解码分离的切片。但是，我只需要来自一个 H.264 字节流的一个视频序列(包含整个图像)，而不是几个解码的视频序列。最好在 FPGA 上合并 H.264 流(而不是通过在嵌入式主机上对解码后的切片视频序列进行后处理)。
因此，输入图像数据如下所示:

    .--.-----.--.--.-----.--.
    |MB|     |MB|MB|     |MB|
    | 0| ... |10|11| ... |21|
    |--.     '--|--'     '--|
    |MB|        |           |
    |22|        |           |
    |--'        |           |
    |   Slice   |   Slice   |
    |     0     |     1     |
    '-----------'----------'

编码器的框图是这样的(只显示了一个编码器核心，没有合并):

                                 YUV420 MacroBlocks (16*16 pixel)
                                         |       |
                                  chroma |       | luma
                                         |       |
                      .----------------.-------. |
                      |                | |     | |
                      |                v v     v v
                 reconstruct      intra8x8cc  intra4x4 ---> header
                      ^                |        |             |
                      |                v        v             |
                inv.transform        coretransform            |
                      ^                |     |                |
                      |                |     v                |
                  dequantise           | dctransform          |
                   ^       ^           |     |                |
                   |       |           v     v                |
        inv.dc.transform <-'---------- quantise               |
                                           |                  |
                                           v                  |
                                         buffer               |
                                           |                  |
                                           v                  |
                                          cavlc               |
                                           |                  |
                                           v                  |
                                         tobytes <------------'
                                           |
                                           v
                                         H.264 byte stream

来自单个核心的编码 h264 数据(用 H264Naked, 解析，参见 parse.txt 、 ref.yuv420 和 ref.264 )包含 3 个 NAL-s:在第一个中有一个序列参数集，在第二个中有一个图片参数在第三个中设置 IDR 图片的编码切片。 SPS 和 PPS header 是静态的，它们是在主机上生成的。 IDR 报头由 FPGA 上的编码器生成。目前我使用一个恒定的量化参数(即 VBR，但计划实现 CBR，稍后使用可变 QP)。
为了合并编码流，我从头 block 中的切片(切片 0 除外)中删除了 IDR 头。然后我将每个编码器的 CAVLC block 输出缓冲一整 MB 行(这是编码的 MB 数据，MB header 可以从 header block 的输出中识别)。然后从这个缓冲区中，我按以下顺序将所有 CAVLC 数据驱动到 tobytes block 的新实例:

切片 0

中一 MB 行的 CAVLC 数据

切片 1 中一 MB 行的 CAVLC 数据

以上重复直到帧结束。

当我解码这个合并的 H.264 流时，我得到以下 ffmpeg 错误(参见 merged_tobytes.264 和 ffplay_error.txt):

[h264 @ 0x7f5f0c00ac00] dquant out of range (-112) at 13 1B f=0/0   
[h264 @ 0x7f5f0c00ac00] error while decoding MB 13 1
[h264 @ 0x7f5f0c00ac00] concealing 396 DC, 396 AC, 396 MV errors in I frame

使用 JM 引用解码器，我收到此错误( jm_dec_error.txt):

mb_qp_delta is out of range (-112)
illegal chroma intra pred mode!

我认为问题在于解码器不知道切片并期望来自其他切片的相邻 MB 数据在编码数据中不可用。我已经检查了 standard 中的宏 block 预测语法。 (第 7.3.5.1 章)，但我不知道该如何纠正(我对 H.264 知之甚少)。在编码器方面，我看到 intra4x4 和 intra8x8cc 正在使用相邻 MB 预测和来自顶部和左侧 MB 邻居的像素数据(我们在第一 MB 行中没有顶部 MB 邻居，我们在每个 MB 行的第一个 MB，在每个切片中)。
我还尝试使用 FMO 并声明切片组 (slice_group_map_type=2)，如 here 所述，但是典型的 H.264 解码器不支持 FMO 和 slice 组(参见 ffmpeg issue，我认为它仅用于广播设备)。事实上，即使我已经声明了切片组(参见 merged_tobytes_with_slice_grops.264 和 jm_dec_slice_groups_error.txt)，我也从 JM 引用解码器中得到了错误:

warning: Intra_8x8_Horizontal prediction mode not allowed at mb 0
illegal chroma intra pred mode!

任何帮助表示赞赏。
引用照片取自 here .
PS:如果有人可以建议可以与此 FPGA 内核一起使用的解 block 器，那也很好。

Answer 1

你不能像那样交错切片数据。从解码器的角度来看，每个切片都应该是一个完整且独立的解码单元，因此解码器可以使用不同的切片解码实例(例如线程)同时解析和解码多个切片。
切片也应该在扫描顺序上是连续的。因此，在您的示例中，您希望水平切割图像(在彼此顶部的两个切片中)而不是垂直切割，然后在第一个切片之后附加第二个切片 - 并修复标题以发出信号正确的框架高度。这应该正确解码。要对更多切片执行此操作，只需将单个切片切小即可。但它们应该始终按扫描顺序连续。