FFmpeg x264 Настройки кодирования

Question

Моя новая видеокамера 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?

Благодарю за помощь.

Answer 1

Возможно, вы захотите использовать более быстрый кодек без потерь, который займет больше временного пространства, например, ffvhuff или что-то еще, если у вас быстрые диски. В противном случае используйте -preset ultrafast с -crf 0 . (так же, как -qp 0 , включает режим без потерь.)

Кстати, slow x264 сжимает чуть лучше superfast в режиме без потерь. Может быть, если бы у вас была анимация с некоторыми битовыми идентичными блоками более чем на 1 кадр назад, так что несколько ссылок могут помочь, тогда более высокие настройки сделают больше. Мои выводы для деинтерлейсинга NTSC DV 1 ч:22 м (720x480p60) составили 27,9 ГБ (superfast) против 27,0 ГБ (slow), или 55,0 ГБ для ffvhuff, или 37,6 ГБ для ffv1 (настройки по умолчанию, несколько меньше при еще более медленном сжатии ffv1). / распаковать настройки) все в юв420). CABAC кодирование / декодирование на этом битрейте занимает тонну процессора; Я должен был использовать сверхбыстрый вместо сверхбыстрого, или просто -x264-params cabac=0 .

TL; DR: используйте libx264 -preset -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 , и определит, какой уровень основан на рез, битрейте и кадрах ref.) edit: -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 или чему-то глупому. :П