Пережатие видео с переменной частотой кадров

Да.

Математик в треде.

Для ffmpeg попробуй -vsync vrf или -vsync passthrough, я второй вариант юзаю.

-vsync parameter
    Video sync method.  For compatibility reasons old values can be specified as numbers.  Newly added values will have to be specified as strings
    always.

    0, passthrough
        Each frame is passed with its timestamp from the demuxer to the muxer.

    1, cfr
        Frames will be duplicated and dropped to achieve exactly the requested constant frame rate.

    2, vfr
        Frames are passed through with their timestamp or dropped so as to prevent 2 frames from having the same timestamp.

    drop
        As passthrough but destroys all timestamps, making the muxer generate fresh timestamps based on frame-rate.

    -1, auto
        Chooses between 1 and 2 depending on muxer capabilities. This is the default method.

-vsync passthrough

Спасибо, похоже, то, что нужно.

Блин, всё равно подёргивается. Не так сильно, как с постоянным фреймрейтом, но всё равно не годится :-/

Буду играть с параметрами.

Может другие ключи все портят. Попробуй самый простой вариант для проверки:

ffmpeg -i input.mp4 -c:a copy -c:v libx264 -preset ultrafast -crf 0 -vsync passthrough -y output.mkv

Попробуй самый простой вариант для проверки

Да у меня итак без наворотов:

ffmpeg -i input.mp4 -vcodec libx264 -q:v 0 -threads 4 -acodec libmp3lame -q:a 0 -vsync passthrough output.mkv

Исходный файл снят при посредственном освещении, поэтому fps местами падает аж до 4. В среднем, наверное, 16-20, длинные куски с 10-15 (на глазок).

Когда играешь этот mp4 с умножением частоты через SVP (интерполируются дополнительные промежуточные кадры), длинные куски с 10-15 fps выглядят плавными, на 30+ fps. Только движущиеся по фону объекты (люди) чуть чёткость теряют по краю (что понятно).

Если смотреть оригинал и перекодированный файл без умножения кадров, то выглядят на глаз одинаково. Дёргано.

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

Т.е. такое ощущение, что в видеоряд где-то встраиваются дублированные кадры, которые и сбивают процесс умножения (интерполяции) кадров. Пробовал с -vsync vfr — никакой разницы.

А разве по умолчанию добавляются какие-то кадры или как-то странно преобразуются таймштампы? Не думаю. Можешь скинуть оригинал?

Если смотреть оригинал и перекодированный файл без умножения кадров, то выглядят на глаз одинаково. Дёргано.

Ну так на что тогда пеняешь?

Когда играешь этот mp4 с умножением частоты через SVP (интерполируются дополнительные промежуточные кадры), длинные куски с 10-15 fps выглядят плавными, на 30+ fps. Только движущиеся по фону объекты (люди) чуть чёткость теряют по краю (что понятно).

Что такое SVP? Через какую софтину, реализующую эту фичу, ты просматриваешь?

Можешь скинуть оригинал?

Не вопрос. Вот, небольшой (53Мб неперекодированных) с характерными проблемами в начале воспроизведения:

http://home.balancer.ru/files/1509/20141001-1525-CAM00439.mp4

Только у тебя есть винда и SVP, чтобы оценить «плавный» вариант? Если смотреть в родном низком fps, то разницы с оригиналом и перекодированным вариантом нет.

Ну так на что тогда пеняешь?

Смотреть ~10fps без интерполяции — ужасно :)

Что такое SVP?

https://www.svp-team.com/

Это фильтр, который в реалтайме достраивает промежуточные кадры для видеоряда, повышая эффективный 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 не знаю, посмотрю.

Так может дело тогда в SVP?

Телевизор (тоже с интерполяцией, только до 120Гц) тоже дёргается на перекодированном.

А от контейнера не может зависеть?

Может и может. Я не знаю, насколько хорошо .mkv, в который конвертирую, дружит с переменным битрейтом. Попробовал бы и в mp4 сохранить, но ffmpeg умеет его только декодировать.

...

Пойду пока, поиграю с copytb и в .avi попробую

Влияния от -copytb и параметров не заметил. Конвертация в .avi ничего не изменила.

Зато на пробу конвертировал в .mkv через mencoder и наблюдал забавное. Во-первых, в логе целая серия «1 повторяющийся(хся) кадр(а/ов)!». Во-вторых, результат тоже подёргивается, но подёргиваний меньше и они какие-то более плавные, что ли.

Если взять первые две секунды выложенного выше видео, пропустив первые пол-секунды совсем уже отвратительного оригинала, то выходит так:

— Оригинал: изображение дёргается скачками раз 10 в секунду. Полная смена кадра, дёргается сам бэкграунд.

— После интерполяции из исходного mp4 мужик в кепке скроллируется идеально плавно, только в моменты рывков оригинала в конце перемещения влево слегка размазывается. Фон движется абсолютно плавно и даже без размытия.

— После интерполяции из .mkv после ffmpeg с -vsync passthrough рывков меньше (всего за указанный период их штук 5), чем без интерполяции и они «плавные», т.е. объект не мгновенно оказывается в новой позиции, а быстро сдвигается в новую позицию. Фон ведёт себя аналогично.

— После интерполяции из .mkv, полученного через mencoder, вместо серии (упомянутые выше ~5 штук) резких (пусть и сглаженных) смещений наблюдается два ускоренных сдвига, которые уже даже «рывком» особо не назвать. Скорее более заметная, чем в оригинале, неравномерность скроллинга.

И ещё забавный момент. В метаданных нет (или я не знаю, как посмотреть) числа кадров в оригинале. Но средний FPS пишется как 18.679. Длительность:

Duration                                 : 36s 16ms
Source duration                          : 36s 30ms

В общем, получается ~675-678 кадров.

ffmpeg при конвертации ведёт отсчёт до frame=673.

Если видео (оригинальное или конвертированное) ffmpeg декодировать в картинки без опции -vsync passthrough, то получается 1080 кадров.

Если с этой опцией, то оригинал выдаёт 673 кадра.

Конвертированное видео выдаёт два кадра и обламывается с ошибкой

Invalid pts (2) <= last (2)
Video encoding failed
Conversion failed!

Видео, конвертированное mencoder при декодировании в картинки через ffmpeg выдаёт 672 кадра при наличии опции -vsync passthrough и 733 кадра без этой опции.

Блин, с mencoder фигня, он в постоянный fps перегнал:

Frame rate                               : 29.970 fps

В общем, сейчас интересно, почему ffmpeg не может им же созданный результат разложить на картинки с сохранением числа кадров :)

Попробовал бы и в mp4 сохранить, но ffmpeg умеет его только декодировать

ffmpeg -formats | grep mp4
...
 D  mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
  E mp4             MP4 (MPEG-4 Part 14)

Неправда, всё он умеет!

Хм. Я по -codecs смотрел :) Ок, попробую.

...

Интересный эффект. Дёргается примерно с той же частотой, что в .mkv, но, сложно словами описать, как бы на меньшие расстояния. И местами видно работу интерполятора.

Что интересно, характеристики исходного mp4:

Format settings, ReFrames                : 1 frame
Format settings, GOP                     : M=1, N=30
Duration                                 : 36s 16ms
Source duration                          : 36s 30ms
Frame rate                               : 18.679 fps
Minimum frame rate                       : 14.511 fps
Maximum frame rate                       : 31.960 fps

Параметры mp4 после перекодирования:

Format settings, ReFrames                : 4 frames
Duration                                 : 35s 936ms
Frame rate                               : 18.728 fps
Minimum frame rate                       : 14.985 fps
Maximum frame rate                       : 29.970 fps

Уже по длительности и минимальному/среднему/максимальному fps видно, что с кадрами и таймингами не получается 1:1.

Опции -copyts и -copytb на эти параметры не влияют вообще.

А так:

ffmpeg -i in.mp4 -c:v h264 -crf 25 -c:a copy -vsync 0 -r 60 out.mp4

Что на входе, что на выходе 673 кадра. Ругается, правда, но выглядит, вроде, похожим на оригинал.

А так

Хм. У меня в man вообще нет параметра crf :) И параметры кадров совсем уехали:

Frame rate                               : 18.720 fps
Minimum frame rate                       : 15.000 fps
Maximum frame rate                       : 60.000 fps

Но визуально, вроде, нормально смотрится. Всё ещё хуже оригинала, но уже, если заранее не знать, на что смотреть, то можно не заметить разницу. Звук синхронизирован.

А вот mkv с этими же параметрами выглядит отвратительно.

crf — это вместо битрейта, параметр качества. От 51, вроде, — самое ужасное качество, до 0 — максимальное качество или даже лосслесс, если стоит '-preset ultrafast'.