Программа для пакетной обработки видео: папка целиком за один запуск

В папке триста роликов. Каждому нужны одни и те же правки: привести к одному размеру, убрать звук, обрезать кадр. Это и есть пакетная обработка видео: настройки задаются один раз, а обрабатывается сразу вся папка. Путей три: запускать свою команду в цикле, ставить файлы в очередь заданий программы или обрабатывать папку программой с массовым экспортом. Первые два делают одну правку для всей папки, третий — разные копии каждого ролика. Готовые команды для всех трёх правок, для конвертации, сжатия и интро — в разделе о первом пути.

Дальше — четыре случая, когда обработка ошибается без предупреждения. Там же — команда проверки результата. Она печатает список подозрительных файлов, и открыть придётся только их.

Обработка по рекомендуемому рецепту из первого раздела заняла у нас примерно вдвое меньше времени, чем длятся сами записи. Мы обработали десять роликов нетронутой съёмки: 11 минут 56 секунд записи, 1,1 гигабайта. По заголовкам файлов каждый ролик длится 69-77 секунд. Обработка заняла 6 минут 23 секунды, по 38 секунд на файл. При 38 секундах на файл триста таких роликов займут около трёх часов. Точное время измерьте на пяти своих файлах. Роликов другой длины мы не мерили: по заголовкам все десять около семидесяти секунд.

Настоящей записи в этих файлах на 26 секунд меньше, чем указано в заголовках. У одного ролика в заголовке стоит неверная длительность, этот случай разобран ниже. Время зависит не только от длины. В другом запуске того же рецепта четыре ролика с одного аппарата, одного разрешения и почти одной длины обрабатывались от 53 до 149 секунд. Компьютер в том запуске был занят другой работой. Дольше всех обрабатывались два ролика с меткой поворота.

Кто и на чём мерил. Замеры делали мы, разработчики Video Unique Booster: основной — 23 сентября, остальные проверки — 26 сентября 2026 года. Ролики взяли из открытого научного набора EVA-7K ¹⁸. Это съёмка со смартфонов, собранная для проверки подлинности видео. Мы брали только нетронутые ролики — прямо с камеры. Копии, пересохранённые редакторами, в наборе лежат отдельно, их мы не трогали. Компьютер — процессор Intel Core i5-12400F и 32 гигабайта памяти. FFmpeg — сборка от 21 июля 2024 года. На другом процессоре секунды будут другими.

Важнее другое. Те же десять роликов мы обработали второй раз короткой командой без сохранения пропорций. Такую команду обычно пишут первой. Вертикальными и в файле, и на экране вышли только два файла из десяти, причём случайно. Остальные восемь инструмент пометил так, что плеер разворачивает их обратно в горизонтальные. Работа сделана впустую. Предупреждения не было ни одного: коды возврата нулевые у всех десяти.

Кому это нужно

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

Вот как люди описывают это сами. «Есть коллекция видеофайлов из 1023 штук. Все лежат в одной папке», — и дальше: «сделать скриншот на 7 секунде из каждого файла» ⁴. «Используем в своем проекте для обработки более полутора тысяч видео» ⁵. Человек, который ведёт марку одежды, каждый день делает ролики для сотни с лишним товаров ⁶.

Такой объём работы был у нас в сетке Instagram примерно на 300 аккаунтов с марта по август 2025 года. Каждый аккаунт публиковал по три Reels в сутки. Для каждой публикации делалась своя уникальная копия ролика. Только на 217 аккаунтах, по которым у нас остался снимок статистики, опубликовано 6690 Reels. Обрабатывали мы эти ролики всегда всей папкой за один запуск, по одному — никогда.

Не нужно тем, у кого два-три файла: настройка окупается числом файлов, которые пойдут следом.

Уникализатор видео для Windows: сотни копий за запускВручную Вы правите копию за копией. Программа создаёт их пачкой. У каждой свои картинка, звук, метаданные и длительность.

Уникализатор видео Video Unique Booster для WindowsВы кладёте видео и задаёте диапазоны настроек. Программа создаёт сотни копий. У каждой свои картинка, звук и длительность.

Уникализатор видео: сотни копий из одного оригиналаРучной способ упирается в одно. Каждую копию надо править отдельно. Больше копий — больше времени.

Уникализатор видео для TikTok, YouTube и InstagramДиапазоны настроек Вы задаёте один раз. Дальше программа для Windows создаёт копии пачкой. Сотнями за запуск.

Уникализатор видео для Windows — Video Unique BoosterВы добавляете одно видео. Программа создаёт сотни копий. У каждой свои картинка, звук, метаданные и длительность.

Что понадобится

Папка с исходниками и место на диске. В замере ниже рекомендуемый рецепт дал 0,44 от веса исходников — 484 мегабайта против 1102. Но общая цифра тут обманчива: самый тяжёлый файл вышел в 1,14 раза больше своего исходника. Считайте место на диске по худшему файлу и берите двойной запас. После короткой команды из раздела про брак файл ролика 800×480 стал тяжелее в 1,76 раза. У вас другие исходники и другая правка, поэтому и рост веса может быть другим.

Дальше — три пути по порядку.

Путь первый: FFmpeg и цикл по папке

На этом пути больше всего ручных настроек, поэтому раздел подробный.

Инструмент один и бесплатный — FFmpeg ¹². Рецепты ниже написаны для Windows, для оболочки PowerShell. Как быть на macOS и Linux, сказано в конце раздела.

Установщика у FFmpeg нет, а на сайте проекта лежит только исходный код. На готовые сборки для Windows там стоят ссылки на два сайта, один из них — gyan.dev ¹⁹. Скачайте там архив ffmpeg-release-essentials.zip. Внутри лежит одна папка с номером версии в имени, например ffmpeg-9.0.2-essentials_build, а в ней папка bin с программой ffmpeg.exe. Распакуйте архив на диск C: и переименуйте эту папку в ffmpeg. Тогда программа будет лежать в C:\ffmpeg\bin. Путь к этой папке надо дописать в переменную PATH, иначе PowerShell программу не найдёт. Это делает одна команда:

[Environment]::SetEnvironmentVariable('Path', [Environment]::GetEnvironmentVariable('Path', 'User') + ';C:\ffmpeg\bin', 'User')

Закройте окно PowerShell и откройте новое. Чтобы проверить установку, наберите команду ffmpeg -version — она должна напечатать номер версии.

Команды запускаются из папки с роликами. Перейдите в неё: cd D:\video, где D:\video — ваша папка.

Команда обрабатывает один файл. Цикл оболочки подставляет в неё все файлы папки по очереди. Вот рекомендуемый рецепт: он приводит все ролики к вертикали 1080×1920 с полями.

$video = '.mp4', '.mov', '.avi', '.mkv', '.3gp'
New-Item -ItemType Directory -Force out
Get-ChildItem -File | Where-Object { $video -contains $_.Extension } | ForEach-Object {
    ffmpeg -y -i $_.FullName -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" -c:a copy "out\$($_.BaseName).mp4"
}

В первой строке перечислены расширения, которые берёт цикл. Маска *.mp4 тут не годится. В том же наборе EVA-7K 140 нетронутых роликов: 84 в .mp4, 52 в .mov и 4 в .3gp. Цикл по *.mp4 молча пропустил бы 56 из 140. Мы проверили оба варианта на смешанной папке, где лежали .mp4, .mov, .3gp, .avi и .mkv. С маской вышло 2 файла из 6, со списком — все 6. Если в папке есть другие форматы, допишите их в список.

Каждый результат рецепт сохраняет в .mp4. Поэтому два исходника с одним именем, a.mov и a.mp4, дадут один out\a.mp4: второй перезапишет первый. Такую потерю ловит счёт файлов на входе и выходе, о нём ниже.

Удаление звука и обрезка кадра добавляются в ту же команду. Вот все три правки разом:

$video = '.mp4', '.mov', '.avi', '.mkv', '.3gp'
New-Item -ItemType Directory -Force out
Get-ChildItem -File | Where-Object { $video -contains $_.Extension } | ForEach-Object {
    ffmpeg -y -i $_.FullName -vf "crop=iw*0.9:ih*0.9,scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" -an "out\$($_.BaseName).mp4"
}

Ключ -an убирает звук и стоит вместо -c:a copy. Обрезка crop=iw*0.9:ih*0.9 стоит в строке -vf первой, перед scale. Здесь iw и ih — ширина и высота исходного кадра. Команда оставляет середину кадра, 90% по каждой стороне, то есть срезает по 5% с каждого края. Доли годятся для папки с разным разрешением, а числа в пикселях — нет. Мы проверили эту команду на той же смешанной папке: обработаны все 6 файлов из 6, у всех 1080×1920 и нет звука.

Ключ -y заранее отвечает «да» на вопрос о перезаписи: без него на втором запуске программа спросит, и обработка остановится до ответа ⁴.

Строка с New-Item создаёт папку для результата. Без неё FFmpeg выдаст ошибку на каждом ролике. Цикл при этом не остановится: на неудачном запуске внешней программы PowerShell его не прерывает.

Короткий вариант scale=1080:1920 портит кадр двумя способами. Если у исходника есть метка формы пикселя (SAR), команда помечает файл так, что плеер разворачивает его обратно в горизонтальный. Если метки нет, команда меняет саму картинку. Оба случая разобраны в разделе «Брак, который выглядит готовым». Там же один кадр показан в трёх видах: исходник, то, что лежит в файле, и то, что показывает плеер.

Здесь вы управляете каждой настройкой, но и следите за каждой сами: «Целое море всевозможных косяков с кодированием вылезло» ⁵.

Этим путём шли и мы: до Video Unique Booster ролики для сеток аккаунтов мы обрабатывали собственными скриптами. Собирать такие скрипты самим утомительно, и это одна из причин, по которой мы взялись за свою программу. Наши скрипты молча пропускали часть файлов папки: с другим расширением или повреждённые. Узнавали мы об этом только по числу готовых роликов, и потом скрипты приходилось исправлять.

Типовые ошибки:

• цикл перебирает папки вместо файлов, и часть исходников остаётся необработанной;
• расширения перечислены неверно, и часть файлов молча выпадает из обработки;
• вопрос о перезаписи остаётся без ответа, и обработка ждёт ответа.

Первые две ошибки проходят без сообщений: цикл завершается, а файлы обработаны не все.

В поисковой выдаче чаще, чем скрипты PowerShell, встречаются .bat-файлы для старой командной строки cmd. Мы взяли PowerShell. Он есть в каждой Windows 10 и 11. Список расширений и проверки в нём пишутся проще.

Если ролики лежат по подпапкам, в рецепте меняется одна строка, третья: Get-ChildItem -File -Recurse | Where-Object { $video -contains $_.Extension -and $_.Directory.Name -ne 'out' } | ForEach-Object {. Ключ -Recurse заходит в подпапки, а условие про out не даёт взять в работу прошлые результаты. Все результаты сохраняются в одну папку out, поэтому ролики с одинаковыми именами из разных подпапок перезапишут друг друга. Это покажет счёт файлов. Мы проверили эту строку на папке с двумя подпапками: взяты все три ролика, а прошлый результат из out в обработку не попал.

Ту же замену — -Recurse и условие про out — сделайте во всех блоках ниже, где стоит Get-ChildItem -File: в проходе на чтение, в обходе папки, в сверке и в цикле продолжения. Иначе они увидят только верхнюю папку, и счёт не покажет перезапись.

На macOS и Linux команда FFmpeg та же, меняется только цикл. Вот он для оболочки bash:

shopt -s nullglob nocaseglob
mkdir -p out
for f in *.mp4 *.mov *.avi *.mkv *.3gp; do
    ffmpeg -y -i "$f" -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" -c:a copy "out/${f%.*}.mp4"
done

Первая строка нужна для двух случаев. Без неё цикл передаст инструменту имя *.avi, если таких файлов в папке нет, и получит ошибку. Кроме того, без неё цикл пропустит файл с расширением .MOV в верхнем регистре. В macOS оболочка по умолчанию другая, zsh, и строку shopt она не знает: сначала наберите bash. Мы проверили этот цикл в bash 5.2 под Windows на той же смешанной папке. Взяты все шесть файлов и седьмой, G.MOV. На самих macOS и Linux мы его не запускали.

Конвертация и сжатие тем же циклом

Для конвертации в другой формат и сжатия меняется только середина команды:

$video = '.mp4', '.mov', '.avi', '.mkv', '.3gp'
New-Item -ItemType Directory -Force out
Get-ChildItem -File | Where-Object { $video -contains $_.Extension } | ForEach-Object {
    ffmpeg -y -i $_.FullName -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k "out\$($_.BaseName).mp4"
}

Ключ -c:v libx264 переводит видео в кодек H.264, а -c:a aac — звук в AAC. Силу сжатия задаёт -crf: чем число больше, тем файл меньше и картинка грубее. Число 23 кодировщик ставит сам, если его не задать. Это видно по служебной строке готового файла: там записано crf=23.0.

Мы проверили этот рецепт на тех же десяти роликах 26 сентября 2026 года. С -crf 23 папка в 1,1 гигабайта стала весить 660 мегабайт — 0,60 от исходного. Но легче стал не каждый файл. Один ролик почти не сжался: 0,98 своего веса. Другой стал тяжелее исходника: 1,12. Оба сняты на улице. С -crf 28 та же папка стала весить 349 мегабайт — 0,32 от исходного. Легче стали все десять файлов, а хуже всех сжался ролик, который при -crf 23 стал тяжелее исходника: 0,64 своего веса.

Конвертация заняла столько же времени, сколько рекомендуемый рецепт, запущенный в тот же час: одна обработка шла 66 секунд на файл, другая — 68. Это дольше 38 секунд основного замера: в этот час компьютер был занят другой работой.

Отсюда правило: сверяйте вес каждого файла, а не всей папки. По общей цифре не видно ролика, который после сжатия стал тяжелее. Сверка из раздела про брак отмечает такие файлы сама.

Интро в начало каждого ролика

Положите интро в подпапку intro под именем intro.mp4 и запустите из папки с роликами:

$video = '.mp4', '.mov', '.avi', '.mkv', '.3gp'
$fit = 'scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2,setsar=1,fps=30'
$snd = 'aresample=48000,aformat=channel_layouts=stereo'
New-Item -ItemType Directory -Force out
Get-ChildItem -File | Where-Object { $video -contains $_.Extension } | ForEach-Object {
    ffmpeg -y -i intro\intro.mp4 -i $_.FullName -filter_complex "[0:v]$fit[v0];[0:a]$snd[a0];[1:v]$fit[v1];[1:a]$snd[a1];[v0][a0][v1][a1]concat=n=2:v=1:a=1[v][a]" -map "[v]" -map "[a]" "out\$($_.BaseName).mp4"
}

Склеить можно только куски с одинаковыми параметрами кадра и звука, а у интро и роликов они обычно разные. Поэтому строка $fit приводит оба куска к кадру 1080×1920 с полями и к 30 кадрам в секунду. Строка $snd приводит звук к стерео 48 кГц. Фильтр concat ставит интро перед роликом. Интро лежит в подпапке, чтобы цикл не принял его за обычный ролик.

Мы проверили рецепт на смешанной папке из шести роликов. Интро взяли трёхсекундное, горизонтальное 1920×1080, с другого телефона и с монозвуком 44,1 кГц. У самих роликов было от 24 до 30 кадров в секунду, звук и моно, и стерео. Все шесть результатов вышли длиннее исходников на три секунды: 8,03 секунды при исходных 5,01-5,04. У всех кадр 1080×1920 и стереозвук. Отдельно мы проверили ролик без звуковой дорожки: его рецепт не склеил, файл результата не читается. Такой файл поймает сверка из раздела про брак. Поэтому интро ставьте раньше, чем убираете звук.

Как оставить первые секунды, взять кадр из каждого ролика и поставить водяной знак

Эти правки делает тот же цикл. Меняется только строка с ffmpeg внутри фигурных скобок:

• первые 15 секунд каждого ролика: ffmpeg -y -i $_.FullName -t 15 "out\$($_.BaseName).mp4";
• кадр на 7-й секунде в .jpg: ffmpeg -y -ss 7 -i $_.FullName -frames:v 1 "out\$($_.BaseName).jpg";
• водяной знак в правый нижний угол с отступом 20 пикселей: ffmpeg -y -i $_.FullName -i logo.png -filter_complex "overlay=W-w-20:H-h-20" -c:a copy "out\$($_.BaseName).mp4". Картинка logo.png лежит в той же папке, что и ролики.

Мы проверили все три строки на трёх целых роликах в форматах .mp4, .mov и .3gp и на одном пятисекундном. Отрезок вышел ровно 15 секунд, а пятисекундный ролик остался пятисекундным. Знак встал в правый нижний угол. Кадр на 7-й секунде из пятисекундного ролика не получился вовсе, и ошибки цикл не показал. Такую недостачу видно только по счёту. Сверка ниже считает файлы .mp4, поэтому число кадров сравните с числом роликов сами: (Get-ChildItem out -Filter *.jpg).Count.

Сами команды для одного файла разобраны отдельно: уникализация видео через FFmpeg.

Путь второй: программа с очередью заданий

У этого пути знакомый интерфейс и привычные кнопки. В Premiere Pro и VirtualDub очередь собирается вручную, HandBrake ставит в неё папку целиком.

Задача у людей одна и та же. «Мне нужно у каждого убрать звук, обрезать кадр и немного поднять экспозицию» («I need to remove the audio, crop the frame and slightly up the exposure to each one»), — так описал её участник форума, у которого накопилась папка файлов с одной камеры ⁷.

Ответ в той же ветке типовой: обработать один клип и скопировать его атрибуты на остальные ⁷. В DaVinci Resolve тот же приём называется группами, и его показывают на примере общей цветокоррекции ⁹.

Массовый экспорт в Premiere Pro встроен: готовые клипы уходят в очередь Adobe Media Encoder. Порядок, который советуют на форуме Adobe, такой ⁸:

1. В панели проекта создайте папку (в Premiere она называется bin).
2. Перетащите в неё все клипы.
3. Выделите их все.
4. В окне экспорта выберите диапазон «Source In/Out», то есть от точки входа до точки выхода каждого клипа.
5. Нажмите «Send to Media Encoder». Каждый клип выйдет отдельным файлом.

Звук убирается там же: при постановке клипов в очередь снимите отметку со звуковой дорожки ⁷. Сами мы этот порядок не проверяли, у нас нет Premiere Pro. Учтите и сложность из ветки о тридцати клипах ⁸: у её автора для вертикальной последовательности не нашлось готовой настройки H.264 1080×1920 при экспорте в MP4.

Повторить одни и те же правки на сотне роликов в Premiere Pro помогают надстройки вроде Automation Blocks ⁶.

Бесплатная программа с графическим интерфейсом — HandBrake. Порядок для целой папки в Windows по её документации такой ²⁰:

1. В меню «Tools» откройте «Preferences». В разделе «Output Files» включите «Automatically name output files» и задайте папку для результатов в поле «Default Path». В поле «File Format» должно стоять «Title»: этого документация требует отдельно.
2. Нажмите «Open Source» и выберите папку с роликами. HandBrake откроет её как один источник, где каждый ролик — отдельная запись («Title»). Ролики во вложенных папках он пропускает.
3. Выберите готовую настройку («Preset»).
4. В меню «Queue» выберите «All Selection to Queue»: в очередь встанут все записи.
5. Нажмите «Start Queue».

Названия пунктов — из версии для Windows. На Mac тот же пункт называется «Add Titles to Queue…» и стоит в меню «File», на Linux — «Add Multiple» в меню «Queue».

Этот порядок мы тоже не проверяли. Какие из трёх правок умеет HandBrake, проверьте на пяти своих файлах.

Очередь есть и в старых инструментах: в ролике ¹¹ показан VirtualDub, где задания складываются в список и выполняются одним запуском. Минус у Premiere Pro и VirtualDub общий — список собирается вручную: автор вопроса с тридцатью с лишним клипами не хочет тридцать раз подряд ставить точки входа и выхода ⁸.

Путь третий: программа с массовым экспортом

Настройка задаётся один раз. Дальше папка обрабатывается целиком за один запуск.

Так устроен Video Unique Booster — наша программа. Из каждого ролика она делает уникальные копии. Настройку вы задаёте диапазоном, а каждая копия получает из него своё случайное значение. Так работают яркость, поворот, обрезка краёв, громкость звука и остальные настройки с диапазоном. Кодек, контейнер, частота звука и «Сжатие файла» задаются одни на весь проект. Кодеки на выбор — H.264, H.265, AV1, VP9 и другие, контейнеры — MP4, MOV, MKV, WebM и AVI.

Три правки из начала статьи — вертикаль с полями, удаление звука и обрезку — делают путь первый и второй. Программа устроена по-другому: копия выходит того же размера, что оригинал, а «Обрезать края» срезает с каждой стороны случайное число пикселей и растягивает кадр обратно.

Программа нужна, когда из папки надо получить разные копии каждого ролика. Например, под сетку аккаунтов, где один и тот же ролик публикуется на многих аккаунтах. Число копий задаёт поле «Количество уникальных копий каждого видео»: пять роликов при десяти копиях дают пятьдесят файлов. Раскладка «По наборам» кладёт их в папки pack0, pack1 и дальше, в каждой по одной копии каждого ролика. Так копии удобно раздавать по аккаунтам.

В сетке Instagram, о которой мы писали выше, ручной работы на этом шаге не было. Video Unique Booster сохранял готовые ролики в папку. Программа автопостинга брала их оттуда и публиковала по расписанию.

Программа принимает на загрузку 13 форматов, среди них .mp4, .mov, .avi, .mkv и .3gp. Работает она в 64-разрядных Windows 10 и 11. Настройки хранятся в проекте, результат сохраняется в отдельную папку.

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

После первой загрузки кнопка называется «Загрузить больше видео», и появляется второй способ: папку можно перетащить мышью прямо в список загруженных видео. Готовые файлы по умолчанию сохраняются не в саму папку для сохранения, а в подпапку с датой внутри неё. Там они ещё раз разложены по наборам: так работает режим сохранения, выбранный по умолчанию. Полоса запуска показывает, какой по счёту файл обрабатывается и сколько их всего.

Любой такой инструмент проверяется одинаково и быстро: обработайте пять файлов и посчитайте, сколько вышло.

Массовый режим сам по себе скорости не даёт. Заказчик на бирже фриланса оценил встраивание интро в 100 роликов на VideoPad примерно в 30 часов ³ — это около 18 минут на ролик. Сравнивать с нашими 38 секундами нельзя: там ролики по 3-7 минут против примерно 70 секунд у нас, и интро вклеивают в каждый ролик дважды, в начало и в конец. Вывод из обоих примеров один: время обработки определяют длина записи и сложность правки, а не массовый режим. Скорость измеряйте на своей правке и на пяти файлах, а не на одном.

Четыре случая, когда обработка ошибается без предупреждения

Один нечитаемый файл в середине

Файл номер 47 из 300 повреждён. Что произойдёт?

Вариантов три. Обработка остановится целиком. Или молча пропустит файл. Или появится испорченный результат, который с виду готов. Какой из них случится, зависит от способа обработки и от вида повреждения.

Цикл из первого раздела не остановится: оболочка код возврата не проверяет. В нашем замере FFmpeg не открыл обрезанный файл вовсе. Команда вернула ненулевой код, выходного файла не появилось. Это второй вариант, и узнаёте вы о нём в конце, по числу файлов.

Файл с целым заголовком и повреждёнными данными внутри дорожки даёт третий вариант. Команда вернула нулевой код и записала результат полного размера, у нас 18 мегабайт. Ошибки чтения ушли в поток ошибок: 10 строк. В общем выводе цикла их легко пропустить. Третий вариант бывает и при обрыве обработки, о нём — отдельный раздел ниже.

Поэтому нечитаемые файлы ищут до старта.

Ищет их отдельный первый проход, только на чтение:

$video = '.mp4', '.mov', '.avi', '.mkv', '.3gp'
Get-ChildItem -File | Where-Object { $video -contains $_.Extension } | ForEach-Object {
    ffmpeg -v error -xerror -i $_.FullName -f null -
    if ($LASTEXITCODE -ne 0) { "НЕ ЧИТАЕТСЯ: " + $_.Name }
}

Проход только декодирует файл и ничего не записывает, поэтому занимает меньше времени, чем обработка. Отдельно мы это не мерили. Список негодных файлов вы получаете до старта.

Что именно добавляет ключ -xerror, мы проверили отдельно. Взяли один ролик, сделали из него три испорченные копии, а целый оставили для сравнения. Обрезанный файл и недописанный файл оборванной обработки не открываются вовсе. У этого ролика таблица кадров лежит в конце файла. Без неё файл не читается, и FFmpeg возвращает ненулевой код и с ключом, и без него.

Но таблица бывает и в начале: так файл пишут для показа в сети, ключом -movflags +faststart. Ролик из того же набора, пересохранённый с таблицей в начале, мы тоже обрезали наполовину. Без ключа -xerror проверка вернула нулевой код, с ключом — ненулевой.

Без ключа файл с целым заголовком и повреждёнными данными внутри дорожки проходит проверку с нулевым кодом, хотя в поток ошибок уходит 165 строк. С ключом — ненулевой. Ради этих двух случаев ключ и нужен.

Судите по коду возврата, а не по сообщениям. У целого файла в том же замере в поток ошибок ушло 29 строк, и правило «есть сообщения — значит, файл испорчен» забраковало бы исправный ролик.

В Video Unique Booster проверка стоит раньше — в момент, когда файлы добавляют в список: программа открывает каждый файл и не берёт те, что не открылись. Отклонённые файлы она перечисляет по именам в окне «Ошибки при загрузке видео». Рядом с именем стоит причина, если она известна. Это окно показано ниже.

Программа проверяет контейнер, а не читает файл целиком. Поэтому файл с целым заголовком и повреждёнными данными внутри дорожки она примет. Это тот самый случай, ради которого нужен ключ -xerror. Мы вызвали функцию, которой программа проверяет файлы, на трёх копиях, испорченных тем же способом. Обрезанный и недописанный файлы она отклонила. Файл с повреждением внутри приняла. Поэтому проход с -xerror она не заменяет.

Брак, который выглядит готовым

На выходе триста файлов. Как убедиться, что все триста в порядке?

Вот что показал замер. Мы взяли десять нетронутых роликов из набора EVA-7K, снятых тремя аппаратами: четыре в 1280×720, четыре в 1920×1080 и два в 800×480. Обработали их короткой командой scale=1080:1920, без сохранения пропорций.

Разрешение у всех десяти стало 1080×1920. Но показываются эти файлы по-разному.

У восьми файлов инструмент дописал метку неквадратного пикселя. Внутри файла кадр действительно сжат по горизонтали, но метка велит показывать его в прежних пропорциях, и плеер её исполняет: на экране вы видите исходное горизонтальное видео, а не вертикальное, ради которого всё задумывалось. Программы, которые метку не читают, показывают сжатый кадр. Один и тот же файл выглядит по-разному у разных программ, и ни одна программа не сообщает об ошибке.

Оставшиеся два ролика вышли вертикальными и в файле, и на экране, но заслуги команды в этом нет. У них в файле стоит метка поворота на 90 градусов: FFmpeg разворачивает такой кадр перед обработкой, и к масштабированию он уже вертикальный. У этих двух файлов результат короткой команды совпал с результатом рекомендуемого рецепта: тот же вес в байтах и те же метки.

Вес тоже разошёлся: пять файлов из десяти стали тяжелее исходников. Вот четыре пары из замера: 120,6 мегабайта против 105,7; 169,7 против 152,3; 32,4 против 18,4; 37,7 против 29,0. Сильнее всех вырос ролик 800×480: его увеличили до 1080×1920, и файл стал тяжелее почти вдвое.

Есть и второй вид этого брака. Метки формы пикселя может не быть у самого исходника. Так записан, например, один из роликов набора в .mov. На таком исходнике короткая команда ничего не помечает, а меняет саму картинку: кадр 16:9 сжимается по ширине до 9:16. В строке разбора такой файл выглядит как годный: 1080x1920 без пометок. Поймать его можно только по самой картинке, и сверка ниже это делает.

Отсюда главная проверка: как кадр показывается, а не какое у него разрешение. Разрешение у правильного файла и у испорченного одно и то же.

Всего проверка смотрит четыре числа:

• разрешение и соотношение сторон. В строке разбора файла они стоят рядом. 1080x1920 [SAR 1:1 DAR 9:16] — кадр вертикальный и в файле, и на экране. 1080x1920 [SAR 256:81 DAR 16:9] — тот самый случай, когда метка разворачивает кадр обратно в горизонтальный. Бывает и третий вид, его даёт сам рекомендуемый рецепт: 1080x1920 [SAR 1216:1215 DAR 76:135]. Так вышло у шести наших файлов из десяти, и это годный кадр. Пиксель практически квадратный, а 76:135 отличается от 9:16 на восемь сотых процента: это округление при масштабировании. Поэтому правило такое: если разрешение вертикальное, а по DAR кадр шире, чем выше, это брак. Если пометки DAR у файла нет, соотношение сторон кадра совпадает с разрешением.
• длительность. Если правка не меняет длину ролика, длительность результата должна совпасть с исходной. Расхождение — повод открыть файл, но ещё не брак: у одного ролика из наших десяти в заголовке стоит 70,7 секунды, а при чтении выходит 44,3, и после обработки в файле те же 44,3. Ничего не потеряно: неверной была длительность в заголовке исходника.
• число файлов на выходе. Их должно быть ровно столько, сколько было на входе, а если настройка делает по несколько копий на файл, то во столько же раз больше.

Вес признаком брака не служит. Короткий вариант испортил восемь файлов, а тяжелее исходника вышли пять. У рекомендуемого рецепта тяжелее исходника вышли два файла из десяти, и оба исправны.

Эти числа и саму картинку сверяет одна команда. Она печатает счёт файлов, а ниже — только файлы, где что-то не так. Две строки в её начале настраиваются под вашу правку:

$video = '.mp4', '.mov', '.avi', '.mkv', '.3gp'
$tall = $true   # результат вертикальный; горизонтальный - $false; кадр не меняли - $null
$plus = 0       # на сколько секунд правка удлиняет ролик: интро в 3 секунды - 3
function Probe($file) {
    $text = (& ffmpeg -hide_banner -i $file 2>&1) -join ' '
    $info = @{ time = -1; shape = 0 }
    if ($text -match 'Duration: (\d+):(\d+):([\d.]+)') { $info.time = [int]$matches[1] * 3600 + [int]$matches[2] * 60 + [double]$matches[3] }
    if ($text -match ', (\d{2,5})x(\d{2,5})') { $info.shape = [int]$matches[1] / [int]$matches[2] }
    if ($text -match 'DAR (\d+):(\d+)') { $info.shape = [int]$matches[1] / [int]$matches[2] }
    if ($text -match 'rotation of -?90') { $info.shape = 1 / $info.shape }
    $info
}
function Picture($file) {
    $text = (& ffmpeg -hide_banner -sseof -3 -i $file -t 2 -vf cropdetect -f null - 2>&1) -join ' '
    $all = [regex]::Matches($text, 'crop=(\d+):(\d+)')
    if ($all.Count -eq 0) { return 0 }
    $last = $all[$all.Count - 1]
    [int]$last.Groups[1].Value / [int]$last.Groups[2].Value
}
$src = Get-ChildItem -File | Where-Object { $video -contains $_.Extension }
"на входе $($src.Count), на выходе $((Get-ChildItem out -Filter *.mp4).Count)"
foreach ($file in $src) {
    $out = "out\$($file.BaseName).mp4"
    if (-not (Test-Path $out)) { "НЕТ РЕЗУЛЬТАТА: $($file.Name)"; continue }
    $a = Probe $file.FullName
    $b = Probe $out
    if ($b.time -lt 0) { "НЕ ЧИТАЕТСЯ: $out"; continue }
    if ([math]::Abs($a.time + $plus - $b.time) -gt 0.5) { "ДЛИТЕЛЬНОСТЬ: $($file.Name), было $($a.time) с, стало $($b.time) с" }
    if ($tall -eq $true -and $b.shape -gt 1) { "ПРОПОРЦИИ: $($file.Name), кадр показывается горизонтальным" }
    if ($tall -eq $false -and $b.shape -lt 1) { "ПРОПОРЦИИ: $($file.Name), кадр показывается вертикальным" }
    $pic = Picture $out
    if ($pic -gt 0 -and $a.shape -gt 0 -and [math]::Abs($pic / $a.shape - 1) -gt 0.05) { "ИСКАЖЕНИЕ: $($file.Name), картинка сжата или растянута" }
    if ((Get-Item $out).Length -gt $file.Length) { "ТЯЖЕЛЕЕ ИСХОДНИКА: $($file.Name)" }
}

В строке $tall задаётся, каким должен выйти кадр: вертикальным — $true, горизонтальным — $false. Если правка размер кадра не меняет, как при конвертации, поставьте $null, и проверка пропорций отключится. В строке $plus задаётся, на сколько секунд правка удлиняет ролик. Для интро в 3 секунды поставьте 3.

Замечаний шесть видов. «НЕТ РЕЗУЛЬТАТА» — готового файла нет. «НЕ ЧИТАЕТСЯ» — файл есть, но FFmpeg его не открыл. «ДЛИТЕЛЬНОСТЬ» — длина разошлась больше чем на полсекунды. «ПРОПОРЦИИ» — кадр показывается горизонтальным вместо вертикального или наоборот. «ИСКАЖЕНИЕ» — картинка без чёрных полей вытянута не так, как в исходнике. Поля ищет фильтр cropdetect по тёмным краям кадра на последних секундах ролика, поэтому интро этой проверке не мешает. Если ролик кончается тёмной сценой, «ИСКАЖЕНИЕ» может оказаться ложным: такой файл просто откройте. «ТЯЖЕЛЕЕ ИСХОДНИКА» — не брак, но при сжатии повод поднять -crf.

Мы проверили команду на пятисекундных вырезках из шести роликов смешанной папки и на седьмой вырезке, из ролика с меткой поворота. На выходе рекомендуемого рецепта, конвертации и интро она не назвала ни одного файла. На выходе короткой команды назвала все шесть испорченных: пять с пометками «ПРОПОРЦИИ» и «ИСКАЖЕНИЕ», а ролик без метки формы пикселя — с пометкой «ИСКАЖЕНИЕ». Ролик с поворотом, вышедший правильным, она не назвала. Удалённый результат она назвала «НЕТ РЕЗУЛЬТАТА», а обрезанный наполовину — «НЕ ЧИТАЕТСЯ».

Для копий из программы Video Unique Booster эта команда не годится: у программы свои папки и имена. Для её копий достаточно счёта: файлов должно выйти столько, сколько получится, если число роликов умножить на число копий.

Счёт файлов не пропускайте никогда: в обсуждении человек запустил обработку на 1023 файлах, а получил 900 ⁴. Недостачу там объяснили одной причиной — неверной подстановкой имени файла. В той же ветке советуют проверить ещё две вещи: совпадение выходных имён и отсутствие ключа -y, из-за которого обработка остановится на вопросе о перезаписи.

Потерю качества при перекодировании измеряли в отдельной работе. Для стандарта HEVC перекодирование снизило PSNR на 0,35 дБ в лучшей точке и на 0,63 дБ при сжатии потока примерно на четверть. Средняя наибольшая потеря на всём проверенном диапазоне — 1,4 дБ. На режимах, которые авторы называют практически полезными, потеря держится ниже 0,7 дБ ¹. Считать это «файл стал хуже на 0,35 дБ» нельзя: там сравнивали перекодированное видео с видео, сжатым напрямую до того же битрейта, то есть измеряли потерю именно от повторного сжатия.

Что эта разница значит для глаза, работа не говорит. PSNR измеряет расхождение значений пикселей, а не заметность искажений. В другой работе метрики качества сравнили с оценками людей. На высоких битрейтах корреляция с оценками людей у PSNR и большинства других метрик вышла 0,25-0,45, а у лучшей из более новых — 0,7. На потоках H.264 корреляция у всех метрик выше 0,94 ¹⁷.

Цепочку из нескольких перекодирований в работе о HEVC ¹ не мерили: авторы ссылаются на свою более раннюю работу, где накопление потерь измерено. Своего замера у нас тоже нет. Практический вывод один: каждое лишнее перекодирование — ещё одна потеря. Поэтому делайте все правки одной командой, как в рецепте трёх правок, а не тремя запусками подряд.

Разнородные исходники

В папке лежат файлы с разным разрешением, частотой кадров и кодеком.

Одна команда даёт им разный результат — это и показал замер выше. Об этом не пишет ни одна из восьми прочитанных страниц, их список — в конце раздела.

Разложить исходники помогает быстрый обход папки. Для этого хватает того же FFmpeg:

$video = '.mp4', '.mov', '.avi', '.mkv', '.3gp'
Get-ChildItem -File | Where-Object { $video -contains $_.Extension } | ForEach-Object {
    $info = & ffmpeg -hide_banner -i $_.FullName 2>&1 | Select-String "Stream #.*Video"
    "$($_.Name): $info"
}

Команда печатает разрешение, частоту кадров и кодек каждого файла. По этому списку сразу видны группы файлов с одинаковыми параметрами.

Дальше два варианта. Первый — разложить файлы по группам и задать каждой своё целевое разрешение. Второй — добавить в одну команду сохранение пропорций, как в рекомендуемом рецепте: force_original_aspect_ratio=decrease вписывает кадр целиком, а pad дополняет его полями. Второй вариант мы проверили на роликах 1280×720, 1920×1080 и 800×480: на выходе 1080×1920 без искажения пропорций.

Отдельный случай — вертикальное видео с меткой поворота. При просмотре ролик вертикальный, а в файле кадр записан горизонтальным и помечен поворотом на 90 градусов. В разборе у такого файла стоит горизонтальное разрешение, например 1280×720, и строка поворота.

Мы проверили один способ обработки: при перекодировании FFmpeg сам разворачивает кадр и снимает метку, и результат выходит верный, 1080×1920. Копирование потока (-c copy) мы не мерили.

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

Оборванная обработка

Закрыли крышку ноутбука. Кончилось место на диске. Программа перестала отвечать.

Обработка 300 файлов оборвалась на 150-м. Что дальше?

Ни одна из прочитанных страниц с готовым кодом не даёт способа продолжить с места остановки: там либо всё обрабатывается заново, либо о поведении после обрыва не сказано вовсе.

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

$video = '.mp4', '.mov', '.avi', '.mkv', '.3gp'
New-Item -ItemType Directory -Force out
Get-ChildItem -File | Where-Object { $video -contains $_.Extension } | Where-Object {
    if (-not (Test-Path "out\$($_.BaseName).mp4")) { return $true }
    ffmpeg -v error -xerror -i "out\$($_.BaseName).mp4" -f null - 2>$null
    $LASTEXITCODE -ne 0
} | ForEach-Object {
    ffmpeg -y -i $_.FullName -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" -c:a copy "out\$($_.BaseName).mp4"
}

Приём не наш: в больших конвейерах обработки работу так же делят на части и после сбоя пересчитывают только потерянные части, а не всё целиком ². Важная оговорка: работа про конвейеры машинного обучения, а не про перекодирование. Видео там разбирают на кадры и распознают, файла на выходе нет вовсе. Работы именно про устойчивость массовой обработки видео мы не нашли.

Проверять одно имя мало. Файл, на котором обработку оборвало, в папке результата уже есть — недописанный, и по имени он неотличим от готового. Мы оборвали обработку через четыре секунды после запуска.

Первое, что приходит в голову, — отсев по весу: считать браком слишком маленький файл. Этот способ не работает: недописанный файл весил 3,4 мегабайта при 17,5 у готового, и порог в 100 килобайт его не отсеивает. Порог от веса исходника тоже ненадёжен. У нас недописанный файл весил 0,03 исходника, а четыре готовых файла из десяти — от 0,12 до 0,23. Но вес недописанного файла зависит от того, когда оборвалась обработка. Порог, который поймает файл, оборванный ближе к концу, заденет и готовые файлы, и они будут уходить на переделку при каждом запуске.

Поэтому годность проверяется чтением, как в первом проходе: недописанный файл не открывается вовсе. FFmpeg пишет таблицу кадров в конец файла, а запись оборвалась раньше. Цикл выше пробует открыть каждый готовый файл и берёт в работу те, что не открылись. Это медленнее сверки имён: там сравниваются имена, здесь читается каждый файл. Времени этой проверки мы не мерили. Мы проверили цикл: в папке из трёх роликов, где один результат готов, второй остался недописанным, а третьего нет вовсе, цикл взял в работу только второй и третий.

Откуда взялись эти четыре случая? Восемь страниц мы собрали 22 сентября 2026 года пятью запросами на русском и прочитали целиком; пять из них названы в источниках — ⁴, ¹³, ¹⁴, ¹⁵, ¹⁶. Остальные три — продающая страница VidBatch, справка по меню VideoPad и обзор на napli.ru с одним готовым скриптом для конвертации webm в mp3. Отдельные советы там есть, например ключ -y и счёт файлов в ⁴. Но ни один из четырёх случаев не разобран целиком ни на одной из восьми. Это не первая десятка выдачи, а восемь страниц, которые нашлись и открылись.

Где это не работает

Массовая обработка не заменяет монтаж: она повторяет одно действие и решения о кадре не принимает.

Делает ли одинаковая обработка ролики разными для площадки, неизвестно: мнения на арбитражных форумах расходятся. «Пробовал программы для пакетной обработки видео, на них у меня просмотры не давало», — писал участник в 2020 году ¹⁰. В 2025 году в той же ветке написали обратное: «у ффмпег богатейший инструментал по уникализации видео — все проходит» ¹⁰. Замера за этими мнениями нет ни у одной стороны. Что правила TikTok говорят о повторных роликах в ленте, мы разобрали в статье про алгоритм тик ток.

Одинаковая правка на всю папку делает копии ролика одинаковыми между собой. Программа с диапазонами устроена иначе: каждая копия получает свои значения настроек. Ролики без уникализации в нашей сетке Instagram мы не публиковали. До сетки, на одном своём аккаунте, чужие ролики из других соцсетей без обработки вскоре начинали получать ноль просмотров. Это наше наблюдение, а не замер.

Наш пример из X этот спор тоже не решает. В сетке X в январе 2024 года мы заменили медиафайлы в публикациях на уникальные копии, и трафика стало в 14 раз больше. Но в том же шаге мы поменяли и схему связей между аккаунтами. Обе перемены сделаны одновременно, и по этим данным не определить, какая из них дала рост.

Читайте по теме: уникализация видео для TikTok, как уникализировать видео для Инстаграм, как уникализировать видео для Ютуб.

Частые вопросы

С чего начать

Возьмите пять файлов из своей папки. Обработайте их выбранным способом. Посмотрите результат и сверьте четыре числа: разрешение, соотношение сторон (DAR), длительность и число файлов на выходе.

Если результат устраивает, запускайте обработку всей папки. Если нет, меняйте настройки и проверяйте их на тех же пяти файлах.

Источники

1. Grajek T., Stankowski J., Karwowski D., Klimaszewski K., Stankiewicz O., Wegner K. Analysis of video quality losses in the homogenous HEVC video transcoding. Poznań University of Technology, 2017. ↩︎
2. Luan F. S. и соавт. The Streaming Batch Model for Efficient and Fault-Tolerant Heterogeneous Execution. 2025. ↩︎
3. Карточка заказа на встраивание интро в 500 роликов: там же оценка около 30 часов на 100 роликов для VideoPad. Freelancehunt, год публикации на странице не показан. ↩︎
4. Обсуждение обработки коллекции из 1023 файлов. Linux.org.ru, 2023. ↩︎
5. Комментарии к статье о массовой обработке видео. Хабр, 2023. ↩︎
6. Обсуждение «How to automate repetitive product video edits». Adobe Community, 2025. ↩︎
7. Обсуждение «Batch process video files». Adobe Community, 2020. ↩︎
8. Обсуждение «30 separate edited clips on one timeline that i want to batch export». Adobe Community, 2025. ↩︎
9. DWUL. Обработка серии клипов в DaVinci Resolve через группы. YouTube. ↩︎
10. Обсуждение «Как уникализировать видео для TikTok». Zismo.biz, 2020-2025. ↩︎
11. KrezWorld. Обработка серии видеофайлов в VirtualDub через очередь заданий. YouTube. ↩︎
12. FFmpeg: страница загрузки. Официальный сайт проекта. ↩︎
13. Пакетная обработка файлов через циклы CMD и Bash. Annimon, 2021. ↩︎
14. Массовое перекодирование сотен файлов скриптом. Хабр, 2012. ↩︎
15. Полезные команды FFmpeg. Losst, 2016, обновлено в 2020. ↩︎
16. Вопрос о массовой нарезке всех видео в папке. Хабр Q&A. ↩︎
17. Antsiferova A., Yakovenko A., Safonov N., Kulikov D., Gushin A., Vatolin D. Objective video quality metrics application to video codecs comparisons: choosing the best for subjective quality estimation. Московский государственный университет, 2021. ↩︎
18. Yang P., Baracchi D., Iuliani M., Shullani D., Ni R., Zhao Y., Piva A. Efficient Video Integrity Analysis Through Container Characterization. IEEE Journal of Selected Topics in Signal Processing, 2020: описание набора EVA-7K. ↩︎
19. FFmpeg: сборки для Windows. gyan.dev, ссылка со страницы загрузки FFmpeg. ↩︎
20. HandBrake Documentation: Using the queue. HandBrake Team. ↩︎