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

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

Для видеозадач особенно важен Video plugin и его FFmpeg Builder. Он разбивает длинную команду FFmpeg на понятные элементы: анализ исходника, выбор кодека, настройку качества или битрейта, работу с аудиодорожками и субтитрами, смену контейнера и финальное выполнение. При этом FileFlows полезен не только для перекодирования: базовые элементы умеют копировать и перемещать файлы, переименовывать их, работать с архивами, создавать каталоги, запускать внешние процессы и принимать решения по значениям переменных.

Как устроена работа FileFlows

FileFlows рассчитан на постоянную обработку коллекций, а не на схему открыть один ролик, выбрать профиль и нажать старт. Сначала создаётся или выбирается библиотека, затем ей назначается Flow. Сканер библиотеки находит подходящие объекты и формирует список файлов. Веб-консоль разделяет их на состояния Unprocessed, Processing, Processed и Processing Failed. Когда свободный Agent получает задание, он создаёт рабочее окружение, выполняет элементы потока по порядку и сохраняет журнал выполнения. Если очередной элемент возвращает второй выход, поток идёт по второй ветке; если возникает необработанная ошибка, файл попадает в список неудачных заданий.

Такая модель удобна там, где критерии обработки должны быть воспроизводимыми. Например, вместо ручной проверки каждой серии можно задать: анализировать видео, пропускать уже подходящий HEVC, остальные файлы кодировать в HEVC, сохранить все субтитры, преобразовать только неподходящие аудиодорожки, сменить контейнер на MKV и после успешной проверки заменить оригинал. В другой библиотеке тот же сервер может выполнять совершенно другой сценарий — например, распаковывать архивы, переименовывать изображения и переносить результат по структуре каталогов.

У FileFlows есть два уровня принятия решения. На уровне Library можно отсечь ненужные объекты ещё до постановки в очередь: по типу файла, расширению, размеру, времени создания или изменения, шаблонам включения и исключения, а для медиа — по некоторым характеристикам. На уровне Flow доступны более детальные проверки, потому что перед ними можно проанализировать содержимое и получить сведения о кодеках, дорожках, разрешении и других свойствах. Это снижает число лишних запусков FFmpeg и помогает не перекодировать файлы, уже удовлетворяющие заданным условиям.

Веб-консоль и основные разделы

Управление сосредоточено в Web Console. Через неё создаются Flows и Libraries, просматривается очередь файлов, настраиваются Agents, подключаются Plugins и Scripts, задаются Variables, открываются системные журналы и отчёты. Для повседневной работы важнее всего пять областей: Dashboard для текущего состояния, Files для очереди, Flows для логики обработки, Libraries для источников и Agents для исполнителей.

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

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

Libraries: откуда FileFlows берёт файлы

Library — это не просто список папок. В её настройках задаются Name, Path и Flow, а также правила обнаружения и планирования. Path указывает каталог, который сканируется. Flow определяет, какой сценарий получит найденный объект. Enabled позволяет временно отключить библиотеку без удаления конфигурации. Scan Interval задаёт период контрольного сканирования, а наблюдение за событиями файловой системы может ускорять обнаружение новых и изменённых файлов.

Hold Minutes нужен там, где файл появляется в библиотеке раньше, чем полностью готов. Типичный пример — загрузчик сначала создаёт файл и постепенно дописывает данные. Если обработка начнётся сразу, анализатор увидит неполный контейнер или Agent будет конкурировать за доступ с программой-загрузчиком. Задержка постановки в обработку даёт исходному приложению закончить запись. Дополнительно File Detection Interval позволяет повторно проверить размер, чтобы не брать файл, который всё ещё меняется.

В File Types можно выбрать Audio, Video, Image или Custom. При Custom задаются расширения вручную. Для отдельных типов доступны дополнительные условия: например, для видео можно ограничивать обработку по кодекам, разрешению и длительности, для аудио — по кодеку и длительности, для изображений — по формату и размерам. Часть расширенных фильтров и параметров библиотеки относится к лицензируемым функциям, поэтому при проектировании сценария важно различать бесплатную базовую автоматизацию и опции, которые требуют лицензии.

Filters и Exclusions применяются к полному пути и помогают не загружать в очередь служебные файлы. Фильтром удобно оставить только определённую подпапку или маску имен, исключением — пропустить sample, extras, временные каталоги и другие известные категории. Поскольку эти правила действуют до Flow, они уменьшают объём ненужной работы и сокращают количество записей в базе.

Schedule задаёт интервалы, когда библиотека может сканироваться и обрабатываться. Если машина одновременно служит медиасервером или рабочей станцией, тяжёлые перекодирования можно ограничить ночными часами. Max Runners ограничивает число параллельных исполнителей для конкретной библиотеки. Это отличается от общего числа runners на Agent: лимит библиотеки защищает определённый набор данных от чрезмерной параллельной нагрузки, даже если в системе свободно больше вычислительных слотов.

Advanced содержит несколько настроек, которые становятся критичными в сложных хранилищах. Exclude Hidden исключает скрытые объекты. Top Level Only запрещает рекурсивный обход подпапок. Folders переключает библиотеку с файлов на каталоги. File System Events можно отключить, если сетевое хранилище плохо передаёт события и удобнее полагаться на периодический скан. Skip File Access Tests ускоряет добавление, но убирает предварительную проверку чтения и записи, поэтому использовать его следует только там, где права уже гарантированы.

Reprocess и Reset: разные операции

Команды Reprocess и Reset решают разные задачи. Reprocess возвращает уже известные записи библиотеки, включая неудачные, в очередь Unprocessed. Это подходит после изменения Flow, когда нужно повторно прогнать те же файлы. Reset удаляет внутренние записи FileFlows для выбранной библиотеки и запускает повторное обнаружение. Файлы на диске при этом не должны удаляться, но история записей этой библиотеки сбрасывается. Поэтому Reset имеет смысл применять, когда база обнаружения перестала соответствовать фактическому содержимому каталога, а не как обычную кнопку повторной обработки.

Files: очередь, состояние и журналы

Раздел Files показывает то, что сканер уже обнаружил. Unprocessed — ожидающие задания, Processing — выполняющиеся, Processed — завершённые, Processing Failed — завершившиеся ошибкой. Для больших очередей это разделение полезнее простого общего списка: можно быстро понять, проблема относится к обнаружению, планированию или непосредственно к выполнению Flow.

Для отдельного файла доступны операции View, Remove, Move To Top, Rescan, Cancel и Reprocess. Remove убирает запись из FileFlows, но не означает удаление исходника с диска. Контекстная команда Delete, напротив, рассчитана на удаление записи вместе с файлом, поэтому её нельзя использовать как эквивалент очистки очереди. Mark as Processed позволяет исключить объект из активной обработки, а Toggle Force Processing включает принудительный режим.

Force Processing полезен для разовой проверки, когда обычное расписание мешает запуску. Такой файл может обрабатываться вне расписания, и Agent, который в обычной ситуации ожидал бы разрешённого окна, получает возможность выполнить принудительное задание. Для постоянной эксплуатации лучше исправить расписание библиотеки и агента, чем регулярно помечать файлы вручную.

Двойной щелчок по обрабатываемому или завершённому файлу открывает журнал. Именно он нужен при поиске причин: в нём видно, какой flow element выполнялся, какие параметры сформировались, что вернул внешней процесс и на каком шаге поток завершился. При сложном FFmpeg Builder полезно смотреть не только последнюю строку ошибки, но и построенную команду, определённые дорожки, выбранный encoder и путь к временному файлу.

Flow Editor: визуальная схема обработки

Flow Editor представляет сценарий как граф. Справа находится список элементов, на рабочем поле — размещённые flow parts, между ними — соединения выходов и входов. Каждый Flow должен начинаться с одного входного элемента. Для обычных файлов это Input File, для видео часто используется Video File, потому что он не только принимает путь, но и запускает анализ медиаданных и создаёт набор переменных с параметрами ролика.

Чтобы построить Flow, элементы перетаскиваются на поле, после чего выход одного соединяется со входом следующего. Двойной щелчок открывает настройки выбранного элемента. Важное правило редактора: каждый выход имеет только одно соединение, но один вход может принимать несколько соединений. Это позволяет свести разные ветки обратно к общей операции, например после альтернативных способов кодирования перейти к одному шагу Move File.

Номер выхода имеет смысл. У проверок первый выход обычно соответствует успешному совпадению или положительному условию, второй — отсутствию совпадения. У процессоров второй выход может означать изменение не потребовалось. У некоторых элементов есть отдельный failure output. Если ошибка не перехвачена соединением, поток завершается неудачей. Если failure output соединён, можно выполнить запасной вариант — например, после отказа аппаратного кодировщика перейти к ветке CPU.

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

Flow Properties и параметры шаблонов

Свойства Flow открываются через контекстное меню на свободной области холста. Там можно сохранить описание, автора и начальные Variables. Переменные Flow задают значения, доступные элементам с самого начала выполнения, и могут изменяться позже. Это удобнее, чем многократно вписывать одинаковый путь или параметр в разные узлы.

При экспорте потока в шаблон доступны Fields. Поле может ссылаться на переменную или конкретное свойство элемента, иметь тип, обязательность и значение по умолчанию. Условия If, If Value и If Not позволяют показывать параметр только тогда, когда он действительно нужен. За счёт этого один шаблон можно использовать для разных библиотек, запрашивая у пользователя только изменяемые значения вроде каталога назначения, целевого кодека или языка.

Sub Flows

Sub Flow превращает повторяемую последовательность операций в самостоятельный элемент. Если несколько библиотек требуют одинаковой подготовки звука, нет необходимости дублировать пять одинаковых блоков в каждом Flow. Подпоток принимает параметры, может иметь несколько выходов и добавляется в основной сценарий как обычный элемент. Практический выигрыш — централизованное изменение логики: исправление внутри общего подпотока не приходится переносить вручную в несколько больших графов.

Failure Flow

Для общей реакции на сбой можно использовать Failure Flow. Он запускается, когда обычный Flow завершается ошибкой, и подходит для уведомлений, записи дополнительной диагностической информации или других единообразных действий. Это лучше, чем добавлять одну и ту же ветку отправки уведомления после каждого потенциально проблемного элемента. Локальные failure outputs при этом остаются полезны там, где ошибку можно обработать внутри самого сценария и продолжить работу.

Variables: как передавать значения между элементами

Variables связывают отдельные части Flow и дают сценариям контекст. В текстовых полях переменные подставляются в фигурных скобках, например {file.Name}. Доступный набор зависит от того, какие элементы уже были выполнены: после Video File появляются сведения о видео, после собственных функций можно добавить вычисленные значения, а стандартные переменные описывают текущий файл, временный каталог, библиотеку и время выполнения.

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

Глобальные Variables на странице конфигурации похожи на именованные параметры среды для всей системы. Через них задаются пути к инструментам и значения, которые должны быть доступны плагинам и скриптам. Типичный пример — путь к FFmpeg. Аналогично можно хранить адрес сервиса уведомлений или собственный параметр интеграции. Если значение должно отличаться на разных Agents, его лучше задавать на уровне конкретного агента, а не глобально.

В текстовом поле ввод символа { открывает выбор доступных переменных. В JavaScript они читаются через объект Variables. Это позволяет строить ветвления без жёстко заданных имён файлов: функция может проверить Variables.file.Extension, значение, сформированное анализатором видео, или собственный флаг и вернуть номер нужного выхода.

Video File: анализ входного ролика

Video File обычно ставят первым элементом в видеопотоке. Он запускает FFmpeg/ffprobe-анализ, загружает сведения о контейнере и дорожках и делает их доступными дальнейшим узлам. Среди полезных значений — ширина, высота, продолжительность, кодек первой видеодорожки, параметры аудио и список кодеков аудиодорожек. За счёт этого решения можно принимать до фактического перекодирования.

Probe Size и Analyze Duration управляют глубиной анализа. Если значения слишком малы, сложный или повреждённый контейнер может быть распознан неполно: например, нужная дорожка обнаружится не сразу. Слишком большие значения, наоборот, увеличивают время предварительного анализа. Для обычной медиатеки разумно начинать со стандартных настроек и повышать их только для файлов, которые стабильно определяются неправильно.

После анализа можно разветвлять поток по кодеку, разрешению, наличию дорожек или другим признакам. Важно помнить, что простая проверка расширения не заменяет Video File: MKV или MP4 — контейнер, внутри которого могут находиться H.264, HEVC, AV1, разные аудиокодеки и несколько субтитров. Если цель — привести библиотеку к единому техническому профилю, решения должны основываться на содержимом, а не только на имени файла.

FFmpeg Builder: сборка преобразования по шагам

FFmpeg Builder — центральный механизм видеоплагина. Вместо одной длинной строки параметров FileFlows создаёт модель, которую последовательно изменяют flow elements. Начало задаёт FFmpeg Builder: Start. Далее узлы меняют видеодорожки, аудио, субтитры, контейнер или фильтры. В конце FFmpeg Builder: Executor строит команду и запускает FFmpeg.

Builder сначала анализирует потоки исходного файла. Если дорожка явно не помечена на удаление и для неё не задано преобразование, она обычно копируется в выход. Это поведение удобно для сохранения субтитров и дополнительных аудиодорожек, но его нельзя путать с гарантией полной идентичности контейнера: отдельные форматы вывода могут не поддерживать конкретные кодеки или типы вложений. При смене контейнера необходимо учитывать совместимость потоков с выбранным форматом.

Схема Start → настройки → Executor позволяет выполнить несколько изменений одним запуском FFmpeg. Например, можно одновременно перекодировать видеодорожку, преобразовать одну группу аудио, сохранить другую без изменений, добавить внешние субтитры и выбрать MP4. Это эффективнее цепочки независимых перекодирований, где каждый этап заново декодирует и кодирует материал.

FFmpeg Builder: Start

Start создаёт модель Builder и подготавливает информацию о потоках. Узлы, которые ожидают объект FfmpegBuilderModel, должны находиться после него. Если пользовательская функция пытается изменить Builder раньше, модель отсутствует и логика не сработает. Поэтому при сложном потоке полезно визуально отделять подготовительную часть от стадии построения FFmpeg-команды.

FFmpeg Builder: Executor

Executor превращает накопленные настройки в команду FFmpeg. Если Builder не обнаружил изменений, он может завершить ветку через отдельный выход без фактического перекодирования. При ошибке выполнения возвращается состояние сбоя. Это важное поведение для потоков, рассчитанных на повторные сканирования: уже подходящий файл не должен каждый раз проходить полную перекодировку только потому, что снова попал в очередь.

В настройках Executor есть режим аппаратного декодирования. Off запрещает использование аппаратного декодера. On пытается подобрать доступный аппаратный вариант и при необходимости вернуться к CPU. Automatic учитывает разрядность и старается применять аппаратное декодирование, когда преобразование не требует несовместимой смены глубины. Такой подход помогает не заставлять GPU выполнять операцию, которую конкретная цепочка всё равно не поддержит корректно.

Video Encode: выбор кодека, качества и скорости

Video Encode предназначен для настройки кодирования без ручного ввода полного набора параметров FFmpeg. В нём выбирается Codec, Encoder, Quality и Speed. Поддерживаемые варианты включают H.264, несколько режимов HEVC, AV1 и VP9. Практический выбор зависит не только от потенциальной экономии места, но и от устройств воспроизведения. Чем новее кодек, тем выше вероятность, что старый телевизор, медиаплеер или браузер потребует программного декодирования.

HEVC Automatic сохраняет идею автоматического выбора 8- или 10-битного варианта в зависимости от источника. HEVC 8-Bit нужен, когда приоритетом является более широкая совместимость. HEVC 10-Bit целесообразен для контента и устройств, где поддержка Main10 заранее известна. AV1 способен дать высокую эффективность сжатия, но время кодирования и доступность аппаратного декодирования нужно оценивать по фактическому парку устройств.

Encoder можно выбрать явно или оставить Automatic. Автоматический режим тестирует аппаратные варианты и при невозможности использовать их возвращается к CPU. Порядок включает Video Toolbox на macOS, затем NVIDIA, Intel QSV, AMD AMF, VAAPI и программное кодирование. Явное указание конкретного аппаратного encoder отключает часть автоматической страховки: если выбранный кодировщик недоступен на Agent, задача завершится ошибкой. Поэтому фиксированный encoder оправдан, когда Flow намеренно назначен только совместимым агентам.

Quality влияет на компромисс между качеством и размером, Speed — между временем и эффективностью сжатия. Слишком быстрый режим обычно требует большего файла для сопоставимого качества, а слишком медленный может не окупаться на большой библиотеке. Для автоматической обработки важнее устойчивый профиль, чем максимальная компрессия любой ценой: небольшая экономия на одном эпизоде может превратиться в недели дополнительной нагрузки на тысячах файлов.

Video Encode Advanced и принудительное кодирование

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

Video Bitrate и режим по проценту

Video Bitrate задаёт целевой битрейт или вычисляет его как процент от текущего. Процентный режим полезен для грубой нормализации разнородной коллекции, однако он не является универсальной оценкой качества. Два источника с одинаковым битрейтом могут радикально отличаться по сложности изображения, шуму и зерну. Если цель — предсказуемое визуальное качество, CRF-подобная логика обычно информативнее простой доли от исходного потока.

Важно учитывать взаимное исключение некоторых подходов. Узел с фиксированным bitrate не должен бездумно сочетаться с Video Encode, который строит параметры качества на другой модели. Если Flow содержит несколько элементов, меняющих параметры одной видеодорожки, итог зависит от того, как Builder объединит их. Лучше заранее решить, работает сценарий от качества или от целевого битрейта, и не смешивать две стратегии без необходимости.

Аппаратное кодирование: NVIDIA, Intel, AMD и VAAPI

Аппаратное ускорение в FileFlows не существует отдельно от FFmpeg и конкретного Agent. Наличие видеокарты ещё не означает, что нужный encoder доступен внутри окружения. В контейнерной установке должны быть проброшены устройства и драйверы, в обычной системе FFmpeg должен быть собран с поддержкой соответствующего механизма. Поэтому при ошибке encoder not found нужно сначала проверить возможности FFmpeg на том агенте, где реально выполняется задача.

Автоматический выбор снижает число жёстких зависимостей, но не отменяет различия между кодировщиками. NVIDIA использует NVENC, Intel — Quick Sync, AMD — AMF, в Linux может применяться VAAPI. Один и тот же абстрактный выбор HEVC превращается в разные параметры. Если библиотека распределяется между несколькими машинами, результат может отличаться по размеру и скорости даже при одинаковом Flow, потому что фактический encoder выбирается на каждом Agent отдельно.

Переменные NoNvidia, NoQSV, NoAMD и NoVAAPI позволяют исключить определённые механизмы из автоматического выбора. Это полезно, если драйвер присутствует, но конкретный encoder работает нестабильно, занят другим приложением или даёт нежелательный профиль. Исключение через переменную лучше, чем случайные отказы внутри очереди: система сразу выбирает другой путь.

На Windows для FFmpeg Builder предусмотрена переменная FFmpegInfinity, позволяющая задавать маску логических процессоров. Такой механизм нужен только в специфических системах, например при желании ограничить FFmpeg определёнными ядрами гибридного CPU. Для обычного домашнего сервера он не является обязательной настройкой и без понимания битовой маски может, наоборот, снизить производительность.

Оптимизация видео по VMAF

В Video plugin есть элементы, ориентированные на подбор параметров по VMAF. Такая обработка отличается от обычного фиксированного Quality: система проводит оценки и ищет значение, которое удовлетворяет целевой модели качества. В отчёте Optimized Files затем можно увидеть encoder, разрешение, число оценок, VMAF, итоговое encoding value, время обработки и объём экономии.

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

Для оценки VMAF FFmpeg должен иметь соответствующую поддержку. В Linux сборки FFmpeg различаются: одна может содержать аппаратные энкодеры, но не VMAF, другая — наоборот. FileFlows позволяет разделить пути FFmpeg и FFmpegVMAF, чтобы использовать разные бинарники для кодирования и оценки. Это практичнее, чем менять всю систему из-за одной недостающей библиотеки.

Аудиодорожки: выборочное преобразование

Audio Convert в FFmpeg Builder умеет обрабатывать все дорожки или только совпавшие по условиям. Фильтровать можно по bitrate, channels, codec, language и title. Это позволяет построить аккуратный поток: например, оставить AC3 5.1 без изменений, но преобразовать DTS в совместимый кодек, либо создать стереодорожку только для материала с многоканальным звуком.

Сравнение языка использует механизм, который сопоставляет названия и ISO-коды. Поэтому условие можно строить по привычному обозначению языка, не переписывая библиотеку под один конкретный вариант метаданных. Тем не менее автоматизация зависит от корректных тегов источника. Если половина файлов имеет пустой language, правило обрабатывать только Russian не сможет надёжно определить такие дорожки без дополнительной логики.

Параметр Channels задаёт число каналов выходной дорожки. Если указать больше, чем в источнике, FFmpeg способен выполнить upmix, но техническая возможность не означает, что это улучшит звук. Для автоматических сценариев безопаснее уменьшать число каналов ради совместимости только там, где это действительно нужно, а не превращать стерео в искусственный многоканал.

Codec Override позволяет заменить стандартный encoder для выбранного формата через переменную вида AAC_Codec. Это пригодится, если в вашей сборке FFmpeg есть предпочтительный encoder и вы хотите использовать его системно. Перед включением такой переменной на нескольких Agents нужно убедиться, что одинаковый codec доступен на каждом из них; иначе часть очереди будет падать только на отдельных машинах.

Нормализация аудио

Нормализацию лучше рассматривать как часть общей FFmpeg-команды, а не отдельную постобработку готового файла. В Builder аудиофильтр можно применить к совпавшим дорожкам и выполнить вместе с видеокодированием. Это уменьшает число промежуточных файлов. Однако правила нормализации стоит тестировать на разных типах контента: громкость диалогов, музыка и многоканальные дорожки требуют более осторожного подхода, чем простое приведение всех файлов к одинаковому числу.

Субтитры и внешние файлы

Если субтитры не удаляются и контейнер их поддерживает, Builder обычно копирует существующие дорожки. Это удобно для медиатек с несколькими языками: не требуется перечислять каждую дорожку только ради сохранения. Отдельные элементы позволяют фильтровать, удалять, изменять признаки default/forced и добавлять внешние субтитры.

Subtitle Track Merge ищет внешние файлы и добавляет их в Builder как новые входы. Поиск может выполняться в исходном каталоге или текущей рабочей папке. Match Filename ограничивает совпадения субтитрами с тем же базовым именем, а Pattern даёт регулярное выражение для более сложного отбора. Это помогает избежать ситуации, когда в сезонной папке к одному эпизоду случайно прикрепляются субтитры от другого.

Для добавленной дорожки можно задать Title, Forced и Default. Если язык известен, он способен использоваться как название. В реальной медиатеке стоит заранее решить, какие признаки считать обязательными. Несколько дорожек, одновременно помеченных Default, могут воспроизводиться по-разному на разных клиентах, поэтому автоматический Flow должен устанавливать флаги последовательно.

Subtitle Generator может создавать дорожки через FileFlows Forge и добавлять их в активную модель Builder. Функция относится к лицензируемым и требует настроенного Forge. Она умеет создавать полный текст и/или forced-вариант, используя подходящую аудиодорожку. Такой сценарий полезен, когда медиатека должна систематически получать субтитры, но он добавляет внешнюю вычислительную стадию и потому требует отдельно контролировать очередь и качество распознавания.

Контейнеры: MKV, MP4, TS и WebM

Remux-элементы меняют контейнер результата без обязательного перекодирования потоков. Если кодеки уже совместимы с целевым контейнером, такая операция намного быстрее полной перекодировки и не ухудшает качество. Однако контейнер определяет, какие типы дорожек и метаданных допустимы. Поэтому переместить всё из MKV в MP4 не всегда означает, что каждая дорожка может быть скопирована без изменений.

Remux to MP4 имеет опцию Use HVC1. Для HEVC в MP4 различие маркировки hvc1/hev1 влияет на совместимость с частью устройств Apple. Если файл предназначен для такой экосистемы, hvc1 может оказаться необходимым. Это пример настройки, которая не меняет сам видеокодек, но влияет на то, как проигрыватель интерпретирует контейнер.

Remux to TS и Remux to WEBM решают более узкие задачи. TS может быть нужен для определённых потоковых или аппаратных цепочек, WebM — для совместимых видеокодеков и браузерных сценариев. Выбирать контейнер стоит по конечному устройству и набору дорожек, а не по желанию получить единое расширение любой ценой.

Замена оригинала и безопасное сохранение результата

Replace Original заменяет исходный файл текущим рабочим. Если расширение изменилось, исходный объект удаляется, а рабочий переносится на его место с новым расширением. Параметр Preserve Dates позволяет сохранить временные метки. Такой финал удобен для оптимизации медиатеки на месте, но он требует уверенности в Flow: ошибка в настройках кодека или фильтра после успешного завершения приведёт к тому, что именно новый файл станет основной копией.

Более осторожный сценарий на этапе настройки — сначала Move File или Copy File в отдельный каталог. Там можно проверить воспроизведение, дорожки и размер. После стабилизации Flow финальную стадию заменяют на Replace Original. Это особенно полезно при первом массовом переходе с H.264 на HEVC или при сложной перекладке аудио и субтитров.

Move File умеет сохранять структуру каталогов относительно библиотеки. Если исходник находится глубоко в дереве сериалов, Copy Folder переносит относительный путь в новый корень назначения. Additional Files позволяет захватить сопутствующие NFO или SUB-файлы, а Original Directory определяет, искать их рядом с исходником или в текущей рабочей директории. Такой набор параметров делает Move File полезнее простого внешнего mv.

Базовые элементы для файловых операций

Basic plugin содержит элементы, которые нужны практически в любом сложном потоке. Copy File и Move File работают с результатом и дополнительными файлами. Renamer меняет имя рабочего файла. Create Folder готовит каталог назначения. Delete удаляет файл или директорию. File Exists, File Extension, File Size и другие проверки позволяют строить ветки без JavaScript. Set Working File переключает текущий объект на другой путь, если предыдущая операция создала альтернативный файл.

7-Zip, Zip и Unpack добавляют работу с архивами. Это расширяет FileFlows за пределы медиатеки: поток может принимать архив, распаковывать его, проверять содержимое, обрабатывать файлы и упаковывать результат. Важно только не смешивать логику уровня один входной архив с библиотекой, которая отдельно обнаруживает извлечённые файлы в том же каталоге, иначе можно получить повторное обнаружение и циклы.

Executor запускает внешний процесс. Он нужен, когда готового flow element нет, но существует консольная утилита. При таком вызове следует передавать рабочий путь через переменную и проверять exit code. Если внешняя программа создаёт новый файл, Flow должен либо явно сделать его текущим через Set Working File, либо переместить его в нужное место. Иначе FileFlows продолжит считать актуальным прежний объект.

Set File Property и Tag работают с записью FileFlows, а не обязательно меняют содержимое файла. Properties подходят для сохранения внутреннего признака, который можно использовать позднее. Tags дают визуальную и отчётную классификацию. Это особенно полезно в сложных сценариях, где технический результат одинаков, но файлы нужно разделять по происхождению или качеству обработки.

Plugins: расширение набора элементов

Страница Plugins показывает установленные расширения и позволяет управлять ими. Именно plugins добавляют категории flow elements — Video, Image, Audio, интеграции и другие операции. В большом экземпляре FileFlows список элементов Flow Editor напрямую зависит от того, какие плагины включены. Если нужного блока нет справа в редакторе, сначала следует проверить Plugins, а не пытаться искать его среди системных настроек.

Автообновление плагинов настраивается отдельно в Settings. Для стабильной производственной схемы имеет смысл учитывать, что изменение plugin может поменять поведение Flow. Если важна воспроизводимость, полезно документировать, какие элементы используются в критичных потоках, и проверять журнал после обновления, особенно когда затронуты FFmpeg-параметры или интеграции.

Плагинная архитектура делает FileFlows шире видеоконвертера. Например, Image plugin умеет анализировать изображения, менять формат, масштабировать, поворачивать, обрезать рамки и работать с метаданными. Это позволяет одной системе обрабатывать медиаколлекцию из разных типов файлов, хотя для каждого типа всё равно разумнее создавать отдельный Flow с понятными входами и условиями.

Scripts и JavaScript-функции

Когда стандартных элементов недостаточно, FileFlows позволяет использовать JavaScript. Простая Function размещается прямо в Flow и возвращает число: положительное значение выбирает соответствующий выход, 0 завершает поток успешно, -1 завершает его ошибкой. Такой механизм подходит для расчёта переменных, сложных условий и небольших интеграционных действий.

Flow Scripts — более формализованный вариант. В начале скрипта описываются параметры, справка, версия и выходы, после чего функция Script становится точкой входа. Из описания FileFlows строит форму настройки элемента. Таким образом, собственный код превращается в повторно используемый flow element, который можно вставлять в разные сценарии без копирования текста функции.

System Scripts применяются для задач и событий системы. Shared Scripts служат библиотеками, которыми пользуются другие скрипты. Разделение важно при росте конфигурации: общую функцию обращения к API лучше вынести в shared-слой, а не хранить одинаковые HTTP-вызовы в десяти Flow Scripts.

Скрипты выполняются движком Jint. Это даёт доступ к предоставленным FileFlows объектам и в отдельных случаях позволяет взаимодействовать с типами .NET. Но пользовательский код остаётся частью автоматической обработки, поэтому ошибка в нём влияет на всю очередь. Любой скрипт, который удаляет или перемещает файлы, должен чётко различать исходный и рабочий путь и возвращать понятный код результата.

Resources и DockerMods

Resources предназначены для небольших файлов, которые должны доставляться вместе с конфигурацией на Agents. Это может быть конфигурационный файл внешней утилиты, изображение водяного знака или небольшой скрипт. Для больших ресурсов документация рекомендует сетевое хранилище: передавать крупные модели или архивы через механизм конфигурации нерационально.

DockerMods добавляют пакеты и изменения в контейнерные экземпляры FileFlows. Через них можно установить дополнительную утилиту, от которой зависит Flow. Порядок модов важен, если один зависит от другого. Недостаток очевиден: каждый лишний пакет увеличивает контейнер и удлиняет обновление, поэтому DockerMods следует добавлять под конкретную необходимость, а не как универсальный набор на всякий случай.

Agents: распределённая обработка

Agent — исполнитель, который получает файл и запускает Flow. У сервера есть встроенный Agent, поэтому отдельная машина не обязательна. Дополнительные Agents нужны, когда обработку следует вынести с сервера или распределить на несколько компьютеров. Например, хранилище может работать на маломощной системе, а тяжёлое кодирование — выполняться на рабочей станции с GPU.

В General задаются имя, адрес, Enabled, Priority и расписание. Более высокий Priority означает, что свободный Agent будет предпочитаться при раздаче задач, если он доступен, находится в разрешённом времени и не исчерпал runners. Приоритет удобно использовать, чтобы сначала загружать эффективную GPU-машину, а медленный CPU-сервер держать как резерв.

Processing ограничивает, какие библиотеки, размеры, кодеки и разрешения может брать Agent. Это лучше, чем надеяться на случайный автоматический выбор encoder. Например, агент с AV1-энкодером можно привязать к библиотеке архивных 4K-файлов, а встроенный Agent оставить для аудио и небольших задач. Processing Order на Agent способен переопределять порядок библиотеки.

Runners определяют число параллельных обработок. Для видео один runner может использовать значительную часть GPU или CPU, поэтому максимальное число не должно подбираться только по количеству ядер. В лицензируемой модели стоимости для SD, 720p, 1080p, 4K и неопределённого разрешения можно назначать разную цену в runners, чтобы тяжёлый 4K-файл занимал больше ёмкости, чем SD.

Mappings между сервером и Agent

Одна из самых частых ошибок распределённой схемы — путь, который существует на сервере, но не существует на Agent. Library хранит путь относительно сервера. Если сервер видит /media/tv, а Windows-Agent подключает тот же ресурс как сетевую папку, нужен Mapping. Он переводит серверный префикс в путь, доступный исполнителю.

Mapping не создаёт сетевой доступ сам по себе. Если Windows-машина не имеет прав к шару, замена строки пути не поможет. Сначала Agent должен уметь открыть файл средствами ОС, затем FileFlows сможет передать ему корректно переписанный путь. При разных операционных системах mappings также нормализуют разделители каталогов.

Маппинг требуется не только библиотекам. Если Flow вызывает внешнюю утилиту по абсолютному пути, путь к ней тоже может отличаться на Agent. Поэтому серверный /usr/local/bin/ffmpeg можно сопоставить с Windows-путём к ffmpeg.exe. Для параметров, различающихся между машинами, удобнее использовать agent Variables.

SignalR и Polling

Внешние Agents поддерживают несколько режимов связи. SignalR используется как рекомендуемый двусторонний вариант с постоянным соединением. Polling заставляет Agent периодически спрашивать сервер о новых данных через HTTP и предназначен как запасной режим, если WebSocket-соединение в конкретной сети работает нестабильно. Если Agent виден как периодически отключающийся за прокси или строгим межсетевым экраном, смена режима связи может быть полезнее бесконечного увеличения тайм-аутов.

Temp Directory и свободное место

Каждый Agent использует временный каталог для рабочих файлов. При полном видеоперекодировании размер временного результата может быть сравним с исходником, а в некоторых цепочках одновременно существуют несколько промежуточных файлов. Поэтому свободное место нужно рассчитывать не по среднему размеру одного ролика, а по максимальному числу runners и худшему сценарию. Если четыре агента параллельно обрабатывают файлы по 50 ГБ, маленький системный SSD быстро станет узким местом.

Temp Directory следует размещать на диске с достаточной скоростью и объёмом. Сетевой временный каталог иногда упрощает доступ, но добавляет трафик и задержки. Для кодирования на удалённом Agent обычно лучше локальный быстрый temp, а библиотеку читать и итог писать по сети.

Tasks, события и автоматическая реакция

Tasks позволяют запускать системные скрипты по событиям. К доступным триггерам относятся расписание, добавление файла, начало обработки, завершение обработки, успешный результат, ошибка, а также отдельные события обновления FileFlows. Эта функция относится к лицензируемым, поэтому её нужно рассматривать как дополнительный уровень оркестрации, а не как обязательную часть любого Flow.

Расписание Tasks разбито на 15-минутные блоки. Оно удобно для служебных действий, которые не привязаны к конкретному входному файлу: например, периодически проверять внешнюю систему, запускать скрипт обслуживания или формировать собственную реакцию на состояние очереди. Для операций над каждым файлом лучше использовать обычный Flow, потому что там есть рабочий файл, переменные и последовательность обработки.

Триггер File Process Success подходит для уведомления, обновления внешнего каталога или запуска постобработки только после успешного завершения. File Process Failure — для диагностики и оповещений. Разделение этих событий помогает не отправлять одинаковое уведомление при любом исходе и не путать процесс завершился с процесс завершился успешно.

Практический пример системной задачи — временно остановить загрузчик, если очередь обработки слишком выросла, и возобновить его, когда FileFlows догонит поток входящих файлов. Здесь особенно важно, чтобы скрипт проверял текущее состояние перед действием: автоматизация не должна бесконечно отправлять одинаковые команды внешней системе на каждом срабатывании.

Tags, Properties и внутреннее состояние

Tags предназначены для классификации файлов внутри FileFlows. Тег имеет имя, описание и может иметь собственную иконку. После присвоения его можно использовать при фильтрации и в отчётах. В отличие от переименования или записи метаданных, Tag не обязан менять сам файл на диске. Это удобный способ отмечать, например, HDR, проверить вручную или получен из внешнего источника без вмешательства в медиаконтейнер.

Set File Property решает похожую, но более программную задачу. Свойство сохраняется у конкретной записи файла в базе. Если тот же физический файл фигурирует в другой библиотеке, его запись и свойства независимы. Это важно для сценариев, где один и тот же путь рассматривается разными правилами: внутренний признак одной библиотеки не следует считать глобальным атрибутом файла.

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

Revisions: возврат к предыдущей конфигурации

Revisions хранят прошлые состояния объектов и позволяют просматривать или восстанавливать изменения. Функция относится к лицензируемым. Наиболее практичный случай — сложный Flow, который работал месяцами, а после серии правок начал направлять файлы по неправильной ветке. Вместо ручного восстановления десятков параметров можно выбрать предыдущую ревизию.

Revisions не заменяют резервное копирование данных. Они относятся к конфигурации FileFlows, а не к копиям каждого обработанного видео. Если Replace Original уже заменил исходник, возврат ревизии Flow не вернёт прежний меди файл. Поэтому изменение опасных операций — Delete, Replace Original, массовый Move — лучше сначала проверять на отдельной библиотеке.

Доступ, пользователи и журнал аудита

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

При включённой защите внешним Agents требуется Access Token. Если после включения Security агент внезапно перестал подключаться, первым делом нужно проверить именно этот токен, а не FFmpeg или paths. Ошибка связи возникает ещё до запуска Flow, поэтому в такой ситуации файлы останутся в очереди, а журнал обработки конкретного файла ничего не покажет.

Access Control ограничивает IP-адреса для Web Console и удалённых сервисов. Правила применяются по порядку, и первое совпадение определяет разрешение или запрет. Если список правил непуст, адрес, не совпавший ни с одним разрешающим правилом, блокируется. Локальные соединения loopback разрешаются отдельно, что помогает восстановить конфигурацию с самого сервера.

Auditing записывает изменения, время и пользователя, который их выполнил. Для сложной установки это существенно: если ночью изменилась библиотека, отключился Agent или кто-то отредактировал Flow, журнал позволяет отличить человеческую правку от технического сбоя. Аудит доступен не только как общий журнал, но и в контексте отдельных объектов — Flows, Libraries, Agents, Plugins, Tasks и Webhooks.

Reporting: что можно понять после обработки

Reporting превращает историю выполнения в агрегированную статистику. Отчёты можно запускать вручную, а при соответствующей конфигурации — формировать по расписанию и отправлять по электронной почте. Для оценки медиатеки это полезнее случайной проверки одного файла: видны тенденции по размеру, кодекам, времени и библиотекам.

Codecs Report группирует обработанные данные по Video Codecs, Audio Codecs и Subtitle Codecs, показывает частоту и визуальное распределение. Параметр Direction позволяет анализировать входные или выходные метаданные. Сравнение двух направлений отвечает на простой вопрос: действительно ли Flow приводит библиотеку к целевому набору кодеков, или часть файлов остаётся в старом формате.

Files Processed показывает общее число файлов, суммарный исходный объём, время обработки, распределение по Agents, самые крупные файлы и самые долгие задания. Если один Agent регулярно попадает в список длительных задач, это повод проверить его encoder, скорость доступа к хранилищу и локальный temp. Если долгие задачи распределены случайно, причина может быть в самих исходниках.

Optimized Files ориентирован на сценарии оптимизации. Для записей отображаются Agent, encoder, resolution, число evaluations, VMAF, encoding value, время и сэкономленный объём. Такой отчёт полезен, когда автоматический подбор параметров работает на нескольких машинах и нужно понять, не даёт ли один encoder систематически худший результат по размеру или времени.

Processing Summary объединяет количество обработанных и неудачных файлов, объём данных, средний размер, storage saved, время, распределение по библиотекам и другие показатели. Его имеет смысл смотреть после массового изменения Flow. Если доля failed резко выросла, откатить конфигурацию безопаснее до того, как очередь дойдёт до всей медиатеки.

Flow Element Execution показывает, сколько раз запускался каждый элемент. Этот отчёт помогает находить мёртвые ветки. Если условие существует в графе, но соответствующий downstream-элемент никогда не выполняется, возможно, проверка сформулирована неверно или входные данные не имеют ожидаемого свойства. С другой стороны, неожиданно высокая частота тяжёлого элемента может показать, что фильтр перед ним пропускает слишком много файлов.

Практический сценарий: перевод H.264 в HEVC без повторной работы

Один из типичных потоков — привести H.264-библиотеку к HEVC, не перекодируя уже готовые файлы. На уровне Library выбирается видео и при необходимости ограничиваются расширения и каталоги. В Flow первым ставится Video File. Затем условие проверяет текущий video codec. Если он уже HEVC, ветка может завершиться или перейти к операциям, которые всё равно нужны, например проверке аудио. Если кодек другой, запускается FFmpeg Builder.

Базовая цепочка выглядит так: Video File → проверка кодека → FFmpeg Builder: Start → Video Encode → при необходимости Audio Convert → выбор контейнера → FFmpeg Builder: Executor → Replace Original. Перед Replace Original можно вставить проверку размера или пользовательскую функцию, которая остановит поток при подозрительном результате. Это защищает от ситуации, когда ошибка параметров дала файл, формально созданный успешно, но явно не соответствующий ожиданию.

Если библиотека содержит несколько аудиодорожек, не следует автоматически преобразовывать их все. Лучше задать Matching и перекодировать только кодек, который не поддерживается целевыми устройствами. Субтитры, к которым Flow не применял операции удаления или конвертации, Builder постарается перенести. При MP4 нужно отдельно оценить допустимость конкретных subtitle codecs.

Для первого запуска большого архива разумно сделать копирующий финал. Вместо Replace Original — Move File в тестовую директорию с сохранением относительной структуры. После выборочной проверки разных типов контента поток можно переключить на замену. Это не лишний этап, а способ отделить проверку логики от необратимого изменения библиотеки.

Практический сценарий: совместимый MP4 для телевизора

Если телевизор плохо воспроизводит часть MKV, задача может требовать не полного перекодирования, а правильного сочетания контейнера, видео и аудио. Сначала Video File определяет кодеки. Если видео уже H.264 или совместимый HEVC, его можно копировать. Неподдерживаемый формат отправляется в Video Encode. Для аудио, например DTS, задаётся выборочный Audio Convert в AAC или AC3 в зависимости от требований устройства.

После этого Remux to MP4 формирует выходной контейнер. Для HEVC при необходимости включается HVC1. Если исходные субтитры несовместимы с MP4, Flow должен либо преобразовать их поддерживаемым способом, либо удалить из контейнера и сохранить отдельно. Простое изменение расширения MKV на MP4 этой задачи не решает.

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

Практический сценарий: привести звук к единому профилю

Для аудионормализации и унификации сначала анализируется видео, затем Builder создаёт модель дорожек. Audio Convert работает по Matching: например, условие Codec равно DTS, либо Channels больше двух, либо Language совпадает с нужным языком. В зависимости от цели можно заменить дорожку или создать дополнительную совместимую версию.

Если в коллекции важны исходные lossless-дорожки, безопаснее не заменять их автоматически. Можно оставить оригинал и добавить совместимый track. Тогда пользователь устройства с ограниченной поддержкой выберет AAC/AC3, а исходная дорожка сохранится для основного просмотра. Стоимость такого подхода — больший размер файла.

Порядок аудиодорожек и флаги default нужно продумать заранее. Медиаплееры выбирают дорожки по своим правилам, и одинаковая структура библиотеки облегчает воспроизведение. Flow может ориентироваться на Language и Title, но качество результата зависит от корректности метаданных исходника.

Практический сценарий: внешние субтитры рядом с видео

Если в каталоге лежат Movie.mkv и Movie.srt, Subtitle Track Merge с Use Source Directory и Match Filename добавит подходящий файл к Builder. Для сериалов это безопаснее широкого поиска всех SRT в папке сезона. Pattern пригодится, если имена содержат язык, например отдельные варианты .ru. и .en..

После добавления можно указать язык и forced/default. Затем обычный Executor создаёт итоговый контейнер. Если целью является MKV, такой подход обычно проще, потому что контейнер хорошо подходит для разных subtitle streams. При MP4 следует заранее проверить совместимость целевого subtitle codec и при необходимости оставить субтитры внешними.

Практический сценарий: распределить 4K и 1080p между разными машинами

Пусть сервер хранения имеет слабый CPU, а отдельная машина — мощную GPU. На GPU-Agent разрешаются нужные библиотеки, задаётся более высокий Priority и подходящее число Runners. В Processing можно ограничить агент 4K или определёнными кодеками. Встроенный Agent сервера оставляется для лёгких 1080p или аудиозадач.

Дальше настраиваются Mappings. Серверный путь к медиа переводится в сетевой путь, доступный GPU-машине, а путь к FFmpeg при необходимости — в локальный путь executable. Temp Directory ставится на быстрый локальный SSD GPU-машины. В результате по сети читается исходник и записывается итог, а промежуточный файл не гоняется туда-сюда через хранилище.

Если обе машины могут аппаратно кодировать, не обязательно жёстко фиксировать encoder в одном Flow. Можно оставить Automatic и управлять допустимыми механизмами через agent Variables. Это упрощает общий сценарий, но перед массовым запуском стоит сравнить результаты разных hardware encoders, если важна однородность качества и размера.

Практический сценарий: обработка только полностью загруженных файлов

Каталог загрузчика часто создаёт файл сразу и увеличивает его размер по мере скачивания. Если Library наблюдает события файловой системы, объект может быть обнаружен до завершения. Для защиты используются Hold Minutes, File Detection Interval и Wait Time. FileFlows повторно убеждается, что файл перестал меняться, прежде чем передавать его в очередь.

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

Практический сценарий: обработка изображений

FileFlows способен применять похожую модель к изображениям. Image File загружает width, height, format, orientation и при наличии дату съёмки. Дальше можно проверять ориентацию, масштабировать, конвертировать формат, поворачивать и использовать дату в пути назначения. Например, Move File может строить каталоги по {img.DateTaken.Year} и {img.DateTaken.Month}.

Здесь особенно полезна проверка существования DateTaken. Пользовательская Function может завершать отдельной веткой файлы без EXIF-даты, вместо создания каталога с пустым именем. Такой принцип универсален: перед использованием переменной, которая зависит от метаданных, нужно предусмотреть отсутствие значения.

Как строить Flow так, чтобы его было проще сопровождать

Большой граф быстро превращается в трудночитаемую схему, если каждый случай решать отдельной длинной веткой. Первое правило — выносить повторяемые блоки в Sub Flows. Второе — использовать Variables для общих значений, а не копировать одинаковые пути. Третье — давать Flow и ключевым элементам понятные имена, чтобы журнал обработки читался без постоянного перехода в редактор.

Условия лучше располагать ближе к входу. Если известно, что 70% файлов уже HEVC, нет смысла сначала строить тяжёлую модель, запускать дополнительные проверки и только потом отсеивать их. Раннее ветвление уменьшает работу и делает журнал короче. Исключение — условие, которому нужны данные, появляющиеся только после конкретного анализатора.

Опасные операции следует держать ближе к концу. Delete, Replace Original и перемещение исходника должны выполняться только после того, как все преобразования успешно завершены. Если внешняя команда может вернуть код 0 при частичном результате, перед финалом стоит добавить собственную проверку наличия и размера файла.

Flow с аппаратным и программным fallback лучше строить явно. Например, основная ветка использует Video Encode с требуемым encoder, failure output ведёт к CPU-варианту, а обе успешные ветки сходятся перед сохранением. Это понятнее, чем скрывать сложную логику в одном скрипте, особенно когда ошибку затем анализирует другой администратор.

Типичные ошибки: файл не появляется в очереди

Если файл лежит в библиотеке, но отсутствует в Files, проблема обычно находится до Flow. Сначала проверяются Enabled, Path и расписание Library. Затем — File Types, Extensions, Filters и Exclusions. Для видео также нужно убедиться, что фильтры codec, resolution или duration не исключают исходник. После изменения правил можно запустить Rescan.

Если используется Top Level Only, объект в подпапке намеренно не обнаружится. Exclude Hidden пропустит скрытый каталог. File System Events могут не приходить с некоторых сетевых файловых систем, но периодическое сканирование должно обнаружить объект позже. Если этого не происходит, журнал сканера и права чтения важнее настроек FFmpeg.

Skip Already Processed способен исключить файл, который FileFlows уже считает обработанным. В таком случае Reprocess возвращает существующую запись в очередь, а Reset полностью пересоздаёт записи библиотеки. Эти операции неравнозначны и выбирать их нужно по тому, есть ли запись в базе и нужно ли сохранить историю.

Типичные ошибки: файл стоит в Unprocessed и не запускается

Когда файл уже виден, но не начинает обработку, нужно смотреть планирование. Проверьте, не стоит ли глобальная пауза, разрешено ли текущее время расписанием Library и Agent, есть ли свободные Runners и имеет ли Agent доступ к этой библиотеке. Ограничения Max File Size, Video Codecs и Resolutions на Agent также способны сделать задачу неподходящей для всех исполнителей.

Если один Agent имеет высокий Priority, но недоступен, сервер должен рассматривать другие подходящие исполнители. Однако если Flow или Library фактически рассчитаны только на него через mappings и variables, резервная машина может быть формально доступна, но упасть сразу после старта. В таких конфигурациях лучше явно ограничить библиотеки для каждого агента.

Типичные ошибки: FFmpeg не найден

Video plugin требует доступный FFmpeg. На системе, где executable находится в PATH, отдельная переменная может не понадобиться. Если путь нестандартный, его задают через Variables. Для удалённого Agent путь должен быть корректным именно на его машине; при различии систем используется mapping или agent-specific variable.

Ошибка часто возникает после переноса конфигурации с Windows на Linux или наоборот: в Flow остаётся абсолютный путь от другой системы. Ещё один вариант — контейнер видит другой файловый namespace. Проверять нужно из среды, где реально запущен Agent, а не из оболочки хоста.

Типичные ошибки: аппаратный encoder не запускается

Если явно выбран NVENC, QSV, AMF или VAAPI, FileFlows не может создать поддержку, которой нет в FFmpeg или драйвере. Нужно проверить, что Agent видит устройство и FFmpeg сообщает соответствующий encoder. В Docker отдельно проверяются проброс GPU, права устройства и нужные runtime-настройки.

Если аппаратный путь нестабилен, можно временно оставить Encoder = Automatic или запретить проблемный механизм через NoNvidia, NoQSV, NoAMD или NoVAAPI. Тогда очередь продолжит работать на другом доступном способе. Это лучше, чем принудительно повторять один и тот же падающий encoder для сотен файлов.

Смена bit depth может влиять на возможность аппаратного декодирования. В Automatic Executor учитывает совпадение глубины источника и цели. Поэтому неожиданное использование CPU не всегда означает ошибку детектирования GPU — иногда конкретная трансформация требует программного этапа.

Типичные ошибки: Agent видит задачу, но не видит файл

Сообщения вроде file not found на удалённом Agent чаще всего связаны с Mapping. Сервер передаёт путь, существующий в своей файловой системе, а Agent должен получить эквивалентный локальный или сетевой путь. Проверьте базовый префикс mapping, разделители, регистр на чувствительной к регистру файловой системе и фактическое подключение ресурса.

Следующий уровень — права. Сервис, под которым работает Agent, может не иметь тех же сетевых credentials, что интерактивный пользователь. Файл открывается в проводнике, но не из службы. Mapping здесь правильный, но чтение всё равно запрещено. Проверять доступ нужно от имени процесса Agent.

Типичные ошибки: временный диск заполняется

Полный Temp Directory способен прервать FFmpeg в середине длительного задания. При нескольких runners проблема появляется резко: свободного места хватает для одного файла, но не для нескольких параллельных. Рассчитывайте запас с учётом максимального исходника, возможного роста при промежуточном формате и количества одновременных задач.

Если временный каталог находится на системном диске, сбой может затронуть не только FileFlows. Для больших библиотек лучше вынести temp на отдельный том и контролировать его. Уменьшение Runners — быстрый способ снизить пиковое потребление, если добавить диск нельзя.

Типичные ошибки: выходной файл больше исходного

Больший размер не обязательно означает сбой. Причина может быть в слишком высоком Quality, неэффективном hardware encoder, сохранении нескольких дорожек или добавлении нового аудио без удаления старого. При fixed bitrate Flow мог задать значение выше исходного. Отчёт Savings и данные конкретного файла помогают отделить единичный случай от системной тенденции.

Если задача именно экономия, сначала определите, какие элементы добавляют данные. Проверьте число аудиодорожек до и после, наличие вложений и субтитров, значение encoder и профиль качества. Не стоит автоматически удалять результат только по условию размер не уменьшился: иногда цель Flow — совместимость, а не компрессия.

Типичные ошибки: Flow заканчивается раньше ожидаемого

Причина часто в выходах элементов. Если вызывается Output 2, а он не соединён, дальнейшая ветка не выполняется. При проверке кодека это может быть логичным для уже подходит, но если дальше должна выполняться общая операция, выход нужно свести к ней. Наведите курсор на порт и проверьте назначение каждого выхода.

У Function число, возвращаемое JavaScript, напрямую выбирает выход. Возврат 0 завершает Flow успешно, -1 — с ошибкой. Случайный return 0 вместо return 1 выглядит в журнале как нормальное завершение, поэтому проблема может не попасть в Failed. Это одна из причин, почему короткие функции стоит сопровождать понятными log-сообщениями.

Типичные ошибки: файл обрабатывается повторно

Повторный запуск может быть ожидаемым, если Downloads Directory специально настроен для повторной обработки успешно завершённых объектов. В других случаях причина — итоговый файл снова попадает под правила той же Library. Например, Flow меняет расширение, но новый файл остаётся в сканируемом каталоге и не помечается как уже обработанный по ожидаемой логике.

Чтобы избежать циклов, разделяйте вход и выход либо используйте чёткие исключения. Если файл заменяется на месте, убедитесь, что после преобразования он соответствует условию ничего делать не нужно. Для HEVC-перехода это естественно: повторный анализ видит HEVC и заканчивает ветку без кодирования. Для произвольного внешнего скрипта такой признак придётся создать самостоятельно.

Типичные ошибки: внешние субтитры не находятся

Проверьте Use Source Directory. После нескольких стадий текущий рабочий каталог может быть временным, где исходного SRT нет. Если внешние субтитры лежат рядом с исходником, поиск должен идти в source directory. Затем проверьте Match Filename и Pattern: регулярное выражение, рассчитанное на .eng.srt, не найдёт .en.srt, если это не предусмотрено.

На распределённом Agent внешний subtitle-файл должен быть доступен через тот же mapping, что и видео. Наличие видеопути не гарантирует, что соседний файл разрешён правами или проброшен в контейнер. При успешном обнаружении Builder добавляет субтитр как отдельный input, поэтому ошибка доступа проявится до финального mux.

Типичные ошибки: после remux пропала дорожка

Builder старается копировать нетронутые streams, но целевой контейнер должен поддерживать их. Если контейнер не принимает конкретный subtitle, attachment или audio codec, FFmpeg может отказаться выполнять команду или потребовать преобразование. Поэтому перед массовым remux полезно составить список кодеков в исходной библиотеке через Reporting и понять, какие сочетания встречаются.

Для сложной медиатеки безопаснее ветвить Flow: полностью совместимые файлы быстро remux, несовместимые сначала преобразуют только проблемные дорожки. Это заметно экономит время по сравнению с безусловным полным перекодированием каждого файла.

Formulas: более простой путь для стандартной медиаобработки

Помимо графических Flows в FileFlows есть Formulas — форма с выпадающими списками, переключателями и ползунками для типовых задач. Formulas относятся к лицензируемым функциям и рассчитаны на случаи, когда не нужны сложные ветвления, внешние процессы и собственный JavaScript. Если требуется просто задать единый профиль видео, аудио или изображений, формула быстрее настраивается и легче читается.

При создании Library можно выбрать, чем обрабатывать её содержимое: Flow или Formula. Это важное различие. Flow даёт максимальный контроль над последовательностью и условиями; Formula скрывает внутреннюю механику и предлагает высокоуровневые параметры. Для администратора нескольких библиотек такой подход позволяет держать простые задачи простыми, а графический редактор использовать только там, где действительно нужна логика.

Video Formula

Video Formula разделена на General, Video, Audio и Subtitles. В General задаётся имя, описание, целевой контейнер и общие правила. Для Video можно выбрать Copy Video или Custom Video. В пользовательском режиме создаются profiles по разрешению — SD, 720p, 1080p, 1440p, 4K или Any. FileFlows выбирает подходящий профиль на основе разрешения входа, поэтому одна формула способна кодировать 4K и 1080p по разным правилам без ручного рисования нескольких веток.

Для профиля выбираются codec и encoder, а метод кодирования может ориентироваться на bitrate, quality или оптимизацию. В режиме bitrate можно задавать фиксированный поток или целевой общий размер. В режиме quality доступны качество и скорость. Оптимизированный режим предлагает уровни качества и глубину анализа, а также реакцию на превышение целевого размера. Наличие этих вариантов не отменяет необходимости понимать конечную задачу: максимально маленький файл и сохранить заданный уровень качества требуют разных методов.

Video Formula также умеет управлять масштабированием, frame rate и обрезкой чёрных полос. Такие функции удобны для библиотек с предсказуемым типом контента. Но если решение зависит от нестандартного условия — например, от имени каталога, результата API-запроса или свойства, вычисленного скриптом, — полноценный Flow остаётся более подходящим.

В аудиочасти Video Formula можно оставить исходные дорожки или создать собственные profiles по языку, codec, channels, bitrate и sample rate. Для нормализации предусмотрены готовые режимы. В разделе субтитров доступны копирование, удаление или пользовательская обработка, фильтрация языков и типов, стандартизация текстовых форматов, а при соответствующей инфраструктуре — генерация отсутствующих субтитров и преобразование некоторых графических дорожек в текст.

Audio Formula и Image Formula

Audio Formula задаёт целевой codec, bitrate, sample rate и режим normalization. Для обычной автоматизации музыки, подкастов или служебных аудиофайлов этого достаточно: не нужно собирать отдельный Flow из анализатора, конвертера и финального перемещения. При выборе lossless-формата логика bitrate меняется, потому что итоговый поток определяется содержимым, а не фиксированным ограничением.

Image Formula настраивает формат и масштабирование. Доступны JPEG, PNG, WebP, ICO и ICNS, а режимы изменения размера включают Cover, Contain, Pad и Fill. Разница между ними принципиальна: Cover может обрезать края, Contain сохраняет всё изображение, Pad добавляет поля, Fill растягивает картинку под точные размеры. Поэтому для массовой обработки фотографий нельзя выбирать режим только по названию — нужно заранее решить, допустима ли обрезка или искажение.

Manually Add: разовый запуск без отдельной Library

Files позволяет вручную добавлять файлы и URL для обработки. Сначала выбирается Flow, затем входные элементы вводятся списком или большим текстовым блоком, где каждая строка представляет отдельный объект. Это удобно для разовой миграции или проверки нового Flow, когда создавать постоянную библиотеку ради нескольких файлов не хочется.

Для вручную добавленных объектов можно передать Custom Variables. Например, один и тот же Flow сохраняет результат в путь, полученный из переменной, а при ручном запуске этот путь задаётся отдельно для конкретной партии. Такой механизм делает Flow переиспользуемым и позволяет тестировать разные ветки без редактирования самой схемы.

Ручное добавление не заменяет Library для постоянной автоматизации. В нём нет той же логики периодического обнаружения, file-system events и фильтрации источника. Его основная ценность — контролируемый запуск конкретного набора входов через уже существующий Flow.

Logging и диагностика обнаружения

Обычный журнал файла показывает выполнение Flow, но проблемы могут возникнуть раньше — на стадии Library Scanner. Для этого существует Verbose Library Logging. Он увеличивает детализацию поиска и помогает понять, почему конкретный путь был принят или исключён. После решения проблемы подробный режим следует отключать, иначе объём логов растёт быстрее и полезные сообщения теряются среди повторяющихся записей.

Log Every Request нужен для диагностики взаимодействия Web Console, API или внешних компонентов, но тоже не является режимом на каждый день. Log File Retention и Library File Log Retention задают срок хранения. Значение 0 для журналов файлов означает отсутствие автоматического удаления, что полезно для аудита, но требует контроля дискового пространства.

При поиске ошибки важно выбрать правильный журнал. Если файл не обнаружен — смотрят Library logging. Если обнаружен, но не назначается — проверяют расписания и Agent. Если стартует и падает — открывают file log. Если внешний Agent исчезает — исследуют его соединение и системный журнал. Такой порядок экономит время: FFmpeg-команда не может объяснить, почему файл никогда не дошёл до Flow.

Резервные копии конфигурации

В лицензируемой конфигурации FileFlows умеет создавать backups, запускать их по расписанию, экспортировать, импортировать и восстанавливать. Резервная копия содержит базу с Flows, Libraries, файлами и другими записями, ключевые настройки сервера и загруженные plugins. Это резерв системы управления, а не копия медиатеки.

Restore или Import заменяет текущую конфигурацию содержимым backup. Значит, изменения, сделанные после даты резервной копии, будут потеряны. Перед восстановлением нужно понимать, что заменяются не только один Flow или одна Library. Для точечного возврата отдельного объекта лучше использовать Revisions, если эта функция доступна.

Автоматические backups имеют frequency и retention. Для активно изменяемой установки разумно хранить несколько точек во времени и периодически экспортировать резерв за пределы системного диска. Резерв, который лежит только в том же хранилище, что и рабочая база, плохо защищает от отказа диска.

Производительность: где обычно находится узкое место

Скорость FileFlows определяется не одной настройкой. Для перекодирования важны encoder и число параллельных задач; для remux — скорость дисков и сети; для массового сканирования — файловая система и правила обнаружения; для распределённой обработки — доступ Agents к исходнику и temp. Поэтому увеличение Runners не является универсальным ускорением.

Если один NVENC-процесс загружает GPU лишь частично, второй runner может повысить общую пропускную способность. Но если GPU уже занят полностью или ограничен видеопамятью, параллельное кодирование только увеличит конкуренцию. Аналогично CPU-кодирование нескольких 4K-файлов может снизить скорость каждого настолько, что общий выигрыш окажется минимальным.

Для сетевого хранилища нужно учитывать одновременное чтение и запись. При четырёх Agents каждый может читать большой исходник и писать итог, а сервер параллельно обслуживает медиаплееры. В такой среде ограничение Library Max Runners иногда даёт более стабильный результат, чем максимальная загрузка всех GPU. Автоматизация ценна именно тем, что может работать долго и предсказуемо; максимальный пик скорости не всегда является лучшей конфигурацией.

Remux и копирование чаще упираются в I/O, чем в CPU. Если такие задания запускаются вместе с тяжёлым encode на том же механическом диске, случайные обращения могут снизить скорость обоих типов работы. Разделение библиотек по расписанию или Agents помогает не только распределять вычисления, но и управлять дисковой нагрузкой.

Ограничения и особенности, которые важно учитывать

FileFlows требует первоначального проектирования процесса. Графическая схема упрощает понимание сложной автоматизации, но не избавляет от необходимости знать, что такое контейнер, codec, stream, remux, encoder и права файловой системы. Ошибка в последнем шаге Move или Replace Original способна затронуть тысячи файлов, потому что система предназначена именно для массового выполнения одних и тех же правил.

Видеообработка зависит от FFmpeg. Поддержка кодеков и hardware acceleration определяется сборкой FFmpeg и окружением конкретного Agent. Нельзя считать, что наличие пункта в интерфейсе гарантирует аппаратную поддержку на любой машине. В распределённой установке это особенно заметно: одинаковый Flow выполняется на разных ОС и GPU.

Часть функций требует лицензии. К ним относятся, в частности, Formulas, Tasks, многие расширенные параметры библиотек и агентов, Revisions, Reporting, механизмы пользователей и доступа, внешний database, File Server и отдельные продвинутые функции видео. Точный набор доступных возможностей следует смотреть в своей лицензии; строить критичный Flow вокруг опции, которой нет в используемом уровне, не стоит.

Сложные Flows со скриптами трудно переносить без документации. Визуальный граф показывает соединения, но не всегда объясняет бизнес-правило, скрытое в Function или внешнем script. Поэтому полезно заполнять Description, давать говорящие имена и выносить общие куски в Sub Flows. Это снижает риск, что через полгода никто не поймёт, почему определённая ветка существует.

Автоматическая замена оригиналов требует резервной стратегии. Revisions восстанавливают конфигурацию, backups — состояние FileFlows, но ни то ни другое не является резервной копией исходной медиатеки после Replace Original. Если исходник ценен, нужно отдельно решить, где хранится его резерв или как долго тестовый результат должен жить до окончательной замены.

Сравнение FileFlows с аналогами

Программа	Лучше подходит для	Главное ограничение
FileFlows	Визуальных многошаговых сценариев для видео, аудио, изображений и обычных файлов с условиями, скриптами и распределёнными Agents	Сложный Flow требует продуманной логики; часть расширенных функций лицензируется
Tdarr	Распределённой автоматической транскодировки больших медиатек с Server, Nodes, Workers и plugin/flow-логикой	Сильнее сфокусирован на медиатранскодировании, чем на произвольных файловых процессах
Unmanic	Постоянной оптимизации библиотек через последовательность plugins, scanner/event monitoring и workers	Логика строится вокруг plugin stages и менее свободна как универсальный визуальный граф
Transcodarr	Автоматического перекодирования в инфраструктуре Radarr/Sonarr с ориентацией на совместимое воспроизведение	Сценарий заметно уже и сильнее привязан к экосистеме *arr и медиасерверу
Sickbeard MP4 Automator	Скриптовой конвертации и тегирования после загрузки с интеграциями Sonarr, Radarr и download clients	Конфигурация преимущественно файловая и скриптовая, без сопоставимого визуального редактора

Практический выбор зависит от того, насколько далеко задача выходит за рамки транскодировать библиотеку. Если нужен распределённый конвейер именно для видео и хочется сильной специализации на транскодировании, Tdarr остаётся прямым конкурентом. Если важна простая модель постоянной оптимизации через plugins и workers, Unmanic может быть быстрее в освоении. Если процесс жёстко связан с Sonarr/Radarr, более узкие инструменты уменьшают количество настроек.

FileFlows заметно выигрывает там, где один сценарий должен совмещать анализ, ветвления, FFmpeg, работу с каталогами, скрипты, переменные и несколько исполнителей. За эту гибкость приходится платить сложностью схемы. Для простого разового перекодирования нескольких файлов такая оркестрация избыточна; для постоянно меняющейся библиотеки с разными правилами она, наоборот, позволяет убрать ручные операции.

Когда FileFlows подходит лучше всего

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

Второй сильный сценарий — несколько машин с разными ресурсами. FileFlows позволяет отделить сервер управления от исполнителей, назначить Agents библиотекам, настроить mappings и распределить параллельную работу. Это даёт возможность использовать GPU рабочего компьютера ночью, а днём оставлять лёгкие задачи на сервере.

Третий сценарий — процесс, который не помещается в один preset конвертера. Когда после видео нужно вызвать внешний скрипт, проверить размер, добавить тег, уведомить систему, выбрать ветку по метаданным и только затем переместить результат, визуальный Flow становится понятнее цепочки shell-скриптов и cron-задач, разбросанных по нескольким машинам.

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

Если требуется вручную перекодировать один ролик, обрезать его или быстро получить файл для телефона, FileFlows добавляет лишний слой настройки. Для такого случая удобнее программа, рассчитанная на интерактивный экспорт. FileFlows раскрывается, когда один и тот же процесс будет повторяться автоматически.

Если все файлы всегда проходят одну FFmpeg-команду и не нужны Web Console, очередь, история и распределение, небольшой скрипт может быть проще. Однако по мере появления исключений — разные codecs, несколько аудиоязыков, ограничение по размеру, отдельные Agents — скрипт обычно обрастает условиями, и тогда визуальная модель начинает окупаться.

Если задача сводится только к распределённой транскодировке видео, стоит сравнить FileFlows с Tdarr и Unmanic на уровне привычного способа настройки. У этих систем разные модели: граф, plugins/stages и специализированные worker pipelines. Выбор лучшей программы без учёта способа администрирования здесь мало полезен.

Рекомендуемый порядок первой настройки

1. Создать тестовую Library на небольшом каталоге, а не сразу указывать весь архив.
2. Собрать минимальный Flow с Video File или Input File и безопасным финалом через Copy/Move в отдельный каталог.
3. Проверить Variables и путь к FFmpeg на каждом Agent, который будет выполнять медиаоперации.
4. Добавить условия, которые пропускают уже соответствующие файлы, чтобы повторный scan не запускал лишнюю работу.
5. Настроить audio/subtitle правила и контейнер, затем проверить несколько файлов с разными дорожками.
6. Только после стабильной работы включить Replace Original, Delete или другие необратимые шаги.
7. При распределении подключать Agents по одному, проверяя mappings, temp и hardware encoders на каждой машине.
8. После переноса Flow на основную Library следить за Failed, Savings и временем обработки, а не только за тем, уменьшается ли очередь.

Такой порядок отделяет ошибки логики от ошибок инфраструктуры. Если минимальный Flow не может прочитать файл, нет смысла настраивать VMAF. Если один Agent успешно выполняет задачу, а второй нет, проблема почти наверняка относится к его путям, FFmpeg, драйверу или правам. Пошаговое усложнение делает журнал FileFlows действительно полезным, потому что после каждого изменения известно, какая новая часть могла вызвать сбой.

Итог

FileFlows — инструмент для тех случаев, когда обработку файлов нужно превратить в постоянно работающий конвейер. Libraries отвечают за обнаружение и расписание, Flows — за логику, plugins и scripts — за операции, Agents — за вычислительные ресурсы, а Files и Reporting — за контроль результата. Для видео связка Video File и FFmpeg Builder позволяет анализировать дорожки и собирать преобразование из отдельных шагов, не превращая каждый сценарий в непрозрачную командную строку.

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