FFMPEG / libx264: как указать переменную частоту кадров, но с максимальной?

Вместо того, чтобы предоставлять фиксированную частоту кадров для FFMPEG / libx264 (-r / -framerate), я хотел бы указать переменную частоту кадров со значением MAXIMUM и позволить libx264 снизить частоту кадров, как она считает нужным. Идея здесь заключается в том, чтобы получить дополнительное сжатие, когда есть что-то вроде расширенного неподвижного кадра (что происходит МНОГО в моих исходных видео).

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

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

Ответом на это является странно названный -vsyncвариант. Вы можете установить несколько разных опций, но вам нужно выбрать «2» или vfr. Со страницы руководства:

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

• 0, сквозной

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

• 1, ср

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

• 2, VFR

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

• падение

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

• -1, авто

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

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

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

Однако у меня недостаточно репутации, чтобы оставить комментарий, чтобы просто ответить на этот «подвопрос», который, кажется, есть у каждого. Но у меня действительно было несколько идей, которые я не был по-настоящему оптимистичен в отношении ... Но первая, которую я попробовал, действительно сработала . Так.

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

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

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

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

Я хотел бы указать переменную частоту кадров со значением MAXIMUM и позволить libx264 снизить частоту кадров, как он считает нужным. Идея в том, чтобы получить дополнительное сжатие, когда есть что-то вроде расширенного кадра

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

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

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

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

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

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

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

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

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

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

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

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

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

- инструменты для прореживания avisynth

- переключатели fps и -r
- x264 General (tcfile, fps)
- стандарты файлов временного кода
- уровни и профили
- краткая и понятная сводка настроек CFR / VFR (раздел «частота кадров»)

doom9, videohelp, & c теоретические дискуссии
1 2 3 4 5 6 7