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

Question 1

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

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

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

0, сквозной

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

1, см.

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

2, ПВП

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

уронить

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

-1, авто

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

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

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

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

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

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

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

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

Answer

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

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

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

0, сквозной

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

1, см.

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

2, ПВП

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

уронить

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

-1, авто

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

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

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

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

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

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

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

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

Question 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-инструменты децимации avisynth

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

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

Answer