Что такое битовые потоки в ffmpeg?

Question

После тщательного чтения FFmpeg Bitstream Filters Documentation, я до сих пор не понимаю, для чего они предназначены.

В документе говорится, что фильтр:

выполняет модификацию битового потока на уровень без выполнения декодирования

Может кто-нибудь объяснить, что дальше мне? Случай использования сильно прояснит ситуацию. Кроме того, существуют различные фильтры. Как они отличаются?

Answer 1

Позвольте мне объяснить на примере. Видеодекодеры FFmpeg обычно работают путем преобразования одного видеофрагмента на звонок в avcodec_decode_video2. Таким образом, ожидается, что вход будет иметь значение «одного изображения» битовых потоков. Давайте рассмотрим эту проблему перехода из файла (массив байтов диска) к изображениям на секунду.

Для файлов «raw» (applicationb) H264 (.h264/.bin/.264) отдельные данные единичного блока (потоки данных заголовка sps/pps или данные кадрового кодирования) объединяются в последовательность блоков nal , с начальным кодом (00 00 01 XX) между ними, где XX - тип единичного блока. (Чтобы предотвратить самонаучные данные, чтобы иметь 00 00 01, это RBSP экранировано.) Таким образом, h264 frame parser может просто вырезать файл на маркеры начального кода. Они ищут последовательные пакеты, которые начинаются с 00 00 01 и включают и исключают следующее появление 00 00 01. Затем они анализируют нулевой тип устройства и заголовок среза, чтобы найти, к какому кадру принадлежит каждый пакет, и возвращают набор nal единицы, составляющие один кадр в качестве входных данных для h264 decoder.

Данные H264 в файлах .mp4 различны. Вы можете себе представить, что стартовый код 00 00 01 можно считать избыточным, если в формате мультиплексирования уже есть маркеры длины, как в случае с mp4. Таким образом, чтобы сохранить 3 байта на кадр, они удаляют префикс 00 00 01. Они также помещают PPS/SPS в заголовок файла, а не добавляют его перед первым кадром, а также пропускают префиксы 00 00 01. Итак, если бы я должен был ввести это в декодер h264, который ожидает префиксы для всех nal-блоков, это не сработает. Фильтр битовых потоков h264_mp4toannexb исправляет это, идентифицируя pps/sps в извлеченных частях заголовка файла (ffmpeg вызывает это «extradata»), добавляя это и каждый nal из отдельных пакетов кадров с помощью стартового кода и объединяя их вместе перед ввод их в декодер h264.

Теперь вы можете почувствовать, что существует очень тонкое различие между «парсером» и «битовым фильтром». Это правда. Я считаю, что официальное определение состоит в том, что парсер принимает последовательность входных данных и разбивает их в кадрах, не отбрасывая никаких данных или не добавляя никаких данных. Единственное, что делает парсер, это изменение границ пакетов. С другой стороны, фильтр битового потока позволяет фактически изменять данные. Я не уверен, что это определение полностью верно (см., Например, vp9 ниже), но это концептуальная причина. Mp4toannexb - это BSF, а не синтаксический анализатор (поскольку он добавляет префиксы 00 00 01).

Другие случаи, когда такие «битовый поток твики» помогают держать декодеры простым и однородным, но позволяют нам поддерживать все файлы варианты, которые происходят, существуют в дикой природе:

• mpeg4 (DIVX) b frame unpacking (чтобы получить B -фрагменты, такие как IBP, которые закодированы как IPB, в AVI и правильные временные метки, люди придумали эту концепцию упаковки B-кадров, где IBP/IPB упакованы в фреймах как I-(PB)-(), т. е. третий пакет пуст, а второй имеет два кадра. Это означает, что временная метка, связанная с кадрами P и B на фазе декодирования, является правильной.Это также означает, что у вас есть два фрейма для входных данных для одного пакета, что нарушает концепцию ffmpeg one-frame-in-one-frame-out, поэтому мы написали bsf, чтобы разбить пакет на две части вместе с удалением маркера, который говорит, что пакет содержит два кадра, следовательно, BSF, а не синтаксический анализатор, - прежде чем вводить его в декодер. На практике это решает в противном случае серьезные проблемы с многопоточным циклом. VP9 делает то же самое (называемое суперкадрами), но разбивает кадры в parser, поэтому разложение парсера/BSF не всегда теоретически идеально; может быть, VP9 должен быть назван BSF)
• HEVC mp4 для annexb преобразования (та же история, что и выше, но для HEVC)
• ААС adts to asc преобразования (это в основном так же, как h264/HEVC annexb против mp4, но для ААС аудио)