temujin Jul 19 2017 at 20:59

Укрощаем мультимедиа с помощью ffmpeg

3 min

87K

Configuring Linux**nix*Data compression*

+32

Comments 33

lorc Jul 19 2017 at 21:42

Спасибо!
Интересно, а зачем кому-то повышать битрейт? Качество то этого не повысится. А скорее даже понизится из-за перекодирования.

hdfan2 Jul 20 2017 at 07:17

Скорее всего, автор имел в виду такую проблему: по каким-то причинам нужно перекодировать аудио/видео из одного lossy формата в другой. В этом случае с настройками по умолчанию качество может получиться не очень, и иногда имеет смысл увеличить битрейт выходных данных, чтобы улучшить качество.

kolipass Jul 20 2017 at 07:36

Я так склеивал несколько видео рядов: есть основное видео с высоким, но оптимальным битрейтом. Есть другое видео, битрейт которого ниже — поднимаем его битрейт и склеиваем оба видео. Более простого решения в лоб я не нашёл.

Wernisag Jul 20 2017 at 08:06

Обычно проблема не в битрейте, а в количестве кадров

Tihon_V Jul 19 2017 at 22:17

Что скажете о использовании h265 и webp под домашние цели (фото/видео)?

PaulZi Jul 19 2017 at 22:37

Не автор но отвечу — если не планируется просмотр на устройствах платформы, отличной от PC — то вариант отличный. А вот на разных smart-телевизорах и других поддержка оставляет желать лучшего.

praeivis Jul 19 2017 at 22:47

Странно — мой телевизор отказывается показывать видео прямо с камеры. А после того как пережал на х265 показывает без проблем.

hungry_ewok Jul 20 2017 at 09:01

Повезло, значит.
Увы, с поддержкой всяких экзотических и самых современных кодеков в бытовой технике, а также с обновлениями — лютый, бешеный швах.

navion Jul 20 2017 at 00:53

Это может компенсировать Plex, но медисервер будет шуметь как пылесос кодируя файлы налету.

UFO just landed and posted this here

praeivis Jul 19 2017 at 22:45

Я последнею неделю как раз занялся домашним видео снятие на GoPro. Но место любимого ffmpeg для х265 попробовал Handbrake и 1080р60 ужался от 3 до 10 раз в зависимости от того что происходит в кадре. 4К видео тоже ужимается, но куда хуже — в среднем только в двое. Но занимает очень много времени, так как программа работает только в 1 поток.
Так что мне тоже интересно что народ делает с 4К видео — уж очень много оно занимает, сжимается плохо и это занимает много времени. Хотя смотреть очень приятно и возвращаться на 1080 не хочется.

dayfuaim Jul 20 2017 at 10:54

HandBrake, кстати, тоже использует ffmpeg. ;)
И да, он хорошо подходит для того случая, когда не хочется заморачиваться с ключами ffmpeg. :)

zelenin Jul 20 2017 at 12:00

HandBrake, кстати, тоже использует ffmpeg. ;)

но не для x265

PaulZi Jul 19 2017 at 22:44

А ещё в ffmpeg куча фильтров, от resize и crop до шумодавов и стабилизации видео.

zaur45 Jul 20 2017 at 10:54

Мне, лично, для стабилизации видео с экшн-камеры помог следующий рецепт в два прохода:

 ffmpeg -i <input_file> -vf vidstabdetect=shakiness=5:show=1 -f null -                      
ffmpeg -i <input_file> -vf vidstabtransform,unsharp=5:5:0.8:3:3:0.4 <output_file>

Видео снимаю для домашнего архива, поэтому без примера :)

dayfuaim Jul 20 2017 at 14:13

Да, один из самых полезных фильтров. Только для него нужен специально собранный ffmpeg, с поддержкой libvidstab.
На всякий случай, инструкция по сборке (для Ubuntu): Video Stabilization Using VidStab and FFmpeg on Linux

hdfan2 Jul 20 2017 at 07:21

Большое спасибо за отличный cheat sheet. Только немного удивил битрейт flac'а. Разве у него есть битрейт? Это же формат сжатия без потерь. У него вроде есть только степень сжатия (с большой степенью размер файла может получиться чуть меньше, но сами данные остаются те же). Битрейт актуален для lossy кодеков.

temujin Jul 20 2017 at 08:06

Спасибо, я не обратил внимания. Проверял синтаксис команд и вывод ffmpeg-а. Битрейт действительно меняется, но это не влияет на качество.

OlegFX Jul 20 2017 at 09:25

Ссылка на Perl скрипт для повышения резкости изображения не работает: «this goo.gl shortlink has been disabled». И, раз уж пишу в комментариях, поправьте, пожалуйста, вот тут:

ffmpeg -r .3 -pix_fmt rgba -s 1280x720 -pattern_type glob -i "*.JPGЭ video.mkv

Вместо закрывающей кавычки 'Э' образовалось.

Спасибо.

grayich Jul 20 2017 at 15:25

imagemagick в стагнации, вместо него рекомендуется использовать graphicsmagick, который в целом имеет тот-же синтаксис, но отличается большей производительностью и меньшим потреблением ресурсов.

lmike Jul 20 2017 at 15:25

до кучи — объединение видео (есть и другие варианты):

ffmpeg -i 'concat:input1|input2' -codec copy output

dcc0 Jul 20 2017 at 16:47

Захват с тв-тюнера тоже можно, если, например, есть необходимость оцифровать видеокассету VHS. Я c тюнера Pinncle так захватывал:
ffmpeg -f alsa -ac 2 -i hw:0 -ab 128 -f video4linux2 -s 640x480 -b:v 4800kb -i /dev/video0 -acodec libmp3lame -vcodec h264 out.avi"
Только иногда еще нужно иметь утилиту v4lctl в системе, чтобы переключиться на композитный режим.

Prous Jul 20 2017 at 17:59

Тот кто умеет пользоваться командной строкой уже давно знает и использует ffmpeg. А вот остальным этот программный продукт покажется сложным и неудобным. Можно было бы упомянуть некоторые бесплатные разработки на базе того же ffmpeg, но с графическим интерфейсом.

Одна и старейших XviD4PSP, хоть и бывает падает, но всё равно хорошая прога. А вот эту FFAStrans использую на работе для автоматической обработки файлов, позволяет следить за папками и просчитывать материалы с достаточно широкими возможностями. Конечно голый ffmpeg куда как более гибок, но и сложность в его освоении достаточно велика.

kodopik Jul 21 2017 at 13:33

Попробуйте вместо

ffmpeg -i video_full.m4v -c:av copy -ss 00:01:00 -t 10 video_short.m4v

так:

ffmpeg -ss 00:01:00 -i video_full.m4v -c:av copy -t 10 video_short.m4v

На больших файлах, и если нужно вырезать из самого конца, очень серьёзно сокращает время обработки.

praeivis Jul 22 2017 at 10:21

То есть на ffmpeg влияет порядок команд в строке? o.O

pav5000 Jul 26 2017 at 17:19

Да, я в своё время долго не мог понять, почему конвертация нормально не работает, пока не осознал, что порядок аргументов имеет значение.

kodopik Jul 26 2017 at 22:18

Да. Это ещё более заметно при использовании ключа -map (хотя и более очевидно).

praeivis Jul 27 2017 at 15:39

А где можно про это почитать? Или может кто-то собирается это поправит? Если тема поднималась, то что разработчики ответили?

kodopik Aug 9 2017 at 18:07

Править не будут, так задумано. В случае -map положение ключа относительно других влияет на номер потока:
https://trac.ffmpeg.org/wiki/Map
Не думаю, что ffmpeg — это единственная утилита командной строки без коммутативности ключей. Хотя и не уверен в этом.

AmnoN Jul 25 2017 at 11:18

С резкой файлов не все так просто. Если -ss использовать ПОСЛЕ -i опции то ffmpeg декодирует все ТОЧНО до указанного времени. Именно по этому процедура может быть долгой, если отрывок в конце файла. Если использовать ПЕРЕД -i опции, то используется поиск по ключевым кадрам, этот процесс намного быстрее чем декодирование. Но начало отрезка будет с ключевого кадра, а не с указанного времени. В некоторых случаях это не критично. Но обычно это проблема, например у кодека h264 интервал ключевых кадров по умолчанию 250 (10 секунд). ± 10 секунд от начала времени. Там еще есть нюансы если использовать copy или конвертацию… Короче это тема для отдельной статьи. https://trac.ffmpeg.org/wiki/Seeking

pav5000 Jul 26 2017 at 17:18

Начиная с версии 2.1 ffmpeg умеет быстро искать с точностью до кадра, когда -ss указывается до -i. За исключением случаев -c:v copy

AmnoN Jul 26 2017 at 18:26

В таком случае быстроту поиска омрачает процесс конвертации. И тут все зависит от мощности компьютера, длительности отрезка, настройки кодека.

pav5000 Jul 26 2017 at 18:27

Я имел ввиду, что применять это стоит только если вам так или иначе надо конвертировать файл.

Show the best of all time