AviSynth, видео с переменной частотой кадров (vfr) и гибридное видео
Содержание
Видео с переменной частотой кадров и гибридное видео
Как распознать VFR-материал (mkv/mp4)
Существует несколько способов определить, что видео в контейнерах mkv/mp4 является VFR:
для mkv: изучить файл с таймкодами кадров, полученный с помощью mkv2vfr.
для mp4: используя mp4dump (брать здесь: MPEG4 tools by MPEG4ip package). В командной строке наберите
Полученный лог-файл выглядит так (найдите атом stts, содержащий продолжительности кадров):
Значения эти, разумеется, не в секундах, это некие «тики» (или отсчеты), которые можно перевести в секунды, используя значение «timescale», хранящееся в атоме timescale видеодорожки (убедитесь, что вы выбрали нужный timescale, так как у каждой дорожки он свой собственный). В лог-файле это выглядит так:
Приведенные логи взяты из реального гибридного видео-файла.
Загрузка гибридного видео (MPEG-2) в AviSynth и его кодирование
Если выбрать частоту кадров 29.97, то NTSC-фрагменты будут играться отлично, но FILM-фрагменты будут подергиваться при воспроизведении из-за дублирования части кадров. И аналогично, при выборе FILM (23.976), получим корректное воспроизведение FILM-фрагментов и подергивание NTSC-фрагментов (уже из-за «выброшенных» в результате прореживания кадров). Помимо этого, при выборе 29.97 мы получим худшее качество картинки при том же финальном размере файла, т.к. количество кадров увеличится на 25%.
Плагин Decomb для AviSynth предоставляет два специальных режима прореживания для наилучшей обработки гибридного материала. Чтобы понять, как использовать Decomb, процитируем его документацию:
Преимущественно FILM-материал (mode=3)
Для начала рассмотрим случай, когда исходный материал преимущественно FILM-формата. В этом случае мы хотим проредить FILM-фрагменты обычным образом, сохранив плавность воспроизведения. Для NTSC-фрагментов частоту кадров будем уменьшать «смешивающим» (blending) прореживанием, получая из каждых 5 кадров 4. Полученные последовательности кадров будут воспроизводиться плавнее, чем если бы мы просто прореживали их как FILM-фрагменты.
Типовой скрипт для такой операции:
Decimate обрабатывает FILM- и не-FILM фрагменты соответствующим образом благодаря двум факторам. Первый: когда мы используем параметр guide=1 в вызове Telecide, мы тем самым разрешаем ему передавать информацию в Decimate о том, какие кадры получены из FILM-фрагментов, а какие нет. Чтобы этот механизм работал, вызов Decimate должен следовать непосредственно после Telecide. Очевидно, что чем лучше (путем подстройки параметров) Telecide сможет распознать шаблоны, с помощью которых поля составлены в кадры, тем лучше справится со своей задачей Decimate.
Есть еще один плагин для «обратного телесина» (IVTC, Inverse Telecine), специально предназначенный для обработки гибридного материала, но без смешивания кадров, как у Decomb в режиме mode=3. Это SmartDecimate. Полученные в результате кадры будут «чистые», но при воспроизведении не будет такой плавности, как при использовании Decomb. Типичный скрипт таков:
Чтобы по возможности сохранить плавность, перед SmartDecimate выполняется деинтерлейс каким-либо «умным» BOB-алгоритмом.
Преимущественно NTSC-видео материал (mode=1)
Теперь рассмотрим случай, когда материал преимущественно в NTSC-формате. Тут надо избежать прореживания кадров для NTSC-фрагментов, чтобы сохранить плавность воспроизведения. Для FILM-фрагментов же надо сохранить частоту кадров = 29.97, но заменить дублирующиеся кадры на кадры, в которых поля смешаны, чтобы дубликаты были не столь заметны.
Типовой скрипт для такой операции:
Рекомендации абсолютно те же, что и для режима mode=3 (см. выше)
кодирование как 120 fps, используя AVI с «выброшенными» кадрами
Это наиболее широко совместимый способ. Для этого вам необходимы TIVTC and avi_tc. Начните с создания a прореженного avi и timecodes.txt, но пропустите мультиплексирование. Затем откройте закладку tc2cfr программы tc-gui и добавьте ваши файлы или используйте следующую командную строку:
Затем муьтиплексируйте с вашим аудио. Это работает так как tc2cfr создает avi с выброшенными (drop) кадрами, заполняя избыточное пространство выброшенными кадрами для создания плавного avi с частотой 120 кадров в секунду.
Есть также старый способ кодирования в 120 fps
Потребуются следующие утилиты
Вся процедура отлично описана здесь. Там же можно скачать и все необходимые утилиты. Но так как процесс можно несколько упростить, мы опишем его тут:
1) Создать индексный файл (idx):
Кладем DVD2AVI 1.76, MPEG2DEC.dll и FPSChk.exe в одну директорию, иначе работать не будет. Запускаем FPSChk.exe. К сожалению, эта утилита на японском языке, но последовательность действий такая: жмем ALT+F, потом O, чтобы открыть файл. Открываем наш D2V-файл. Далее жмем ALT+A, потом S, чтобы просканировать файл и найти в нем FILM- и NTSC-фрагменты. В статусной строке побегут счетчики, так что наберемся терпения и подождем. По окончании сканирования жмем ALT+F и затем W, чтобы сохранить индексный файл.
2) Кодируем как 30 кадров/сек с помощью dec60.dll:
Здесь можно использовать AviSynth v2.5 (но вам потребуется mpeg2dec.dll и dvd2avi 1.76, стало быть потребуется LoadPluginEx.dll, чтобы загрузить плагины от AviSynth версии v2.0x). Создайте следующий скрипт:
Загрузите скрипт в VirtualDub и закодируйте в DivX/XviD как обычно.
3) Конвертируем полученный AVI с 29.97 кадров/сек в 119.88 кадров/сек:
Запустите AVI60GUI.exe. В нем три поля для ввода. В верхнее вводим имя файла, полученного на предыдущем этапе. Второе поле вводим имя файла, в котором будем сохранять модифицированный AVI-файл. В нижнее поле вводим имя IDX-файла. После заполнения всех трех полей жмем Enter и ждем. По окончании работы получаем плавно воспроизводящийя файл со 120 кадрами в секунду. Теперь самое время смикшировать его со звуковой дорожкой.
создание VFR-видео в контейнере MKV (matroska/матрёшка)
Возьмите модифицированный плагин Decomb под названием Decomb521VFR, который умеет сохранять файлы с таймкодами и статистикой, по которым можно определить, какие кадры с какой частотой вопросизводятся. Сделайте следующий скрипт:
(Для создания файла с таймкодами можно также воспользоваться TDecimate из пакета TIVTC от tritical).
Откройте скрипт в VirtualDub-е и запустите на проигрывание. Будут созданы файлы с таймкодами и статистикой. Теперь удалите вызов Decomb521 из скрипта, останется только:
этот скрипт закодируйте в DivX/XviD (как 29.97 кадров в сек).
Запустите mmg.exe, который является графической оболочкой для mkvmerge: откройте в нем свои видео и аудио файлы (если необходимо, укажите задержку для звука), файл с таймкодами timecodes.txt и запустите микширование.
создание VFR-видео в контейнере MP4
подведем итоги по методам
Суммируя все недостатки и достоинства вышеперечисленных методов, можно сказать следующее: создание видео с фиксированной частотой кадров 23.976 или 29.97 удобно, если требуется дальнейшее редактирование в AviSynth, VirtualDub и др., т.к. многие редакторы работают только с CFR-материалом. Но такое видео может воспроизводиться с подергиваниями из-за дублирующихся или выброшенных кадров. Кодирование со 120 кадрами/сек опять же дает нам CFR, но зато отсутствие подергиваний при просмотре. Однако, его создание требует некоторых усилий, да и некоторые из применяемых программ имеют закрытые исходные тексты. Кодирование в MKV с переменной частотой кадров (используя таймкоды) не имеет недостатков (за исключением того, что файлы MKV не воспроизводятся бытовыми плеерами).
Создание VFR-видео в контейнере MP4 с N-VOP-ами
Загрузка гибридного видео (не MPEG-2) в AviSynth и его кодирование
загрузка не-AVI VFR-материала в AviSynth
В зависимости от продолжительности исходных кадров будет производиться добавление или выкидывание кадров чтобы сохранить синхронизацию.
Перекодирование с частотой кадров 23.976 или 29.97:
(Я не знаю, что в теории даст лучший результат). Для MP4 это тоже работает.
перекодирование 120 fps VFR-видео
TIVTC также может дедать это:
Как только вы закодировали ваш файл, мультиплексируйте обратно в mkv или 120 fps avi.
Это будет убирать все дублированные кадры вставленнные directshowsource, в то же время удерживая количество кадров и времена почти идентичными. Но не используйте файл временных кодов от входного видео, используйте новый. Они могут быть не идентичными. (Конечно вы пожете поиграться с параметрами если хотите использовать большую функциональность dedup.)
Есть также другие более старые способы
Нижеприведенная методика основана на описании, данном HeadlessCow в этой ветке форума.
0) Берем vfrtools, инсталлируем Java VM.
1) Берем фильтр MultiDecimate и создаем AVS-скрипт для файла, который будем кодировать. Убедитесь, что все ненужные кадры обрезаны ДО вызова MultiDecimate в скрипте. В итоге должен получиться скрипт, похожий на этот (никакие фильтры обработки видео здесь пока не нужны):
2) Теперь загружаем скрипт в VirtualDub и запускаем его проигрывание (один раз, при этом никакие перемещения по тайм-лайну делать НЕЛЬЗЯ! Открыли скрипт и сразу запустили), затем закрываем VirtualDub. Теперь у нас есть файл mfile.txt в той же директории, где и AVS-скрипт. Выглядит он так:
Каждая строка содержит номер кадра и степень его отличия от предыдущего кадра.
3) Сейчас потребуется vfrtools.jar. Но сначала убедитесь, что у вас установлена Java VM. Из командной строки запускаем vfrtools.jar с двумя аргументами: файлом mfile.txt и исходной частотой кадров, вероятно = 119.88 (поместите vfrtools.jar в ту же директорию, что и ваш AviSynth-скрипт и mfile.txt).
В первой строке значения смысла не имеют, за исключением числа кадров. Первые три значения просто выбраны так, чтобы быть «безопасными» (в смысле, что с ними ничего не рушится, не виснет и не глючит).
Предполагаемая частота кадров выставлена равной исходной, это ничего. Все кадры разделены на интервалы, для каждого из которых установлена своя частота кадров.
4) Измените режим работы MultiDecimate на «второй проход» (pass=2) и закодируйте видео. Ваш AVS-скрипт должен выглядеть примерно так (теперь в конец скрипта можно добавить любые другие фильтры, которые потребуются).
Результат будет иметь несуразную чатсоту кадров, но это не важно, мы это исправим во время соединения видео и звука.
Запустите mmg.exe, являющийся оболочкой mkvmerge: загрузите видео и звуковый файлы (при необходимости установите задержку для звука), загрузите файл timecodes.txt. После этого запускайте микширование.
Для воспроизведения полученного файла потребуется Matroska splitter, который можно скачать здесь (от Gabest-а) или здесь (от Haali).
(Можно вместо MultiDecimate попробовать DeDup. Вроде бы он и для YV12 подходит).
Пребразование vfr в cfr avi для AviSynth
Вы можете избежать анализирования и прореживания с использванием специальных средств, чтобы получить минимальное cfr avi для подачи в avisynth. После обработки и пере-кодировки, примените tc2cfr или mmg к выходу с оригинальными временными кодами чтобы восстановить vfr и полную синхронизацию. (До тех пор, пока вы не удаляете/добавляете кадры, вы можете использовать все тот же файл с таймкодами. Если кол-во кадров изменилось, то прийдется править файл с таймкодами ручками, хотя dedup имеет параметр timesin.)
avi_tc будет создавать временной код и нормальное видео, если avi использует выброшенные кадры и не n-vops или полностью закодированные кадры. Она также требует, чабы не присутствовало аудио или вторая дорожка. Чтобы использовать, откройте tc-gui и добавьте ваш файл, или используйте следующую командную строку:
кодирование VFR-видео в MPEG-2
Пока нет никаких комментариев по этому поводу.
Синхронизация со звуком
После рассмотрения всех методов кодирования гибридного видео (как 23.976, 29.97 или VFR) возникает вопрос: почему независимо от выбранного метода звук все равно остается синхронизированным с видео? До кодирования видео и звук имеют равную продолжительность и синхронизированы. Во время кодирования возможны два варианта:
И, наконец, предположим, что вы открываете свое VFR-видео в AVISynth с помощью DirectShowSource. Сравним:
Ссылки
Для обязательного прочтения: Force Film, IVTC, and Deinterlacing and more.
Создание видео со 120 кадрами/сек.
Документация к Decomb521VFR.
Про модификацию Decomb521VFR1.0 для автоматизации создания Matroska VFR.
Mkvextract GUI от DarkDudae.
Помимо всех тех людей, которые участвовали в создании инструментов, упомянутых в этом руководстве, автор (Wilbert) хотел бы поблагодарить bond, manono, tritical and foxyshadis за ценные замечания и предложения.
Монтаж видео с разными частотами кадров в Adobe Premiere
Иногда приходится производить монтаж видео с разными частотами кадров в одном проекте. Конечно по умолчанию Adobe Premiere сам подгоняет этот параметр, но делает это не достаточно качественно. Он просто выкидывает при уменьшении частоты лишние кадры или добавляет одинаковые при увеличении. В результате получается дёрганное изображение. Более же качественно подогнать частоты кадров можно, используя плагин Twixtor.
Итак, допустим, у нас есть основная секвенция с 24 кадрами в секунду (а точнее 23,976), где первым идет видео кусок с теми же настройками. Далее в неё мы добавляем кусок с 30 кадрами в секунду. И нам нужно его правильно конвертировать.
Начнём с того, что сделаем копию этого клипа в окне со списком использованных в нашем проекте файлов, нажимая на него правой кнопкой мыши и выбирая “Duplicate”. Это нужно для того, чтобы сохранить звуковую дорожку. Потому как при дальнейшем изменении нашего клипа с 30 кадрами в секунду его оригинальный звук исказится.
Теперь давайте перенесём эту копию на таймлинию над нашим оригинальным куском, чтоб звуковая дорожка копии оказалась ниже. Теперь нам надо разделить звук и изображение обоих кусков. Для этого нажимаем правой кнопкой мыши на этих клипах и выбираем “Unlink”.
Далее удаляем видео дорожку у копии, а у оригинала звуковую.
Теперь можно редактировать клип, но не забывайте резать и звуковую дорожку в том же месте. После редактирования переходим непосредственно к изменению частоты кадров.
И для начала в окне со списком использованных в нашем проекте файлов нажимаем правой кнопкой мыши на оригинальном файле с 30 кадрами в секунду, выбираем “Modify” – “Interpret Footage…”
В открывшемся окне отмечаем точкой пункт “Assume this frame rate” и вписываем туда нашу основную частоту кадров. (в моём случае 23,976, но программа округляет до 23,98) После нажатия на кнопку “ОК” наш видео кусок немного замедлится. Если же вы наоборот переводите из меньшего количества кадров в большее, то он убыстрится. Вот тут то нам и понадобится плагин Twixtor, который очень качественно умеет замедлять или убыстрять видео без потери промежуточных кадров.
Но сначала нужно создать из нашего куска встроенную секвенцию (Nested Sequence). Для этого нажимаем правой кнопкой мыши на клипе и выбираем “Nest”.
Теперь к этой секвенции применяем плагин Twixtor, перетащив его из браузера эффектов.
Теперь нам нужно перейти в нашу встроенную секвенцию. Для этого кликаем два раза левой кнопкой мыши на ней. Тут нужно увеличить длину клипа, иначе Twixtor не сможет просчитать клип до конца.
Если же вы наоборот увеличивали частоту кадров. То есть переводили, например из 24 кадров в секунду в 30. Тогда вам нужно будет продублировать клип в секвенции. Это опять же связанно с алгоритмами работы плагина.
На этом можно было бы закончит, но в конец куска Twixtor почему-то добавляет темноту, перекрывая концовку. Поэтому приходится добавлять длину встроенной секвенции. Что сбивает всю нарезку клипа.
Поэтому советую сначала добавлять в стык, выше на дорожку, следующий клип.
А затем увеличить длину встроенной секвенции, убрав тем самым эту темноту в конце куска.
Пережатие видео с переменной частотой кадров
Есть много видео с коммуникатора в mp4-контейнере с AVC-сжатием. Проблема в том, что сжатие слабого уровня и с переменным FPS. Если пережимать в статический FPS, даже в 60, то теряется плавность просмотра. Особенно с интерполяцией промежуточных кадров (она тупо перестаёт работать после такого пережатия).
Можно ли как-то пережать (ffmpeg/mencoder/vlc/etc), сохранив частоту кадров, т.е. фактически только перекомпрессировать кадры в видеоряду не меняя их тайминг?
Спасибо, похоже, то, что нужно.
Блин, всё равно подёргивается. Не так сильно, как с постоянным фреймрейтом, но всё равно не годится :-/
Буду играть с параметрами.
Может другие ключи все портят. Попробуй самый простой вариант для проверки:
Попробуй самый простой вариант для проверки
Да у меня итак без наворотов:
Исходный файл снят при посредственном освещении, поэтому fps местами падает аж до 4. В среднем, наверное, 16-20, длинные куски с 10-15 (на глазок).
Когда играешь этот mp4 с умножением частоты через SVP (интерполируются дополнительные промежуточные кадры), длинные куски с 10-15 fps выглядят плавными, на 30+ fps. Только движущиеся по фону объекты (люди) чуть чёткость теряют по краю (что понятно).
Если смотреть оригинал и перекодированный файл без умножения кадров, то выглядят на глаз одинаково. Дёргано.
Если смотреть с умножением перекодированный файл, то он выглядит плавнее, чем без умножения, но хуже оригинала. В некоторых местах начинает на секунду дёргаться как без перекодирования.
А разве по умолчанию добавляются какие-то кадры или как-то странно преобразуются таймштампы? Не думаю. Можешь скинуть оригинал?
Если смотреть оригинал и перекодированный файл без умножения кадров, то выглядят на глаз одинаково. Дёргано.
Ну так на что тогда пеняешь?
Когда играешь этот mp4 с умножением частоты через SVP (интерполируются дополнительные промежуточные кадры), длинные куски с 10-15 fps выглядят плавными, на 30+ fps. Только движущиеся по фону объекты (люди) чуть чёткость теряют по краю (что понятно).
Что такое SVP? Через какую софтину, реализующую эту фичу, ты просматриваешь?
Не вопрос. Вот, небольшой (53Мб неперекодированных) с характерными проблемами в начале воспроизведения:
Только у тебя есть винда и SVP, чтобы оценить «плавный» вариант? Если смотреть в родном низком fps, то разницы с оригиналом и перекодированным вариантом нет.
10fps без интерполяции — ужасно 🙂
Это фильтр, который в реалтайме достраивает промежуточные кадры для видеоряда, повышая эффективный FPS. Т.е. на мониторе с 60Гц развёрткой смотришь [почти] честные 60 кадров в секунду, а не 24-30 с многократным (2-3 раза) показом одного и того же кадра. Разница в восприятии огромная. Особенно при скроллинге. Вместо дёргающегося фона — реально плавное движение. Это как на ТВ с умножением частот, только там часто до 100-120Гц умножают (хотя между 60 и 120Гц я разницы уже не вижу).
Через какую софтину, реализующую эту фичу, ты просматриваешь?
Текущая стабильная версия работает только под Windows, зато — в любом DirectX проигрывателе. 4-ю версию пилят и под Linux, но я пока не в курсе текущих успехов.
Это фильтр, который в реалтайме достраивает промежуточные кадры для видеоряда
Ну так это морфинг по сути. Это умный фильтр, ffmpeg простым перекодированием такого, разумеется, не даст.
Это умный фильтр, ffmpeg простым перекодированием такого, разумеется, не даст.
Я от него этого и не хочу 🙂 Я просто хочу, чтобы в результате перекодирования все итоговые кадры были по тем же временнЫм интервалам, что в оригинале. Чтобы при воспроизведении умный фильтр достроил по ним недостающее также, как в оригинале.
Но по факту не получается. Поскольку похоже, что сбивается генерация промежуточных кадров, я могу предположить, что ffmpeg что-то в исходном порядке кадров нарушает. Или сдвигает по времени или, что вероятнее, где-то вставляет лишние кадры.
Я просто хочу, чтобы в результате перекодирования все итоговые кадры были по тем же временнЫм интервалам, что в оригинале.
Я по своему опыту полагаю, что так и происходит. Да и ты говоришь, что при обыкновенном проигрывании что оригинал, что перекодированный файл смотрятся неотличимо.
Или предоставь подтверждение своей правоты с числами в руках.
Посмотри ещё на опции copyts, copytb.
Если смотреть в родном низком fps, то разницы с оригиналом и перекодированным вариантом нет.
Так может дело тогда в SVP? А от контейнера не может зависеть?
Я по своему опыту полагаю, что так и происходит
В этом случае не было бы проблемы с интерполяцией, как её нет для оригинального видел.
Да и ты говоришь, что при обыкновенном проигрывании что оригинал, что перекодированный файл смотрятся неотличимо.
Или предоставь подтверждение своей правоты с числами в руках.
Как в преобразовании видеоряда в последовательность изображений в имени изображения указать точный (до миллисекунд) таймстамп?
Посмотри ещё на опции copyts, copytb
copyts смотрел, эффекта нет. copytb не знаю, посмотрю.
Телевизор (тоже с интерполяцией, только до 120Гц) тоже дёргается на перекодированном.
А от контейнера не может зависеть?
Если взять первые две секунды выложенного выше видео, пропустив первые пол-секунды совсем уже отвратительного оригинала, то выходит так:
— Оригинал: изображение дёргается скачками раз 10 в секунду. Полная смена кадра, дёргается сам бэкграунд.
— После интерполяции из исходного mp4 мужик в кепке скроллируется идеально плавно, только в моменты рывков оригинала в конце перемещения влево слегка размазывается. Фон движется абсолютно плавно и даже без размытия.
5 штук) резких (пусть и сглаженных) смещений наблюдается два ускоренных сдвига, которые уже даже «рывком» особо не назвать. Скорее более заметная, чем в оригинале, неравномерность скроллинга.
И ещё забавный момент. В метаданных нет (или я не знаю, как посмотреть) числа кадров в оригинале. Но средний FPS пишется как 18.679. Длительность:
В общем, получается
ffmpeg при конвертации ведёт отсчёт до frame=673.
Если с этой опцией, то оригинал выдаёт 673 кадра.
Конвертированное видео выдаёт два кадра и обламывается с ошибкой
Блин, с mencoder фигня, он в постоянный fps перегнал:
При чём перегнал криво, полная рассинхронизация со звуком. Похоже, исходный видеоряд просто расставил по новым таймстампам, почему плавность и сохранилась. При этом полностью накрылся тайминг.
В общем, сейчас интересно, почему ffmpeg не может им же созданный результат разложить на картинки с сохранением числа кадров 🙂
Попробовал бы и в mp4 сохранить, но ffmpeg умеет его только декодировать
Неправда, всё он умеет!
Что интересно, характеристики исходного mp4:
Параметры mp4 после перекодирования:
Уже по длительности и минимальному/среднему/максимальному fps видно, что с кадрами и таймингами не получается 1:1.
Что на входе, что на выходе 673 кадра. Ругается, правда, но выглядит, вроде, похожим на оригинал.
Хм. У меня в man вообще нет параметра crf 🙂 И параметры кадров совсем уехали:
Но визуально, вроде, нормально смотрится. Всё ещё хуже оригинала, но уже, если заранее не знать, на что смотреть, то можно не заметить разницу. Звук синхронизирован.
А вот mkv с этими же параметрами выглядит отвратительно.
crf — это вместо битрейта, параметр качества. От 51, вроде, — самое ужасное качество, до 0 — максимальное качество или даже лосслесс, если стоит ‘-preset ultrafast’.
