Что такое фильтры bitstream в ffmpeg?

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

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

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

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

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

• в формате MPEG4 (DivX и) B номер кадра распаковке (чтобы получить последовательности B-кадров, такие как IBP, которые кодируются как IPB, в AVI и получают правильные временные метки, люди придумали эту концепцию упаковки B-кадров, где I-B-P / I-P-B упакован в кадры как I-(PB) - (), т. е. третий пакет пуст, а второй имеет два кадра. Это означает, что временная метка, связанная с кадром P и B на этапе декодирования, является правильной. Это также означает, что у вас есть два кадра входных данных для одного пакета, что нарушает концепцию ffmpeg "один кадр в одном кадре", поэтому мы написали bsf, чтобы разделить пакет обратно на два-вместе с удалением маркера, который говорит, что пакет содержит два кадра, следовательно, BSF, а не парсер - прежде чем вводить его в декодер. На практике это решает в противном случае сложные проблемы с многопоточностью кадров. VP9 или делает то же самое (так называемый сверхциклов), но шпагат кадров в парсер, поэтому разбиение парсера/BSF не всегда теоретически идеально; возможно, VP9 следует назвать BSF)
• преобразование HEVC mp4 в annexb (та же история, что и выше, но для hevc)
• aac adts для asc преобразование (это в основном то же самое, что и H264/hevc annexb против mp4, но для aac аудио)