Комментарии 86
Такие дела, братюни! Не пренебрегайте инструментами командной строки
Мы то, как раз не пренебрегаем, FFmpeg используем постоянно. Только у вас я хороших примеров не увидел (наверное, плохо смотрел?). Под «хорошими» я понимаю результаты, выложенные в общий доступ. Например, видео с двуязычными субтитрами. Допустим, берем обучающий ролик с французско-английскими субтитрами:

и делаем замену английского перевода на русский:

Само видео можно посмотреть в https://lecole.free.nf/Video/FrRu0101.php .
Или еще круче. В «одноклассниках» можно найти оригинал испанского фильма: «Парчиз против изобретателя невидимки» («Los Parchís contra el inventor invisible»). Там есть прикольная песня: «La Batalla de los Planetas» («Битва Планет»).
Весь «цимус» был в том, что, не зная испанского, распознать текст песни, перевести ее и «нарисовать» соответствующие субтитры:

Более того, с помощью FFmpeg нужно было извлечь музыкальную дорожку из фильма, разделить музыку (которая слишком громкая в фильме) и вокал, приглушить музыку и затем всё объединить снова. И это притом, что доступные (бесплатные) ИИ-сервисы плохо распознают текст песен.
Результат эксперимента можно посмотреть в: https://rutube.ru/video/87d4a7fe4a59271dd1871ec2331ee98f/ .
Кроме титров, с помощью FFmpeg, можно делать «видео-книги»: https://my.mail.ru/mail/emmerald/video/_myvideo/27.html :

Здесь сразу виден уровень возможностей FFmpeg и других подобных утилит, вроде консольной утилиты «ImageMagick»:

перекодировать видео из H264/H265 в контейнер WebM с кодеком VP9
Аппаратная поддержка H264 нынче встроена в любую лампочку, а вот потянет ли эта лампочка программное декодирование VP9 — большой вопрос
ffmpeg -i ./input.mp4 -c:v libvpx-vp9 ./output.webm
На видео с переменной частотой кадров ffmpeg любит иногда эту самую частоту портить, поэтому на всякий случай усмиряю его опциями -fps_mode:v passthrough и -enc_time_base:v demux чтобы не выпендривался
(ещё в каких-то старых версиях ffmpeg любил портить цветовое пространство, но сейчас воспроизвести не могу, возможно починили)
вытаскивание скриншота из видео
Тут уж проще использовать функцию создания скриншота, встроенную в видеоплеер
Но мы так теряем в качестве
Через ffmpeg вы тоже теряете качество дважды: во-первых, из-за преобразования цветового пространства (хотя на BT.709 это незаметно, потому что оно почти идентично sRGB), а во-вторых, из-за jpg
ffmpeg -i ./input_video.mp4 -vn -c:a copy ./audio.mp3
Что-то я очень сильно сомневаюсь, что аудио в видеофайле было закодировано именно в MP3. Вы проверяли, что за файл получается на выходе на самом деле? (Впрочем, если там не MP3, то мой ffmpeg ругается Invalid audio stream)
И вместо -vn наверно лучше использовать что-то вроде -map 0:a:0 чтобы быть уверенным, что на выходе ровно один аудиопоток и никакого мусора вроде встроенных субтитров
обратно в SVG сконвертировать не получится
Я бы посмотрел у кого получится 🙃
Для более быстрого итерирования
Ограничьте длительность выходного файла опцией -t, нет необходимости ждать полного перекодирования, чтобы просто проверить попадание координат текста
Я хочу выводить видео прямо в терминал
mpv --vo=tct (я бы ещё сказал mpv --vo=caca но в моей сборке mpv он почему-то недоступен)
если уж речь пошла о вырезании аудиодорожки из скачанного с ютуба видео, то нельзя обойти вниманием ещё один инструмент командной строки – а именно yt-dlp. как ffmpeg служит перочинным ножиком для всего, что связано с перекодированием картинок, звука и видео (разве что кофе варить не умеет), так yt-dlp – универсальный солдат для скачивания видосов с YouTube (и тысяч других сайтов). если раньше я действовал как автор статьи (т.е. скачивал видео через какой-нибудь сайт или расширение и потом ffmpeg'ом вырезал аудиодорожку или фрагмент видео с нужной репликой персонажа), то теперь не мыслю себя без yt-dlp.
утилита опенсорсная, кроссплатформенная, проживает здесь, инсталлятора не имеет, да он и не нужен – просто качаешь файл для своей платформы и кидаешь в удобное место, также понадобится скачать зависимости (тот самый ffmpeg и deno или аналогичный рантайм для разбора джаваскрипта). в линуксе вроде надо добавлять репозиторий, точно не подскажу, но в винде всё просто ставится через winget: winget install yt-dlp.yt-dlp.nightly (желательно ставить именно nightly версию, потому что ютуб постоянно пытается поломать скачивальщики, а они пытаются адаптироваться – такие вот кошки-мышки. вингет сделает всё сам – подтянет зависимости, пропишет команды, добавит что нужно в PATH, одна команда – и готово.
установили, можно качать:
yt-dlp https://youtu.be/dQw4w9WgXcQ
это самый простой пример использования, будет скачано видео и аудио (ютуб хранит их отдельно) в максимальном качестве, потом дорожки будут склеены с помощью ffmpeg.
если вам нужно видео в 360p, то не обязательно тянуть 4K, а потом перекодировать. можно посмотреть список доступных форматов (ключ -F):

yt-dlp c ключом -F показывает номера доступных форматов, их размер, кодек, качество (разрешение и фреймрейт для видео; частота дискретизации и битрейт для аудио). выбираем нужные и качаем с помощью ключа -f:
yt-dlp -f 396+251 dQw4w9WgXcQ
автору статьи нужно было вытащить из видео аудиодорожку; для этого можно указать только номер аудиодорожки в ключе -f или использовать -x:
yt-dlp -f 251 dQw4w9WgXcQ
yt-dlp -x dQw4w9WgXcQ
впрочем, указание конкретного формата – не совсем правильно. правильнее указать максимальное качество какого-то конкретного кодека:
yt-dlp -f "bestvideo[ext=webm]+bestaudio[ext=m4a]/best" dQw4w9WgXcQ
или ограничить разрешение видео (bestvideo и bestaudio можно заменить на bv и ba соответственно):
yt-dlp -f "bv[height<=480]+ba/b" dQw4w9WgXcQ
чуть более продвинутый пример скачивания аудио с перекодированием:
yt-dlp -x --audio-format mp3 --audio-quality 320k --embed-thumbnail --embed-metadata -P "%USERPROFILE%/Music" -o "%(title)s.%(ext)s" dQw4w9WgXcQ
-x – скачать только аудио; --audio-format – в какой формат перекодировать; --audio-quality указывает битрейт (также можно указать качество перекодирования "в шакалах" от 0 до 10); --embed-thumbnail и --embed-metadata соответственно встраивают в mp3 превьюшку с ютуба и данные о песне для отображения в плеере; -P указывает, куда класть конечный файл, а -o – как его назвать (по умолчанию yt-dlp добавляет ID видео к имени файла; указанный в команде формат позволяет этого избежать).
если вам нужны только несколько секунд из ролика, опять же, не надо качать его целиком, можно вырезать нужную часть:
yt-dlp --download-sections "*00:01:30-00:01:45" dQw4w9WgXcQ
кстати, заметили, что в примерах выше нет полной ссылки? для ютуба достаточно указать ИД видео (или плейлиста, кстати – тогда будет качаться весь плейлист), для остальных сайтов придётся всё-таки давать полную ссылку.
ютуб может не отдавать видео без входа на сайт (например, у ролика ограничение по возрасту, или у вас приватная ссылка, доступная только вашему аккаунту, либо у вас есть премиум и вы хотите скачать премиум-видео, да просто ютубу может не понравиться ваш IP-адрес). в этом случае надо передать yt-dlp куки, чтобы подтвердить свою личность. проще всего это делать с помощью файрфокса – войти в браузере и в yt-dlp использовать ключ --cookies-from-browser firefox (с хромом и тому подобными этот трюк не работает, там надо вытаскивать куки в файл и использовать ключ --cookies cookies.txt).
возможностей у yt-dlp гораздо больше, я лишь поскрёб самую поверхность. естественно, эта утилита – не волшебная палочка и не инструмент для хакинга, она не скачает удалённый ролик, видео, к которому у вас нет доступа, или видео с географическими ограничениями. ну и конечно, если вам повезло жить в самой прекрасной стране на свете, вам нужен либо туннель, либо подкоп и прочее удобное средство доступа к информации, в крайнем случае ТОР (если что, yt-dlp умеет в прокси):
yt-dlp --proxy socks5://127.0.0.1:9150 dQw4w9WgXcQ
ну и напоследок, если прекрасно работавшая утилита вдруг перестала качать и начала выдавать ошибку, первым делом попробуйте её обновить:
yt-dlp -U
Я с недавших пор предпочитаю просто спросить у ChatGPT - как мне с помощью ffmpeg сделать то-то и то-то, он выдает строчку с кучей ключей, которые я не собираюсь запоминать и изучать, я беру эту строку и запускаю. Если что-то не так, говорю - чувак, это не то что я хотел, мне надо вот так-то... В общем обычное дело.
Но конечно же ffmpeg не заменяет видеоредактор. Хотя, для линуксоидов (которые так красноречиво изображены на обложке статьи) может и норм :)
Вы перешли на следующий уровень ;) Просто не все знают, что так вообще можно - это натолкнуло меня на написание статьи, пусть и полушуточной.
А видеоредактор у меня тоже есть. Просто ОЗУ у меня обычно занята докером, IDE, браузером и терминалом - и везде, мягко говоря, не по одному окну. Ну и не только. Поэтому не всегда есть возможность запускать большой GUI, проще в терминале зарядить FFmpeg как фоновую задачу.
Иронично получилось упоминание ффмпег в контексте экономии ОЗУ, если в качестве примера сжимать видео в h265 (процесс прожорливые предшественников).
Более правдиво выглядело бы избавление от Qt GUI в пользу командной строки с перспективой избавиться от зависимостей и полсотни мег на диске высвободить)
Согласен, экономия ОЗУ часто превращается бесконтрольное её пожирание. Так у нас, оптимизаторов производительности, заведено :D
Я из графических редакторов в итоге оставил у себя на линуксовой рабочей машине только Shotcut. Всё-таки не всегда GUI можно избежать)
Я имел в виду, что алгоритм в основе h265 ищет грубо говоря более крупные и сложные объекты в кадре, чем его предшественники, и на сбор статистики движения участков кадра тратит драматически больше памяти, поэтому не очень похож на добрососедский по отношению к другим процесс в многозадачном окружении. Отчасти напоминает современные архиваторы с громадным словарём в сравнении с pkzip прошлого века.
Что касается GUI, мне как виндузятнику не очень по душе дублирование в каждом мультиплатформенном приложении функционала менеджера окон, который в системе уже есть из коробки, при этом они каждое пользуются своей конкретной версией, а не одной на всех ( что в сумме ведёт к разбуханию дистрибутивов
полсотни мег на диске высвободить
На 1 ТБ диске, 0.05%, серьезно?
Я в школу ходил при Брежневе и помню, сколько места "должна" или может занимать целая операционная система, не будем ворошить прах win3.11 ладно, но например XP ) и всё ещё считаю диск в ПК своим, а не принадлежащим разработчикам ОС и рантайм библиотек, которые при не слишком впечатляющем росте функциональности в размерах за последние годы распухли как монтажная пена.
На мой взгляд, дело не в долях процента терабайтного диска, а в возможности таскать джентльменский набор утилит на 16 Гб флешке с собой, быстро бэкапить, легко заливать на онлайн диск или в облако, не утыкаясь в лимиты бесплатных хранилищ или вложений почты и соцсетей.
помню, сколько места “должна” или может занимать целая операционная система, не будем ворошить прах win3.11 ладно, но например XP )
И сколько? Во времена актуальной ХР, напоминаю, диски были сильно меньше. Считайте в %.
в возможности таскать джентльменский набор утилит на 16 Гб флешке с собой
128 гб флешка стоит чуть дороже чем 16. А меньше 16 нужно специально искать.
быстро бэкапить
Терабайтный диск? На 16 гб флешку? Нуок.
следующий уровень: просить у тула вроде Claude Code сделать то-то и то-то с целым каталогом, он сам начнёт его обходить, где-то запускать ffmpeg, где-то запускать тут же написанные python скрипты c инструментами вроде vad.
я так прошу выделять голос из сырых больших аудиозаписей с кучей шума, а потом отправлять предобработанные куски с голосом на распознавание речи
День 16. Объясняю жене, почему не могу просто запустить Paint и нажать две кнопки.
В тот же день. Расчехляете Винду и опять начинаете использовать крякнутые Фотошоп и Вегас, потому-что жена пригрозила, что перестанет Вас кормить(Пусть тебе твой ffmpeg обед готовит) /s
часто использую ffmpeg в связке с mpv, который позволяет писать скрипты на lua. Так удобнее настраивать cut+trim и сразу записывать результат в буфер обмена для ffmpeg
Да, FFmpeg - это станок на все случаи жизни. Захват экрана, отправка трансляции в сокет, биндинги в самые разные ЯП - чего там только нет...
Дабы не раздувать объём, я покрыл только самые примитивные сценарии применения. Если у читателя проснулся интерес к теме, рекомендую заглянуть в официальную документацию и более узконаправленные статьи.
А для изучения возможностей FFmpeg - помимо упомянутого комментатором выше ChatGPT - рекомендую вот эту статью про различные GUI вокруг консольной утилиты. GUI как инструмент обучения, чтобы лучше понять спектр задач и возможности, очень даже подходит.
Я на Windows. Редакторов для всех типов медиа у меня предостаточно. Но ffmpeg всегда под рукой (а у некоторых видеоредакторов под капотом) и время от времени я им пользуюсь. Для изображений же иногда обращаюсь к ImageMagick - тоже клевый набор консольных утилит для статичной графики.
ffmpeg конечно может все. И использовать его очень удобно в автоматизации или каких-то специфических задачах внутри скриптов. Но на повседневных задачах... для тех кто любит "секс в гамаке стоя".
Я не вижу проблемы в работе из командной строки. Могу связать это с издержками профессии :)
По Вашему профилю не могу понять, кем Вы трудитесь, но вообразите себе рутину инженера-программиста, специализирующегося на бэкенде и системном ПО. Я иногда весь день в терминале провожу с логами, правкой конфигой, пересборкой проектов и минимальными правками прямо в nano. Рука набита на клавиатуре уже условно 3 или 5 часов. Мышкой почти не пользуюсь уже два года, тачпад у меня в основном для системных жестов и иногда скролла (переучаю себя на Page Up/Down). На кой ляд в таком случае коней менять, если можно всё привычными движениями пальцев сделать?
Такие дела, братюни! Не пренебрегайте инструментами командной строки
Мы то, как раз не пренебрегаем, FFmpeg используем постоянно. Только у вас я хороших примеров не увидел (наверное, плохо смотрел?). Под «хорошими» я понимаю результаты, выложенные в общий доступ. Например, видео с двуязычными субтитрами. Допустим, берем обучающий ролик с французско-английскими субтитрами:

и делаем замену английского перевода на русский:

Само видео можно посмотреть в https://lecole.free.nf/Video/FrRu0101.php .
Или еще круче. В «одноклассниках» можно найти оригинал испанского фильма: «Парчиз против изобретателя невидимки» («Los Parchís contra el inventor invisible»). Там есть прикольная песня: «La Batalla de los Planetas» («Битва Планет»).
Весь «цимус» был в том, что, не зная испанского, распознать текст песни, перевести ее и «нарисовать» соответствующие субтитры:

Более того, с помощью FFmpeg нужно было извлечь музыкальную дорожку из фильма, разделить музыку (которая слишком громкая в фильме) и вокал, приглушить музыку и затем всё объединить снова. И это притом, что доступные (бесплатные) ИИ-сервисы плохо распознают текст песен.
Результат эксперимента можно посмотреть в: https://rutube.ru/video/87d4a7fe4a59271dd1871ec2331ee98f/ .
Кроме титров, с помощью FFmpeg, можно делать «видео-книги»: https://my.mail.ru/mail/emmerald/video/_myvideo/27.html :

Здесь сразу виден уровень возможностей FFmpeg и других подобных утилит, вроде консольной утилиты «ImageMagick»:

Прежде всего, благодарю за комментарий! Хватало бы кармы, поставил бы плюс за потрясающее дополнение.
Мы то, как раз не пренебрегаем, FFmpeg используем постоянно. Только у вас я хороших примеров не увидел (наверное, плохо смотрел?). Под «хорошими» я понимаю результаты, выложенные в общий доступ.
Статья содержит не один текст, а как раз таки прикреплённые результаты. На основе моей рабочей практики прошлого - конечно, отредактированные или с заменой исходника, потому что NDA и всё такое. Это сэмплы, не более. Я же поставил статье категорию "Мнение", а не "Кейс".
Дабы упростить жизнь читателю, я вместо внешних ссылок на видео вставил гифки прямо в статью. Да, потерялось качество и визуальная красота. Да, некоторые кейсы из-за этого пришлось выкинуть из финального черновика. Но цели сделать исчерпывающее руководство по FFmpeg я не ставил (это на практике невозможно). Как и цели впечатлить прожжённых юзеров с многолетним опытом использования (это делать уж точно не мне). Статья бы тогда растянулась и стало бы ещё тяжелее дожить до конца :)
Прежде всего, благодарю за комментарий!
Спасибо! Взаимно, за доброжелательную реплику!
Хватало бы кармы, поставил бы плюс за потрясающее дополнение.
Добавил вам плюс в карму.
Я же поставил статье категорию “Мнение”, а не “Кейс”.
У меня была опубликована обучающая программа здесь. Долго не мог найти подходящий тег для нее. По-моему, поставил «Мнение». Теперь буду знать, что надо ставить «Кейс». Хотя, по-хорошему, почему нет тега: «Разработка ПО для ПК»?
Но цели сделать исчерпывающее руководство по FFmpeg я не ставил
А зачем, вообще, делать «исчерпывающие руководства»? Все равно, ведь, нужная информация находится не там, а в оригинальной документации. А про «ноу-хау», вполне, можно спросить у ИИ-ёв.
Как и цели впечатлить прожжённых юзеров с многолетним опытом использования
Думаю, что не надо никого «впечатлять»! Достаточно, ориентироваться на воспроизводимый результат.
«Юзвери», они, ведь, тоже люди и смотрят на любую статью с собственной «колокольни»: «А что, лично мне, может дать эта статья?». – Полезную информацию, которая неизвестно когда пригодится и пригодится ли вообще? Или яркую картинку – скриншот, которую глянул краем глаза и сразу заценил – нужно ли, вообще, читать текст дальше:
В этом смысле, меня умиляют статьи без иллюстраций, но с огромными кусками кода. Неужели автор реально надеется, что в этот код кто-то будет вникать «искусства, ради»? Я эти портянки сразу пролистываю и смотрю, а в заключении или выводах автор что-нибудь завлекательное напишет? Свой код, я всегда стараюсь давать в прилагаемых архивах. Кому надо, скачает и сразу запустит. Максимум, можно дать 10-15 строчек для демонстрации чего-то там.
Добавил вам плюс в карму
От всей души благодарю, сударь!

Теперь у меня период охлаждения, приду завтра :)
---
Про "исчерпывающее руководство", "впечатлять" и всё что далее - полностью с Вами согласен. Просто я, когда сначала прочитал Ваш комментарий, предположил критический настрой по отношению к статье из-за фраз наподобие
Только у вас я хороших примеров не увидел (наверное, плохо смотрел?)
Я не вижу проблемы в критике как таковой. Просто сложилось впечатление, что Вы говорите о том, что Вам всё показанное в статье известно и что Вы на другом уровне. А я ответил, что я держал в голове вообще другую аудиторию: тех, кто про FFmpeg знает "постольку, поскольку" - или не знает вообще.
Я не вижу проблемы в критике как таковой.
Правильно! «Критики бояться – в Интернет не ходить!»
Просто сложилось впечатление, что Вы говорите о том, что Вам всё показанное в статье известно и что Вы на другом уровне.
Да нет, конечно! «Специалист – подобен флюсу», как говаривал Козьма Прутков, «полнота его одностороння!».
У всех нас полно пробелов в знаниях, разве что «тараканы в голове», иногда похожи.
FFmpeg – действительно неисчерпаем. Удивляюсь, как его вообще могли создать. Просто, лично я предпочитаю осваивать материал порциями. Типа, вот с помощью этой команды – можно получить такой результат, а помощью иной – другой. А вот картинки для демонстрации. При этом важно давать ответ, зачем или какой смысл подобных телодвижений?
Вообще, мне кажется, статьи нужно ориентировать на визуальное восприятие, прежде всего. А справочную информацию, для общего случая, давать постольку - поскольку. Впрочем, я не настаиваю. Мы все – в одинаковых условиях. Я могу кого-то, случайно, обидеть и меня, тоже, уже не случайно :) .
Короче, для того тусовки и существуют, чтобы разрешать «непонятки» путём споров и дискуссий…
В ряде случаев ImageMagick, а точнее ее более новую версию "Graphic Magick" вполне может заменить простая программа на питоне с использованием библиотеки PIL. Зачем? Выигрыш в скорости работы минимум в десяток раз. Хотя GM более универсальный инструмент, тут не поспоришь. У меня бывают случаи, когда нужно изменить размер кучи изображений, количество которых может достигать сотен тысяч (и это не кадры с видео), и они все разные по разрешению, вот нужно привести все к одному виду, вот тут то скорость и видна даже не на глазок. Возможно, это не со всякими изображениями так работает, да и возможности обработки не очень большие, но что есть то есть.
В ряде случаев ImageMagick, а точнее ее более новую версию “Graphic Magick” вполне может заменить простая программа на питоне с использованием библиотеки PIL. Зачем? Выигрыш в скорости работы минимум в десяток раз.
Насчет «Graphic Magick» – спасибо! Буду иметь в виду.
А PIL’ом я как раз и пользуюсь, чтобы рисовать субтитры на полупрозрачную подложку. Более того, например, также, чтобы стереть оригинальные (белые) субтитры, для замены их своими. Для этого я меняю белый пиксель на средневзвешенный цвет окружающих его не белых точек.
Или, вот, возьмем такую тему, как рисование блок-схем. Стандартные средства есть, но мне не понравились. Поэтому, быстро наваял скрипт на Питоне, который по заданным параметрам строит нужные диаграммы (без каких-либо импортируемых модулей). Вот пример, такой блок-схемы:

перекодировать видео из H264/H265 в контейнер WebM с кодеком VP9
Аппаратная поддержка H264 нынче встроена в любую лампочку, а вот потянет ли эта лампочка программное декодирование VP9 — большой вопрос
ffmpeg -i ./input.mp4 -c:v libvpx-vp9 ./output.webm
На видео с переменной частотой кадров ffmpeg любит иногда эту самую частоту портить, поэтому на всякий случай усмиряю его опциями -fps_mode:v passthrough и -enc_time_base:v demux чтобы не выпендривался
(ещё в каких-то старых версиях ffmpeg любил портить цветовое пространство, но сейчас воспроизвести не могу, возможно починили)
вытаскивание скриншота из видео
Тут уж проще использовать функцию создания скриншота, встроенную в видеоплеер
Но мы так теряем в качестве
Через ffmpeg вы тоже теряете качество дважды: во-первых, из-за преобразования цветового пространства (хотя на BT.709 это незаметно, потому что оно почти идентично sRGB), а во-вторых, из-за jpg
ffmpeg -i ./input_video.mp4 -vn -c:a copy ./audio.mp3
Что-то я очень сильно сомневаюсь, что аудио в видеофайле было закодировано именно в MP3. Вы проверяли, что за файл получается на выходе на самом деле? (Впрочем, если там не MP3, то мой ffmpeg ругается Invalid audio stream)
И вместо -vn наверно лучше использовать что-то вроде -map 0:a:0 чтобы быть уверенным, что на выходе ровно один аудиопоток и никакого мусора вроде встроенных субтитров
обратно в SVG сконвертировать не получится
Я бы посмотрел у кого получится 🙃
Для более быстрого итерирования
Ограничьте длительность выходного файла опцией -t, нет необходимости ждать полного перекодирования, чтобы просто проверить попадание координат текста
Я хочу выводить видео прямо в терминал
mpv --vo=tct (я бы ещё сказал mpv --vo=caca но в моей сборке mpv он почему-то недоступен)
Благодарю за дельные замечания к содержанию статьи! Поставил бы плюс, но карма не выросла :)
Прокомментирую часть из Вами написанного:
Аппаратная поддержка H264 нынче встроена в любую лампочку, а вот потянет ли эта лампочка программное декодирование VP9
Не согласен:
Intel QSV поддерживает декодирование VP9 очень давно (см., например, статью от самих Intel на Хабре от 2016 года);
NVIDIA поддерживает декодирование VP9 начиная с поколения Pascal, то есть с 2016 года (см. официальную таблицу поддерживаемых фич);
AMD в этом смысле запоздали, но в последних поколениях поддержка VP9 тоже имеется (см. официальную таблицу поддерживаемых фич);
Мобильные GPU не могут не иметь аппаратной поддержки VP9, потому что тогда видосики с ютуба сжирали бы батарею и стали бы заметной проблемой. Я в 2026 году в это просто не поверю.
Энкодеры являются гораздо большей проблемой, нежели декодеры - что в программных реализациях, что в аппаратных. Энкодеры (производители контента) нужны не везде, а декодеры (потребители) нужны как раз в любой современной лампочке :)
Тут уж проще использовать функцию создания скриншота, встроенную в видеоплеер
Зачастую - да. Но я не один раз напарывался на проблему, когда всё время на 1-2 кадра не то что нужно - ползунок недостаточно чувствительный. И в такой ситуации вытащить серию скриншотов за целую секунду, как я показал в статье, мне оказывалось гораздо проще.
Через ffmpeg вы тоже теряете качество дважды: во-первых, из-за преобразования цветового пространства (хотя на BT.709 это незаметно, потому что оно почти идентично sRGB), а во-вторых, из-за jpg
Не спорю, просто посчитал это слишком детальными нюансами и убрал из статьи перед публикацией. Это уже следующий уровень тюнинга, а я хотел сосредоточить внимание на самом подходе.
Я в 2026 году в это просто не поверю.
Устройства десятилетней давности никто не отменял, у меня ноутбук 2014 года и телефон 2017 года
Из новенького в Raspberry Pi 5 даже H264 забыли положить, там только H265; множество другой ARM-рассыпухи, не связанной с телефонами и тв-приставками, тоже умеет только H264 и иногда H265 (поэтому я и пишу про лампочки, а не про NVIDIA)
Хм, хорошо, согласен. Я сфокусировался на основном секторе потребительских устройств, но это действительно не лампочки для энтузиастов.
Из новенького в Raspberry Pi 5 даже H264 забыли положить, там только H265
Я, кстати, этому сильно удивлён. У 265, насколько знаю, сложная патентная схема для отчислений, тогда как у 264 патенты уже истекли. А VP9 - вообще открытый формат, не требующий роялти.
ползунок недостаточно чувствительный
mpv умеет перематывать покадрово клавишами запятая и точка (ютуб внезапно тоже умеет)
В VLC следующий кадр по умолчанию на E, предыдущий кадр почему-то не завезли
декодирование VP9
И даже если поддерживает, далеко не факт, что туда завезли кодирование. У потребительских карт Nvidia, например, оно не поддерживается, только H264/265 и AV1.
Кодировать видео аппаратно имеет смысл только если труб горят. Оно ощутимо проигрывает процессорному по битрейту даже на околостандартных пресетах.
Конкретно у меня был кейс Remote Desktop, то есть это real-time сжатие, с минимально возможной задержкой. Тут уж не до хорошего :) Современная графическая архитектура такова, что фрейм с рабочим столом стартует из видеопамяти. Readback из VRAM - долго и тяжело для шины, это просто похороны в данном случае.
А вообще согласен, аппаратные энкодеры (уж тем более на фоне декодеров) необходимостью назвать не готов.
Remote Desktop
Та же Aspia программно кодирует и столь же программно декодирует VP9, вроде норм (хотя не для игр конечно)
Сделал к статье пост-скриптум и отметил там ваш комментарий как важное дополнение. Надеюсь, Вы не возражаете :)
Железо Эппл (айфон + макбук). Снимаю видео в LOG формате, хочу применить lut и слегка повысить контрастность и насыщенность. Я так и не нашел как это сделать через ffmpeg, чтобы работало с приличной скоростью. Утилита Compressor (с gui) либо Давинчи справляются в десятки, а то и сотни раз быстрее. Плюс в Давинчи и монтировать можно.
Но ffmpeg хорош чтобы быстро перегонять записи видео стримов (которые нельзя скачать). Ну или ту же музыку к единому формату приводить.
С удовольствием бы подключился к решению проблемы, но с железом Apple у меня как юзера отношения не складываются :) Есть планы поработать с их SDK из любопытства, но это бэклог.
Мой единственный (отдалённо) релевантный опыт в данном вопросе - портирование нативного клиента на C (GTK) под macOS. Там использовал декодеры videotoolbox для вывода на экран изображения удалённого рабочего стола (Remote Desktop а-ля SPICE).
То есть вы вместо того, чтобы "пальцем ткнуть" в гуе, где написать надпись и каким шрифтом, делаете несколько итераций через командную строку с просмотром результатов опять в гуе?
Не, пакетная обработка и использование в скриптах - да, это задача для CLI. Да и то, гуёвые инструменты для пакетной обработки вполне себе имеются. Но использоваться CLI для интерактивной обработки - это именно что в гамаке и стоя.
Если уж на то пошло, то я скину фото/скрин себе в Телеграм и напишу/нарисую всё что нужно с телефона, пальцем.
Возвращаясь конкретно к Вашему вопросу, я специально для ответа на него сделал в статье раздел "А что это всё даст?". Вопрос не в том, что итерироваться через командную строку проще - конечно же, это не так, - а в том, что в случае, когда я работаю в CLI, проитерироваться на месте в совокупности быстрее и дешевле (по усилиям), чем переходить в GUI, перестраивать себя под абсолютно иную парадигму взаимодействия с компьютером, а потом возвращаться обратно.
Да, контринтуитивно. Да, вкусовщина. Я поэтому специально оговорился, что не считаю свой путь единственно верным и призываю лишь попробовать.
На вкус и цвет все инструменты разные.
переходить в GUI, перестраивать себя под абсолютно иную парадигму взаимодействия с компьютером, а потом возвращаться обратно.
Так вы пока итерации гоняете по выбору координат и размера шрифта, не один раз туда-сюда переключитесь. Вы же не в ascii картинки смотрите?
Таскать хэндлы в графическом редакторе или повторять последнюю команду терминала с мелкими правками? Каждый шкодит как он хочет :) Я умею и так и так, но если сижу в терминале, то предпочитаю из него не выходить. Конечно, специально в терминал из условного командного чата я ради такой задачи вряд ли полезу.
Так в графическом редакторе вы сразу видите результат и вам не надо каждый раз скакать между cli и gui для просмотра результата вашей команды.
Несколько подходов к упражнению - и глаз уже намётан и я с первого-второго раза получаю то, что мне нужно.
А проверить результат не выводя свою бионейросеть из режима работы с терминалом - не так уж и сложно:
Вызываете в терминале
xdg-open file(для macOS - простоopen) и видите свой файл, открытый приложением по умолчаниюНажимаете ESC (или другую клавишу) и выходите из приложения - Вы снова в терминале
GUI, конечно, все равно появится, когда надо будет вернуться обратно в Slack/Mattermost/Telegram/choose-your-fighter (если мы всё ещё про кейс с текстом на фото трещим). Но драг-дроп для меня приемлем в этом смысле.
Да, я в терминале наберу ffmpeg -i 1.mp4 -i 2.mp4 -codec copy 3.mp4 быстрее, чем в гуи это все накликаю (во многих того же copy просто нет, кстати). Постигается упражнением.
И где тут интерактивность?
Так а зачем интерактивность в кодировании видео? Интерактивность при работе с видео нужна только при его монтаже. При кодировании она антиполезна зачастую, потому что обычно под капотом все равно ffmpeg, а он при прямом управлении справляется лучше (все настройки доступны по определению, а не то, что разработчик гуя соизволил положить).
Я с видео каждый день работаю, если что :)
По возможности, из Premiere Pro всегда выгоняю ProRes HQ, а потом уже его кодирую во что мне нужно ffmpeg-ом. Да и через пару месяцев пользования ffmpeg-ом все задачи уже закрываются готовыми скриптами, перетяни на него файл просто и все.
Недавно перегнал всю коллекцию записей формулы 1 через ab-av1 с ffmpeg под капотом в av1, минус 50% в весе без заметной потери качества :)
Если бы в ffmpeg была поддержка шейдеров пост-обработки или просто фильтр для транскодирования с указанием файла шейдеров, то было бы совсем универсально.
Я никогда так не делал, но в FFmpeg есть поддержка libplacebo. Возможно, это для Ваших целей как раз подойдёт. Вот документация
В армии есть такое развлечение - зубной щёткой плац мести. Без богомерзких тяжеловесных мётел…
Спасибо огромное автору за пример с расширенным эквалайзером! Я немного модифицировал скрипт с помощью чата гпт, притащил ноут в свою диджейку, воткнул в него цифровой выход с пульта и вывел на экран визуализацию звука с мастера. Теперь сижу слушаю музыку в колонках и наглядно сравниваю спектры и панораму одних и тех же записей со стриминга, с винила и с cd, очень увлекательно!
Хочется поставить жирный плюс, да кармы нетути :(
Ох! Помню я хотел что-то сделать ffmpegом... Какое-то конвертирование... На форумах шло обсуждение командных строк как алхимических рецептов. И получилась дудочка и кувшинчик - если видео кодируется нормально, то пропадает аудио, если аудио остается - то видео с полосами какое-то... Не помню чем закончилось, возможно VirtualDubом...
Заклинания действительно надо применять с осторожностью. Стандартные настройки и профили - не просто так стандартные. Я как-то раз закодировал видео по медленному пресету, так оно получилось H264 уровнем L7, который в принципе аппаратно не декодируется. Просто разваливалось на макроблоки при движении. Репу долго чесал :)
а скажут что опять в этом линуксе все через командную строку ;) Виндузятников иногда легко впечатать тем что kdenlive/shortcut просто запускается с флешки. а его базового минимума хватает для не самых простых задач. Черная магия требуется скорее для инсталляции pinncle etc. - сложных коммбайнов которые валяться от чиха.
Пусть говорят ;) А звучать это будет странно - хотя бы потому, что синтаксис FFmpeg одинаковый и на пингвинах, и на окошках, и на маковых.
kdenlive/shortcut просто запускается с флешки
Вы про AppImage-дистрибутивы, я так понимаю? Которые при запуске с основного диска монтируются как отдельная файловая система?
Черная магия требуется скорее для инсталляции pinncle etc.
Как-то раз я установил себе на Fedora 1С. Да, он существует для Linux, только тащит за собой всё вплоть до libstdc++ :D JetBrains, насколько понимаю, действуют примерно так же
Самое интересное не рассказали: Как сохранять в один файл потоковое видео из медиа-сервисов(ютуб, рутуб и т.д.)?
Согласен с тем, что это интересный кейс с точки зрения полноты введения в FFmpeg. Почему его нет в статье? Всё просто: ни разу не пользовался.
Если есть желание, приглашаю сделать дополнение в Вашем же комментарии. Плюсану, сделаю в статье UPD с пометкой что Вы сделали важное дополнение.
как сказали в коменте ниже yt-dlp
видео с ютуба мы через веб-плагин скачать смогли.
Извращенец! А как же командная строка и yt-dlp?
Только не кидайтесь субстанциями: ни разу yt-dlp не использовал :)
Если есть желание, можете раскрыть сценарий применения yt-dlp + ffmpeg здесь, в комментариях. Я добавлю в статью как важное дополнение (сделал UPD в конце)
если уж речь пошла о вырезании аудиодорожки из скачанного с ютуба видео, то нельзя обойти вниманием ещё один инструмент командной строки – а именно yt-dlp. как ffmpeg служит перочинным ножиком для всего, что связано с перекодированием картинок, звука и видео (разве что кофе варить не умеет), так yt-dlp – универсальный солдат для скачивания видосов с YouTube (и тысяч других сайтов). если раньше я действовал как автор статьи (т.е. скачивал видео через какой-нибудь сайт или расширение и потом ffmpeg'ом вырезал аудиодорожку или фрагмент видео с нужной репликой персонажа), то теперь не мыслю себя без yt-dlp.
утилита опенсорсная, кроссплатформенная, проживает здесь, инсталлятора не имеет, да он и не нужен – просто качаешь файл для своей платформы и кидаешь в удобное место, также понадобится скачать зависимости (тот самый ffmpeg и deno или аналогичный рантайм для разбора джаваскрипта). в линуксе вроде надо добавлять репозиторий, точно не подскажу, но в винде всё просто ставится через winget: winget install yt-dlp.yt-dlp.nightly (желательно ставить именно nightly версию, потому что ютуб постоянно пытается поломать скачивальщики, а они пытаются адаптироваться – такие вот кошки-мышки. вингет сделает всё сам – подтянет зависимости, пропишет команды, добавит что нужно в PATH, одна команда – и готово.
установили, можно качать:
yt-dlp https://youtu.be/dQw4w9WgXcQ
это самый простой пример использования, будет скачано видео и аудио (ютуб хранит их отдельно) в максимальном качестве, потом дорожки будут склеены с помощью ffmpeg.
если вам нужно видео в 360p, то не обязательно тянуть 4K, а потом перекодировать. можно посмотреть список доступных форматов (ключ -F):

yt-dlp c ключом -F показывает номера доступных форматов, их размер, кодек, качество (разрешение и фреймрейт для видео; частота дискретизации и битрейт для аудио). выбираем нужные и качаем с помощью ключа -f:
yt-dlp -f 396+251 dQw4w9WgXcQ
автору статьи нужно было вытащить из видео аудиодорожку; для этого можно указать только номер аудиодорожки в ключе -f или использовать -x:
yt-dlp -f 251 dQw4w9WgXcQ
yt-dlp -x dQw4w9WgXcQ
впрочем, указание конкретного формата – не совсем правильно. правильнее указать максимальное качество какого-то конкретного кодека:
yt-dlp -f "bestvideo[ext=webm]+bestaudio[ext=m4a]/best" dQw4w9WgXcQ
или ограничить разрешение видео (bestvideo и bestaudio можно заменить на bv и ba соответственно):
yt-dlp -f "bv[height<=480]+ba/b" dQw4w9WgXcQ
чуть более продвинутый пример скачивания аудио с перекодированием:
yt-dlp -x --audio-format mp3 --audio-quality 320k --embed-thumbnail --embed-metadata -P "%USERPROFILE%/Music" -o "%(title)s.%(ext)s" dQw4w9WgXcQ
-x – скачать только аудио; --audio-format – в какой формат перекодировать; --audio-quality указывает битрейт (также можно указать качество перекодирования "в шакалах" от 0 до 10); --embed-thumbnail и --embed-metadata соответственно встраивают в mp3 превьюшку с ютуба и данные о песне для отображения в плеере; -P указывает, куда класть конечный файл, а -o – как его назвать (по умолчанию yt-dlp добавляет ID видео к имени файла; указанный в команде формат позволяет этого избежать).
если вам нужны только несколько секунд из ролика, опять же, не надо качать его целиком, можно вырезать нужную часть:
yt-dlp --download-sections "*00:01:30-00:01:45" dQw4w9WgXcQ
кстати, заметили, что в примерах выше нет полной ссылки? для ютуба достаточно указать ИД видео (или плейлиста, кстати – тогда будет качаться весь плейлист), для остальных сайтов придётся всё-таки давать полную ссылку.
ютуб может не отдавать видео без входа на сайт (например, у ролика ограничение по возрасту, или у вас приватная ссылка, доступная только вашему аккаунту, либо у вас есть премиум и вы хотите скачать премиум-видео, да просто ютубу может не понравиться ваш IP-адрес). в этом случае надо передать yt-dlp куки, чтобы подтвердить свою личность. проще всего это делать с помощью файрфокса – войти в браузере и в yt-dlp использовать ключ --cookies-from-browser firefox (с хромом и тому подобными этот трюк не работает, там надо вытаскивать куки в файл и использовать ключ --cookies cookies.txt).
возможностей у yt-dlp гораздо больше, я лишь поскрёб самую поверхность. естественно, эта утилита – не волшебная палочка и не инструмент для хакинга, она не скачает удалённый ролик, видео, к которому у вас нет доступа, или видео с географическими ограничениями. ну и конечно, если вам повезло жить в самой прекрасной стране на свете, вам нужен либо туннель, либо подкоп и прочее удобное средство доступа к информации, в крайнем случае ТОР (если что, yt-dlp умеет в прокси):
yt-dlp --proxy socks5://127.0.0.1:9150 dQw4w9WgXcQ
ну и напоследок, если прекрасно работавшая утилита вдруг перестала качать и начала выдавать ошибку, первым делом попробуйте её обновить:
yt-dlp -U
Красота, спасибо большое! Плюсанул, в статье отметил, комментарий закрепил.
У меня вполне себе работает –cookies-from-browser chrome, только требует, чтобы я сначала закрыл Chrome, иначе yt-dlp не может получить доступ к файлу с куками.
Очень удобно, кстати, вот так `yt-dlp -xhttps://youtu.be/XXxXxxXxxXX` скачивать аудио-дорожку некоторых youtube-подкастов (где картинка не нужна), а потом сразу по sftp на телефон в нужную папку закидывать для прослушивания позже.
Как вы себе представляете групповую операцию для любого из сценариев выше? Или, скажем, для снимков фотосессии?
Я не верю, что такого нет. Если это реально нужно, то оно есть с 99% вероятностью
В гуи объективно удобнее работать, видя сразу результат
Как и вся статья, мой ответ вам будет чистым ИМХО.
Я не верю, что такого нет. Если это реально нужно, то оно есть с 99% вероятностью
Я не спорю, что оно ГДЕ-ТО есть. Вот это самое ГДЕ-ТО нужно искать: искать в интернете про разные ПО, пробовать что-то устанавливать, тыкать, удалять не понравившееся. А зачем, если у меня уже есть способ, который меня устраивает?
Если уж совсем по-честному, то я пробовал и не нашёл. Раньше на Windows был Sony Vegas с крякой, но это было как из пушки по воробьям.
В гуи объективно удобнее работать, видя сразу результат
Для этого в статье есть целый раздел "А что это всё даст?". + дискутировали с другим хабротоварищем вот в этой ветке комментариев. Изолированно сравнивать GUI и CLI без контекста - зачем? Конечно, GUI побеждает засчёт интерактивности и WYSIWYG. Но я объясняю свою позицию не в рамках вакуума, а применительно к своей работе (см. в дополнение к ссылке выше вот здесь).
я пробовал и не нашёл
Что именно?
А зачем, если у меня уже есть способ, который меня устраивает?
Написать самому под конкретную задачу? Прелестно. Только никакой гибкости тут и не пахнет, любые изменения (как те же координаты текста) это множественные правки, когда в гуи я просто переношу куда надо а возможно и другие элементы под него параллельно подстраиваю
дискутировали с другим хабротоварищем вот в этой ветке комментариев.
Вы пришли в итоге к рекомендации затерпеть)
Но вы же прибегаете к использованию регулярных выражений, а не обрабатываете строки каждый раз через стандартную библиотеку языка C, верно?...
Как раз вы этой обработкой через библиотеку языка си и занимаетесь) Потому что регулярные выражения пишутся напрямую в гуи вскода скажем. Вот эти намеки на то что люди имеют сложности с тем чтобы перевести курсор куда-нибудь это прям сильно было. Вы игнорируете очевидную необходимость при использовании клавиатуры сидеть в кресле по струнке, когда мышь я могу одной рукой держать и лениво двигать. Для нашей работы отвлечение от клавиатуры даже полезно
Когда надоест красноглазие, знайте, что для всего этого есть открытый кроссплатформенный avidemux.
ЗЫ: Если всё таки вам реально нужно транскодирование (не для превью), лучше использовать проприетарные кодировщики.


Зачем мне фото- и видеоредакторы с GUI, когда есть FFmpeg?