FFmpeg x264 Настройки кодирования
Моя новая видеокамера Canon Vixia HF G30 имеет возможность кодировать непосредственно до 35 Мбит / с Mp4 при 1080p60, и это делает хорошую работу. Я в основном использую его для записи баскетбольных игр моей дочери.
Мне нужно сделать блики из файлов камеры, и я хочу сохранить их как можно более качественными и четкими. Вот рабочий процесс, который я разработал с моим ограниченным пониманием FFmpeg:
ШАГ 1.) Соедините созданные MP4 клипы в один файл MP4, представляющий одну игру. Вот типичная команда, которую я использую для этого шага из командной строки Windows (окно DOS):
ffmpeg -f concat -i "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\gameclipsfromcamera.txt" -c copy "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\joined_fullgame.mp4"
Это объединяет игровые клипы в игровое видео без транскодирования (я полагаю), и это хорошо (это быстро и никаких дополнительных артефактов сжатия не вводится).
ШАГ 2.) Вырежьте клипы из видео игры. Вот типичная команда, которую я использую для этого шага:
ffmpeg -ss 00:00:06.00 -i "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\joined_fullgame.mp4" -acodec copy -vcodec copy -t 00:00:20.00 "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1.mp4"
Это приводит к следующему 20-секундному клипу, начиная с 6 секунд в видео игры:
Образец выделения (85 МБ)
ШАГ 3.) Мне требуется 2-секундная пауза в начале каждого клипа, где наложение текста идентифицирует мою дочь. Чтобы получить это, я делаю растровое изображение из первого кадра клипа:
ffmpeg -i "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1.mp4" -ss 00:00:00.00 -f image2 -vframes 1 -deinterlace "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1freezeframe.bmp"
Вот результат.
Затем зациклите видео в течение 2 секунд с CRF 0, чтобы не вводить никаких дополнительных артефактов:
ffmpeg -loop 1 -r 59.97 -i "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1freezeframe.bmp" -c:v libx264 -crf 0 -pix_fmt yuv420p -t 2 "\\Excelhero\f\Canon\2013.09.21_san_francisco_game2\1freezeframe.mp4"
Затем добавьте текстовую метку наложения, идентифицирующую Фиона:
ffmpeg -i "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1freezeframe.mp4" -vf drawtext="fontfile=/Windows/Fonts/Corbelb.ttf:text='Fiona':fontsize=40:fontcolor=yellow:x=1321:y=417" -b:v 35M -minrate 35M -maxrate 35M -bufsize 35M -profile:v high -level:v 4.2 -refs 2 -pix_fmt yuv420p -bf 0 -r 59.97 "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1freezeframeannotated.mp4"
Который производит этот файл: [ehasamples.excelhero.com/video/1freezeframeannotated.mp4]
(SuperUser позволил мне только включить 2 прямые ссылки)
Теперь мы добавляем тихий звуковой поток в клип:
ffmpeg -f lavfi -i aevalsrc=0:0:sample_rate=48000 -i "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1freezeframeannotated.mp4" -shortest -c:v copy -c:a aac -b:a 255k -strict -2 "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1freezeframeannotatedwithsilentsound.mp4"
В результате этого: [ehasamples.excelhero.com/video/1freezeframeannotatedwithsilentsound.mp4]
(SuperUser позволил мне только включить 2 прямые ссылки)
Выше - 2-секундное видео с моей дочерью, помеченной в приостановленной мультипликации с пустым звуковым потоком.
ШАГ 4.) Последняя операция - присоединить 2-секундное видео к полному ролику с камеры. Я могу легко выполнить рендеринг с помощью фильтра, создавая один выходной файл из этих двух входных файлов следующим образом:
ffmpeg -i "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1freezeframeannotatedwithsilentsound.mp4" -i "\\Excelhero\f\Canon\2013.09.21_san_francisco_game2\1.mp4" -filter_complex "[0:0] [0:1] [1:0] [1:1] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" -c:v libx264 -r 59.97 "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1done.mp4"
Но это не лучшее решение. Это медленно, потому что исходные кадры с видеокамеры воспроизводятся заново с введением новых артефактов сжатия. Я могу добавить " -crf 0 ", чтобы получить повторный рендеринг без потерь, но это увеличивает размер клипа более чем на 1000%, в этом случае размер нашего клипа-образца превышает гигабайт. Так что это не практическое решение.
Поэтому я хочу использовать дематер concat вместо фильтра:
ffmpeg -f concat -i "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\clipfiles.txt" -c copy "\\mylancomputer\f\Canon\2013.09.21_san_francisco_game2\1doneBAD.mp4"
При таком подходе операция выполняется быстро, так как нет перекодирования. НО, полученный файл не воспроизводится должным образом. Вот:
[ehasamples.excelhero.com/video/1doneBAD.mp4]
(SuperUser позволил мне только включить 2 прямые ссылки)
2-секундное изображение отображает все 22 секунды. Хотя видео не воспроизводится должным образом, звук работает нормально. Поэтому я предполагаю, что эти два файла (клип с камеры и 2-секундный клип с меткой) просто слишком сильно отличаются друг от друга в их относительном кодировании. Я попытался сделать их как можно ближе к идентичным с точки зрения кодирования с помощью MediaInfo и FFProbe, и приведенные выше серии команд являются моими лучшими, но, по-видимому, их недостаточно.
Таким образом, у меня возникает вопрос: возможно ли с помощью FFmpeg сделать мой помеченный клип достаточно похожим на закодированный отснятый материал с камеры, чтобы демакс Concat мог успешно работать? Если так, то как?
Весь этот рабочий процесс основан на пакетном файле и с моей стороны очень прост, поэтому мне он нравится, и я надеюсь использовать эту методологию, чтобы позволить мне быстро редактировать основные моменты игр в будущем.
И наоборот, есть ли лучший (более быстрый, без перекодирования) рабочий процесс с использованием FFmpeg?
Благодарю за помощь.
1 ответ
Возможно, вы захотите использовать более быстрый кодек без потерь, который займет больше временного пространства, например, ffvhuff или что-то еще, если у вас быстрые диски. В противном случае используйте -preset ultrafast с -crf 0, (такой же как -qp 0, включает режим без потерь.)
x264 slow только сжимает чуть лучше, чем superfast в режиме без потерь, кстати. Может быть, если бы у вас была анимация с некоторыми битовыми идентичными блоками более чем на 1 кадр назад, чтобы могли помочь несколько ref-кадров, тогда более высокие настройки сделали бы больше. Мои результаты для деинтерлейсинга NTSC DV 1 ч: 22 м (720x480p60) составили 27,9 ГБ (superfast) против 27,0 ГБ (slow), или 55,0 ГБ для ffvhuff, или 37,6 ГБ для ffv1 (настройки по умолчанию, несколько меньшие при еще более медленных настройках сжатия / распаковки ffv1) все в yuv420). CABAC кодирование / декодирование на этом битрейте занимает тонну процессора; Я должен был использовать сверхбыстрый вместо сверхбыстрого, или просто -x264-params cabac=0,
TL;DR: использовать libx264 -preset ultrafast или ffvhuff для промежуточных файлов.
ffv1 или h.264 с CABAC не стоят времени процессора кодирования / декодирования, когда размер файла на самом деле не имеет значения. И huffyuv не делает yuv 4:2:0, вам нужен ffvhuff для этого. Lagarith - это GPL, но в ffmpeg только для декодера, а кодировщик не портирован ни на что, кроме окон. (Соотношение между скоростью и сжатием, вероятно, не слишком впечатляет по сравнению с x264 также, за исключением, может быть, источников шума, таких как анимация, где предсказание / длина пробега до энтропийного кодера будут хорошими.)
Кроме того, уверен, что вы могли бы использовать -vf drawtext во время BMP -> 2 сек видео шаг. И почему вы используете hard-CBR (битрейт 35M, максимальный битрейт 35M) для этого? Почему бы не просто без потерь для этого шага тоже?
Обычно не полезно для конкретного -profile для x264. Он устанавливает флаги профиля в выводе на минимально возможное значение, учитывая то, что он помещает в поток битов. (т.е. он установит высокий профиль, если 8x8dct=1 и определите, какой уровень основан на кадрах рез, битрейта и реф. -profile также вынуждает x264 снизить количество кадров ref или другие настройки, необходимые для соблюдения ограничений для данного профиля. Тем не менее, редко нужно использовать его, если только он не предназначен для HW-декодера.
Что полезно при окончательном кодировании с потерями -preset slower или что-то, чтобы x264 использовал больше процессорного времени, но получал больше качества при том же битрейте. Это в значительной степени заменяет необходимость настройки всех ручек, таких как ref-кадры, шпалеры, адаптивные b-кадры, поиск движения и т. Д.
Чтобы попытаться ответить на реальный вопрос, необходимо иметь возможность объединять различные потоки h.264 (из кодера вашей камеры и из BMP -> x264), просто разрешение, цветовое пространство (yuv420 против yuv444 или что-то в этом роде) и вероятно, некоторые параметры потока h.264, например, чересстрочный или нет.
Если вы планируете хранить все 35 Мбит / с и не хотите, чтобы размер файла был приемлемым, который вы могли бы отправить через Интернет, тогда вы захотите соответствовать тому, что делает аппаратный кодер вашей камеры., Или вы можете запустить все это через x264, что займет время, но с -preset veryslow Вы можете, вероятно, сделать 10 Мбит / с, или даже 5, с небольшой заметной потерей качества. Пытаться -crf 18 обычно это довольно прозрачно. (Да, вы все еще можете легко заметить разницу, если вы сделаете паузу и переключитесь между x264 и исходными кадрами).
Если должно быть возможно сделать весь процесс за один вызов ffmpeg. Фильтрующий граф, который в конечном итоге заканчивается в фильтре concat, может иметь цепочки, которые генерируют 2 секунды повторяющегося неподвижного изображения + тишина с вкраплениями цепочек, которые являются просто inputfile-> output.
(Или, если вы действительно хотите не кодировать выходные данные камеры, и можете выяснить, что отличается между выходом вашей камеры и x264: один вызов ffmpeg для неподвижного изображения, а затем один финальный конкат.)
Аппаратные кодеры в телефонах и камерах обычно довольно плохие. Единственный способ, которым они выглядят хорошо, это бросить много битрейта на проблему. x264 обычно может работать намного лучше, особенно с -preset slow, slower или veryslow. Очевидно, будет еще одно поколение потерь, но вы можете сократить битрейт видео до 2 Мбит / с для голливудских фильмов 1080p@24fps с очень четкими деталями. Шумные портативные источники с высоким движением все время будут занимать больше битов, но -crf 18 Это постоянное качество, поэтому я рекомендую это как то, что будет достаточно для просмотра даже близко на хорошем мониторе. Я бы, вероятно, все же сохранил бы исходные источники, так как хранилище становится только дешевле, и вы никогда не сможете восстановить исходное качество из вывода x264. Тем не менее, я бы просто оставил их для них. Если вы даете этот файл кому-либо или копируете его через Интернет, x264 -preset slow делает хорошие вещи. Даже по умолчанию -preset medium это хорошо. Если вы не установите целевой битрейт или качество, по умолчанию я думаю -crf 23,
Я не очень много делаю, чтобы ответить, как заставить x264 выводить данные, которые можно согласовать с не кодированным потоком битов вашей камеры, так как это не то, что я должен был сделать, и мне не очень интересно это выяснять, извините, В основном, ответы, так что любой, кто хочет следовать вашей отправной точке, не будет приведен к -crf 0 или чему-то глупому.:П