Вместо задания фиксированной частоты кадров для FFMPEG/libx264 (-r/-framerate), я хотел бы указать переменную частоту кадров с МАКСИМАЛЬНЫМ значением и разрешить libx264 снижать частоту кадров по мере необходимости. Идея заключается в том, чтобы получить дополнительное сжатие, когда происходят, например, длительные неподвижные кадры (что случается ОЧЕНЬ ЧАСТО в моих исходных видео).

Я понимаю, что предсказуемые или двунаправленные MPEG кадры будут сжиматься очень хорошо, но также возможно, что исходная частота кадров меньше той, в которую я собираюсь перекодировать (что потенциально может привести к БОЛЬШЕЙ трансляции!).

Разочарованный, что вы тоже не нашли ответа, я собирался хотя бы ответить на вопросы других людей о том, как включить VFR (не VBR) вывод из FFMPEG.

Ответ на это – странно названная опция -vsync. Вы можете установить её на несколько различных значений, но вам нужна ‘2’ или vfr. Из мануала:

-vsync параметр
Метод синхронизации видео. Для совместимости старые значения можно указывать как числа. Новые значения всегда должны указываться как строки.

• 0, passthrough

  • Каждый кадр передается с его временной меткой от демультиплексора к мультиплексору.

• 1, cfr

  • Кадры будут дублироваться и удаляться для достижения точно запрошенной постоянной частоты кадров.

• 2, vfr

  • Кадры передаются вместе с их временной меткой или удаляются, чтобы предотвратить появление двух кадров с одной и той же временной меткой.

• drop

  • Как passthrough, но уничтожает все временные метки, заставляя мультиплексор генерировать новые временные метки на основе частоты кадров.

• -1, auto

  • Выбирает между 1 и 2 в зависимости от возможностей мультиплексора. Это метод по умолчанию.

Обратите внимание, что временные метки могут быть дополнительно изменены мультиплексором после этого. Например, в случае, если включена опция формата avoid_negative_ts.

С помощью -map вы можете выбрать, из какого потока должны быть взяты временные метки. Вы можете оставить либо видео, либо аудио без изменений и синхронизировать оставшиеся поток(и) с неизмененным.

Однако у меня недостаточно репутации, чтобы просто ответить на этот ‘подвопрос’, который, кажется, всех интересует. Но у меня было несколько идей, в которые я, честно говоря, не очень верил… Но та, которую я попробовал первой, действительно сработала. Итак.

Вам просто нужно скомбинировать опцию -vsync 2 с опцией -r $maxfps, конечно, заменяя $maxfps на максимальную частоту кадров, которую вы хотите! И это РАБОТАЕТ! Он не дублирует кадры из исходного файла, но удаляет кадры, которые заставляют файл превышать максимальную частоту кадров!

По умолчанию кажется, что -r $maxfps сам по себе просто вызывает дублирование/удаление кадров для достижения постоянной частоты кадров, а -vsync 2 сам по себе вызывает прямую передачу кадров без значительного воздействия на значения PTS.

Я не был уверен в этом потому, что я уже знал, что -r $maxfps приводит к постоянной частоте кадров. Я честно ожидал ошибки или, что он просто будет подчиняться тому, что указано первым или последним, или еще чему-то. Тот факт, что он делает именно то, что я хотел, вызывает у меня удовлетворение от разработчиков FFMPEG.

Я надеюсь, что это поможет вам или кому-то другому в будущем, если вам больше не нужно это знать.

Я хотел бы указать переменную частоту кадров с МАКСИМАЛЬНЫМ значением и разрешить libx264 снижать частоту кадров по мере необходимости. Идея заключается в том, чтобы получить дополнительное сжатие, когда происходят, например, длительные неподвижные кадры

На мой взгляд, это может быть возможно достаточно неуклюжим способом, но нежелательно по некоторым сложным и противоречивым причинам

Хотя поток x264 имеет частоту кадров, частота кадров более является проблемой на уровне контейнера, чем кодека.

В кодировании с встраиванием VFR будет, по сути, текстовый файл, детализирующий, какая частота кадров происходит на каких кадрах/временах, и при кодировании источника функция типа tcfile-in или tcfile-out передает временные метки через кодировку, чтобы сопоставить расположение частот и сохранить видео субъективно последовательным от источника.

Идея о низкой частоте кадров логична, но не работает по нескольким причинам. Хотя x264 учитывает VFR с некоторыми возможностями, я не думаю, что существует функция анализа, которая будет варьировать частоту кадров с учетом движения для уменьшения размера файла (аналогично многим методам управления битрейтом).

Источником также является проблема: VFR источники по умолчанию сохранят свою изменчивость кадров, но, видимо, кодирование файла CFR с переменной битрейтом (хорошо иногда, особенно когда нужно делать телесинхронизацию) просто приведет к тому же CFR.

Это значит, что вы, вероятно, должны будете переписывать битрейт вручную (т.е. временные метки медленных сцен, вмещенные в файл), или прибегнуть к алгоритму редукции кадров, как dup, dedup и exactDedup для avisynth. Если ваше видео имеет крайне низкое движение, некоторые кадры (даже половина?) будут выкинуты. Проблема в том, что эти алгоритмы не продвинуты, и не делают хороших выборов с “живыми” кадрами по поводу того, что будет способствовать лучшему кодированию.

Кроме того, удаление кадров, содержащих такие элементы, как I и B кадры, снижает количество деталей, доступных со временем, что делает движение выглядящим “ступенчатым” и может нарушить другие базовые параметры видео и вызвать такие артефакты, как алиасинг.

И из-за того, как работают квантизаторы, x264 на самом деле уменьшит битрейт непропорционально в этих сценах с низким движением. Если только у вас нет слайд-шоу с идентичными изображениями, будет движение (даже зерно и другие артефакты), и будет потеря качества, которая не была бы видна без внезапных изменений в битрейте.

И, наконец, причина, по которой нет множества опций для достижения того, чего вы хотите, заключается в том, что x264 действительно хорошо управляет битрейтом просто используя временное сжатие (запись изменений в частичных кадрах). Например, уменьшение частоты кадров наполовину не сократит размер файла в два раза; 10% – это, вероятно, реалистичная выгода, которую можно ожидать от низкого движения или анимации.

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

Если вы все же хотите попробовать редуктор, возможно, вы сможете ограничить максимальную новую частоту кадров, используя опции уровней, каждая из которых указывает максимальное разрешение и частоту кадров. К сожалению, вам, вероятно, придется работать с очень низкими разрешениями, чтобы получить тот вид частот кадров, который вы хотите, используя профили. Это сводится к ручному редактированию частот, либо полностью, либо для исправления частот, которые вы считаете слишком высокими. В любом случае, потребуется манипуляции для поддержания синхронизации звука с новыми частотами, если изменения вносятся после процесса кодирования, когда сохраняется tcfile.

Вывод в том, что потраченное время на оптимизацию множества настроек битрейта даст гораздо больше в плане управления размером файла и повысит качество вашего видео, чем приведет к сложностям с небольшой выгоду. Сохранение оригинальной частоты кадров, вероятно, является лучшей идеей, если вы не нацеливаетесь на радиовещательные или медийные стандарты. Плееры хорошо спроектированы для обработки изменяющихся битрейтов (в отличие от NLE) — и чем больше кадров в вашем видео, тем плавнее будет воспроизведение, и, возможно, размер файла будет меньше из-за меньших изменений в движении между кадрами.

Вот подборка ссылок на информацию о стандартах и обсуждениях на форумах, которые должны помочь разобраться с этим запутанным аспектом кодирования:

–инструменты декимирования для avisynth

–переключатели fps и -r
–x264 Общее (tcfile, fps)
–стандарты файлов временных кодов
–Уровни и профили
–Краткий, четкий обзор настроек CFR/VFR (“раздел “частота кадров”)

doom9, videohelp и теоретические обсуждения &св прочие
1
2
3
4
5
6
7

Идеальное решение: Уменьшить повторяющиеся очень похожие кадры и сохранить вывод при (пиковом) переменном темпе кадров

• Для контента с длинными статичными сценами уменьшение дублирующихся кадров может динамически и значительно снизить частоту кадров, чтобы добиться большего уменьшения размера файла, чем это может когда-либо достигнуть кодек и его внутрикодековое сжатие!
• В моем примере:
  • 100% оригинального размера файла меццанина при 60 FPS
  • 15% CR28 при 60 FPS с постоянной частотой кадров
  • 6% CR28 при 60 FPS с пиковой частотой кадров (почти в 3 раза!)

Оригинал доступен

ffmpeg -i screen-recording.mov -movflags faststart -c:v libx264 -vf mpdecimate -vsync vfr -r 120 -preset veryslow -crf 24 screen-recording-vfr.mp4

Перекодировать уже сжатое видео в динамическую частоту кадров без повторного кодирования

ffmpeg -i video-export-old.mp4 -vf mpdecimate -vsync vfr video-export-mpdecimated-without-reencoding.mp4

Подробно

Оригинал доступен

ffmpeg -i screen-recording.mov -movflags faststart -c:v libx264 -vf mpdecimate -vsync vfr -r 120 -preset veryslow -crf 24 "screen-recording-vfr.mp4"

-i video-mezzanine.mov   Оригинал или ваш высококачественный рендер экспорт в качестве входного файла.
-movflags faststart      Готовность для потоковой передачи, помещая атом moov в начало файла.
-c:v libx264             H-264 кодек
-vf mpdecimate           Удаляет кадры, которые не сильно отличаются от предыдущего кадра, чтобы уменьшить частоту кадров.
-vsync vfr               Вывод в виде переменной частоты кадров (vfr)! Необходимая сестринская опция к 'mpdecimate'.
                         - Для поддержания скорости воспроизведения и получения уменьшения размера файла.
-r 30                    Если вы укажете -r, то в этой комбинации это будет служить как пиковая частота кадров!
                         Рекомендуется не указывать эту опцию:
                         - Тогда пиковая частота кадров БУДЕТ пиковым/постоянным темпом источника.
                         - Что полностью сохраняет динамические сцены и сжимает длинные статические последовательности.
                         - Таким образом, лучшее из обоих аспектов.
                         - Укажите пиковую частоту кадров, если потеря FPS в динамичных сценах
                           приемлема для уменьшения размера файла.
-crf 24                  - Константный фактор битрейта (постоянное качество при переменной битрейте)
-preset veryslow         - Вложенное качество в кодирование
screen-recording-vfr.mp4 - Выходной файл

Конвертировать уже экспортированное видео в динамическую частоту кадров без повторного кодирования

ffmpeg -i video-export-old.mp4 -vf mpdecimate -vsync vfr video-export-mpdecimated.mp4

• Это операция без потерь. Нет перекодирования с потерей, только перепаковка/перессылка.

• Он удалит столько дублированных кадров, сколько сможет!

Пример:

• Слайд-шоу из всего 3 статических изображений, без переходов * каждое длится 5 секунд * при 50 FPS = 750 кадров

• ffmpeg действительно уменьшит его лишь до 3 кадров с 1/5 (=0,2) FPS! Подтверждено с помощью mediainfo!

Анализ и Обучение

• Видео с длинными сценами со статическими изображениями могут значительно уменьшить количество кадров и размер файла!
• Для обоих сценариев
  • Кодирование из меццанинового файла с тем же CFR сохраняет визуальное качество
    • Но уменьшение размера файла от постоянной до переменной частоты кадров составляет 15% до 6%.
  • Уменьшение частоты кадров без повторного кодирования приводит к меньшему уменьшению размера файла, но все же:
    • Приводит к уменьшению размера файла (15% до 10%)

screen-recording.mov
- Режим частоты кадров: Переменная
- Частота кадров: 58,628 FPS
- Минимальная частота кадров: 30,000 FPS
- Максимальная частота кадров: 60,000 FPS
- Количество кадров: 732                100 %
- Размер: 1675084 байтов              100 %

screen-recording CR24 fps 60.mp4
- Режим частоты кадров: Постоянная
- Частота кадров: 60,000 FPS
- Количество кадров: 750                102 %
- Размер: 255863 байтов                15 %

screen-recording CR24 mpdecimated vfr.mp4
- Режим частоты кадров: Переменная
- Частота кадров: 17,398 FPS
- Минимальная частота кадров: 1,132 FPS
- Максимальная частота кадров: 60,000 FPS
- Количество кадров: 214                 29 %
- Размер: 101860 байтов                6 %

screen-recording CR24 mpdecimated fps 30 max.mp4
- Режим частоты кадров: Переменная
- Частота кадров: 11,078 FPS
- Минимальная частота кадров: 1,154 FPS
- Максимальная частота кадров: 30,000 FPS
- Количество кадров: 137                 17 %
- Размер: 94382 байтов                5,6

screen-recording CR24 mpdecimated vfr без повторного кодирования faststart.mp4
- Режим частоты кадров: Переменная
- Частота кадров: 19,974 FPS
- Минимальная частота кадров: 1,132 FPS
- Максимальная частота кадров: 60,000 FPS  
- Количество кадров: 247                 33 % 
- Размер: 165 KB (164947 байтов)      10 %

Правильный способ управления максимальной частотой кадров с помощью VRF – использовать фильтр постобработки -vf "fps=60" вместо -r/-fpsmax.

Например:

ffmpeg -i input.mp4 -c:v libx264 -crf 20 -preset fast -vsync vfr -vf "fps=60" output.mp4

Комбинация VRF и -r или -fpsmax была ошибочной, так как -r/-fpsmax предназначен для управления частотой кадров для CRF, а не для VRF. Даже если ffmpeg в какое-то время (v5 и старше) позволял это, и он работал – это не был правильный способ использования этой комбинации флагов. Эта комбинация больше не разрешена (ffmpeg v6+), и комбинация VRF и -r/-fpsmax приведет к сообщению об ошибке:

Один из -r/-fpsmax был указан вместе с не-CFR -vsync/-fps_mode. Это противоречиво.