Предисловие:

В этой статье читателям необходимо иметь определенное представление о потоках H.264, чтобы понимать различия между этими двумя форматами.

Первое, что нужно понять, это то, что не существует стандартного формата элементарного потока H.264. Документ содержит Приложение, конкретно описывающее один из возможных форматов — формат Приложения B, но это не обязательный формат. Документ стандартов определяет, как видео кодируется в отдельные пакеты, но то, как эти пакеты хранятся и передаются, остается открытым.

1. Приложение Б:

1、Network Abstraction Layer Units：

Пакеты, закодированные в видео, называются единицами уровня сетевой абстракции, также называемыми NALU и NAL. Каждый пакет NALU может анализироваться и обрабатываться отдельно. Первый байт каждого пакета NALU содержит тип NALU, бит3-бит7 содержит содержимое. особенно важно (бит 0 должен быть выключен, биты 1–2 определяют, ссылается ли на этот NALU другой NALU).

Форматы NALU делятся на две категории: VCL и не-VCL, всего существует 19 различных форматов NALU.

• VCL, пакеты уровня кодирования видео, содержат фактическую визуальную информацию, то есть закодированные данные видео.
• Non-VCL, contain metadata that may or may not be required to decode the video. Невидеоданные, информация о конфигурации

Одиночный пакет NALU или даже пакет NALU VCL не означает независимый кадр. Кадр данных может быть разделен на несколько NALU. Один или несколько NALU образуют единицы доступа (AU), содержащие полный кадр. Разделение кадра на несколько независимых NALU требует много ресурсов ЦП, поэтому разделение данных кадра используется не часто.

Ниже приведены все определенные типы NALU:

В формате NALU есть несколько пакетов, содержащих очень полезную информацию.

2. Стартовые коды NALU, стартовый код пакета NALU:

Данные в пакете NALU не содержат информации о его размере (длине), поэтому вы не можете просто объединить пакеты NALU для построения потока, поскольку вы не знаете, где заканчивается один пакет и начинается другой. В формате Приложения B для решения этой проблемы используется стартовый код, то есть к каждому NALU добавляется префиксный код: 2 или 3 0x00, за которым следует 0x01, например: 0x000001 или 0x00000001. Начальный код 4-байтового типа является непрерывным. Это очень полезно при передаче данных, поскольку очень легко использовать байты для выравнивания и разделения потоковых данных. Например, для разделения потоковых данных легко использовать 31 последовательный бит 0, за которым следует бит 1. Если следующий бит равен 0 (поскольку каждый NALU начинается с бита 0), то это начальная позиция пакетных данных NALU. Стартовый код 4-байтового типа обычно используется только для идентификации точек произвольного доступа в потоке, например SPS PPS AUD и IDR, а затем стартовый код 3-байтового типа используется в другом месте для уменьшения объема данных.

3. Байты предотвращения эмуляции, байты антиконкуренции:

Начальный код работает, поскольку 3-байтовая последовательность 0x000000, 0x000001, 0x000002 и 0x000003 (должны быть все 0x0000**) находится в формате, отличном от VCL (исходный текст не RBSP, транслятор изменен) NA Это запрещено в пакете LU, поэтому при сборке пакета ANLU необходимо убедиться, что эти числовые последовательности исключены. Это достигается путем вставки байта анти-гонки 0x03 в каждую последовательность этого типа. Затем после вставки анти-гонки. byte, 0x000001 Становится 0x00000301. При декодировании важно найти и удалить антирасовые байты. Поскольку байты анти-гонки могут появиться где угодно в пакете NALU, в документации часто удобнее предположить, что они были удалены.

4、Example：

Вот полный пример:

Это полная единица доступа (AU), включающая 3 пакета NALU. Как видите, последовательность данных начинается со стартового кода, за которым следует SPS (SPS начинается с 0x67). 2 антигоночных байта. Без этих байтов в этих местах появятся недопустимые последовательности данных. Затем вы можете увидеть стартовый код, за которым следует PPS (PPS начинается с 0x68), затем окончательный стартовый код, за которым следует пакет IDR. Это полный поток H.264. Если вы сохраните эти данные в шестнадцатеричном формате в файл с суффиксом .264, вы сможете преобразовать данные в изображение.

Формат Приложения B обычно используется для форматов потоковой передачи в реальном времени, таких как транспортные потоки, широковещательные передачи, DVD и т. д., передаваемых по беспроводной сети. В этих форматах пакеты SPS и PPS обычно повторяются периодически, часто перед каждым ключевым кадром, тем самым создавая точку произвольного доступа для декодера, который может присоединиться к текущему потоку и воспроизвести поток A, который уже передается.

2. АВКК:

Другой способ хранения потоков H.264 — это формат AVCC. В этом формате к каждому пакету NALU добавляется префикс, указывающий его длину (размер пакета NALU) (в формате с прямым порядком байтов). Этот форматированный пакет очень легко анализировать. , но этот формат удаляет приложение Функция выравнивания байтов в формате B, а также префикс может составлять 1, 2 или 4 байта, делает формат AVCC более сложным. Значение указанного номера байта префикса (1, 2 или 4 байта) сохраняется в файле. объект заголовка (начало потока), этот заголовок обычно называется «дополнительными данными» или «заголовком последовательности». Его основной формат следующий:

bits    
8   version ( always 0x01 )
8   avc profile ( sps[0][1] )
8   avc compatibility ( sps[0][2] )
8   avc level ( sps[0][3] )
6   reserved ( all bits on )
2   NALULengthSizeMinusOne    // Это значение (длина префикса-1). Если значение равно 3, то префикс равен 4, поскольку 4-1=3.
3   reserved ( all bits on )
5   number of SPS NALUs (usually 1)
repeated once per SPS:
  16     SPS size
  variable   SPS NALU data
8   number of PPS NALUs (usually 1)
repeated once per PPS
  16    PPS size
  variable PPS NALU data

Если использовать приведенный выше пример, дополнительные данные AVCC будут выглядеть следующим образом:

0x0000 | 01 64 00 0A FF E1 00 19 67 64 00 0A AC 72 84 44
0x0010 | 26 84 00 00 03 00 04 00 00 03 00 CA 3C 48 96 11
0x0020 | 80 01 07 68 E8 43 8F 13 21 30

Вы обнаружите, что SPS и PPS хранятся в пакетах, не относящихся к NALU (вне полосы), то есть независимо от данных элементарного потока. Хранение и передача этих данных является задачей файлового контейнера и выходит за рамки данной статьи.

• Примечание. Хотя формат AVCC не использует стартовые коды, байты, запрещающие гонку, все равно присутствуют.

Кроме того, в дополнительных данных есть переменная с запутанным названием NALULengthSizeMinusOne. Эта переменная сообщает нам, сколько байтов используется для хранения длины NALU (префикс: 1, 2 или 4). Если NALULengthSizeMinusOne равен 0, то каждый NALU использует префикс байта. Чтобы указать длину, максимальная длина каждого пакета NALU составляет 255 байт, что явно слишком мало. Этот метод слишком мал для хранения полного ключевого кадра. При использовании 2-байтового префикса для указания длины максимальная длина каждого пакета NALU составляет 64 КБ. Этого достаточно для нашего примера, но предел все равно относительно велик: 3 байта — это идеально, но по некоторым причинам это не широко. поддерживается, поэтому префикс длиной 4 байта в настоящее время является наиболее используемым методом, и именно этот метод мы используем здесь:

Одним из преимуществ формата AVCC является то, что при настройке декодера можно перейти к середине потока. Этот формат обычно используется для мультимедийных данных, к которым возможен произвольный доступ, например файлов, хранящихся на жестком диске.

Из-за этой особенности MP4 и MKV обычно сохраняются в формате AVCC.

Ссылка на статью: https://blog.csdn.net/Romantic_Energy/article/details/50508332.