Как стать автором
Обновить

Комментарии 33

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

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

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

Обычно проблема не в битрейте, а в количестве кадров
Что скажете о использовании h265 и webp под домашние цели (фото/видео)?
Не автор но отвечу — если не планируется просмотр на устройствах платформы, отличной от PC — то вариант отличный. А вот на разных smart-телевизорах и других поддержка оставляет желать лучшего.
Странно — мой телевизор отказывается показывать видео прямо с камеры. А после того как пережал на х265 показывает без проблем.
Повезло, значит.
Увы, с поддержкой всяких экзотических и самых современных кодеков в бытовой технике, а также с обновлениями — лютый, бешеный швах.
Это может компенсировать Plex, но медисервер будет шуметь как пылесос кодируя файлы налету.
НЛО прилетело и опубликовало эту надпись здесь
Я последнею неделю как раз занялся домашним видео снятие на GoPro. Но место любимого ffmpeg для х265 попробовал Handbrake и 1080р60 ужался от 3 до 10 раз в зависимости от того что происходит в кадре. 4К видео тоже ужимается, но куда хуже — в среднем только в двое. Но занимает очень много времени, так как программа работает только в 1 поток.
Так что мне тоже интересно что народ делает с 4К видео — уж очень много оно занимает, сжимается плохо и это занимает много времени. Хотя смотреть очень приятно и возвращаться на 1080 не хочется.
HandBrake, кстати, тоже использует ffmpeg. ;)
И да, он хорошо подходит для того случая, когда не хочется заморачиваться с ключами ffmpeg. :)
HandBrake, кстати, тоже использует ffmpeg. ;)

но не для x265

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


 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>

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

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

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

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

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

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

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

Спасибо.
imagemagick в стагнации, вместо него рекомендуется использовать graphicsmagick, который в целом имеет тот-же синтаксис, но отличается большей производительностью и меньшим потреблением ресурсов.
до кучи — объединение видео (есть и другие варианты):
ffmpeg -i 'concat:input1|input2' -codec copy output
Захват с тв-тюнера тоже можно, если, например, есть необходимость оцифровать видеокассету 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 в системе, чтобы переключиться на композитный режим.
Тот кто умеет пользоваться командной строкой уже давно знает и использует ffmpeg. А вот остальным этот программный продукт покажется сложным и неудобным. Можно было бы упомянуть некоторые бесплатные разработки на базе того же ffmpeg, но с графическим интерфейсом.

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

На больших файлах, и если нужно вырезать из самого конца, очень серьёзно сокращает время обработки.
То есть на ffmpeg влияет порядок команд в строке? o.O
Да, я в своё время долго не мог понять, почему конвертация нормально не работает, пока не осознал, что порядок аргументов имеет значение.

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

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