Рассмотрены инженерные решения, лежащие в основе разработанного программного инструмента, который автоматически совмещает звуковую дорожку с видеорядом по движениям губ диктора. Инструмент написан на Python, имеет кроссплатформенную модульную организацию и использует ранее обученную свёрточно-темпоральную модель с контрастивной целевой функцией InfoNCE. Такая модель проецирует визуальный и акустический сигналы в единое векторное пространство. Сопоставление выполняется в два прохода. Сначала с шагом в 1 с пакетно строятся эмбеддинги для пятисекундных блоков, из которых формируется матрица косинусных сходств. Затем результат фильтруется: устраняются выбросы по медиане, контролируется монотонность аудиопозиций, а подряд идущие совпадения объединяются в общие сегменты. Пользователь может работать через окно на PyQt6 либо вызывать инструмент из терминала в пакетном режиме. Итоговый файл MP4 собирается с помощью утилиты FFmpeg. По итогам испытаний на 50 контрольных парах вида «короткий видеоролик — длинная звуковая запись» доля верно локализованных совпадений достигла 92,0 % при средней абсолютной погрешности начала корректно найденного отрезка 71 мс. Полный цикл обработки одной такой пары занимает 9,2 с при использовании видеокарты NVIDIA RTX 3060 и 37,7 с — на процессоре ноутбучного класса Intel Core i7.
1. Введение
Дистанция между обученной нейронной сетью и работающим инструментом синхронизации обычно оказывается значительно длиннее, чем принято считать. Сама модель способна переводить кадр области губ и фрагмент мел-спектрограммы в один и тот же эмбеддинг-вектор, однако конечному пользователю требуется не вектор, а собранный MP4-файл, в котором ранее записанная звуковая дорожка корректно совмещена с ранее снятым видео. Промежуток между этими двумя состояниями — прикладная задача со своей внутренней структурой. Она включает следующие этапы: подготовка входных потоков (приведение кадра к стандартному виду, выделение области губ, преобразование звука в мел-представление), посегментная обработка данных через сеть, аккуратное установление соответствия между полученными векторами, удаление выбросов, восстановление непрерывной временной оси, передача данных во внешний сборщик, наглядное отображение результата в интерфейсе. У каждого из перечисленных шагов имеются собственные инженерные нюансы, которые существенно сказываются как на качестве итога, так и на эксплуатационные характеристики всей системы
[1]
Подавляющее большинство публично доступных реализаций актуальных моделей аудиовизуальной синхронизации — SyncNet
[2][3][4]
Вторая существенная трудность связана со сменой постановки задачи. Вместо оценки одного смещения между двумя заведомо согласованными фрагментами требуется находить соответствия между коротким видеоотрывком и длинной аудиозаписью. Именно такой сценарий типичен для практики: у монтажёра обычно есть видеоклип длительностью 10–30-секунд (или несколько подобных клипов) и аудиозапись интервью либо подкаста продолжительностью в час и более. При этом нужно определить, в какой точке длинной записи находится фрагмент, содержательно соответствующий клипу. Простая модель, которая выдаёт для пары отрезков одно скалярное число, в этом случае непригодна. Необходимо построить отображение оси видеовремени в ось аудиовремени — оно должно отражать структуру всего материала.
В представленной статье излагается архитектура и реализация программного комплекса, в котором обе указанные задачи решаются совместно. Используемая нейросетевая модель — свёрточно-темпоральная сеть, обученная с контрастивной функцией потерь InfoNCE, — подробно описана и обоснована в
[5][6]
2. Архитектура программного комплекса
В качестве среды реализации выбран Python 3.10; комплекс выполнен в виде модульного кроссплатформенного приложения. Нейросетевые операции выполняет PyTorch, обработка видео опирается на связку OpenCV и MediaPipe, обработка аудио — на Librosa и soundfile, оконный интерфейс построен на PyQt6 (с интегрированным через Matplotlib просмотром графиков), а сборку итогового файла осуществляет внешний процесс FFmpeg. На этапе проектирования последовательно применялся ряд принципов, которые заранее задают общий облик кодовой базы и упрощают её последующее сопровождение
[7]
Функциональная декомпозиция. Кодовая база разбита на шесть функциональных подсистем: подготовка видеопотока, подготовка аудиопотока, синхронизация, обучение и оценка модели, графический интерфейс и сбор обучающих данных. Каждой подсистеме отведён собственный Python-пакет, и каждая решает строго одну задачу. Обмен данными между подсистемами организован через простые структуры — массивы NumPy, тензоры PyTorch и словари, описывающие результат.
Централизованная конфигурация. Ключевые числовые параметры — разрешение области губ (96×96 пикселей), количество мел-фильтров (80), длительность блока грубого выравнивания (5 с), шаг скользящего окна (1 с), размер мини-пакета при инференсе (64 фрагмента), а также пороги постобработки — собраны в одном конфигурационном файле config.py. Такое решение существенно повышает воспроизводимость экспериментов и упрощает подбор настроек под конкретный сценарий применения.
Двойной режим вычислений (CPU и GPU). Все компоненты, взаимодействующие с нейронной сетью, при запуске проверяют наличие CUDA-совместимого ускорителя: при его обнаружении задействуют GPU, при отсутствии — автоматически переходят на CPU. Эта возможность принципиально важна, поскольку среди потенциальных пользователей комплекса — не только обладатели рабочих станций с дискретной видеокартой, но и журналисты или монтажёры, работающие на обычном ноутбуке без выделенного GPU.
Файловая иерархия комплекса спроектирована по принципу «одна папка — одна подсистема». Единая точка входа — модуль av_sync/main.py; режим работы выбирается первым позиционным аргументом командной строки: gui (открытие графического окна; используется по умолчанию, если аргументы отсутствуют), preprocess <dir> (пакетная подготовка указанного каталога с видеофайлами), train (запуск цикла обучения), evaluate (расчёт метрик на отложенной выборке), download <url или поисковый запрос> (загрузка одиночного видеоматериала по ссылке либо по запросу к видеохостингу), sync <видео> <аудио> [output] (синхронизация одной пары без графического интерфейса). Массовое наполнение датасета одной команды выполняет отдельный высокоуровневый скрипт download_training_data.py, описанный в разделе 6. Универсальность точки входа делает комплекс одинаково удобным как для интерактивной работы, так и для встраивания в автоматизированные конвейеры массовой обработки мультимедиа.
Конвейер обработки в пользовательском режиме «синхронизация» устроен следующим образом. Подсистема подготовки видео принимает входной файл, в каждом кадре находит лицо с помощью MediaPipe FaceLandmarker, по 11 опорным точкам выделяет прямоугольную область губ, приводит её к фиксированному размеру 96×96 пикселей и складывает результат в трёхмерный массив формы
Содержание задач каждой подсистемы и набор её ключевых внешних зависимостей представлены в таблице 1.
Подсистемы программного комплекса и набор их внешних зависимостей
| Подсистема | Функция | Зависимости |
| Предобработка видео | Локализация лица, выделение области губ, нормализация | OpenCV, MediaPipe |
| Предобработка аудио | Загрузка, ресэмплирование, вычисление мел-спектрограммы, сегментация | Librosa, soundfile |
| Синхронизация | Пакетное вычисление эмбеддингов, матрица сходств, постобработка | PyTorch, NumPy |
| Обучение и оценка | Цикл обучения, валидация, расчёт retrieval-метрик | PyTorch, scikit-learn |
| Графический интерфейс | Главное окно, выбор файлов, прогресс, визуализация результата | PyQt6, Matplotlib |
| Сбор датасета | Автоматическая загрузка обучающих видеоматериалов по запросам | yt-dlp |
Принятая декомпозиция позволяет независимо развивать и проверять каждую подсистему в отрыве от остальных. Так, при появлении более точной нейросетевой модели достаточно заменить файл чекпоинта, не затрагивая остальной код. Чтобы добавить поддержку нового видеоформата, требуется доработать только подсистему подготовки видео. Графический интерфейс отделён от вычислительной части и при необходимости может быть заменён на веб-фронтенд либо встроен в стороннее приложение для видеомонтажа.
3. Подсистема предобработки данных
Поступающий видеопоток обслуживает класс
Локализацию лица обеспечивает MediaPipe FaceLandmarker
[8]
Если детектор не обнаружил лица в очередном кадре (например, говорящий отвернулся или сцена содержит только крупный план без лица), используется последний валидный ограничивающий прямоугольник. Если лицо отсутствует в нескольких подряд идущих кадрах, текущий кадр заполняется нулями и помечается флагом «невалидный». При последующей синхронизации такие кадры исключаются из вычислений: их вклад в эмбеддинг блока обнуляется, а веса при усреднении соответствующим образом перенормируются.
Класс
Такое жёсткое временно́е соответствие между видео- и аудиоканалами — обязательное требование архитектуры сети: совместное эмбеддинг-пространство построено в предположении, что каждый видеокадр сопоставлен акустическому сегменту равной длительности. Любое нарушение этого баланса, в частности отклонение реальной частоты кадров входного видео от номинальной, ведёт к деградации синхронизации. Поэтому при неоднозначном fps подсистема подготовки видео выводит соответствующее диагностическое сообщение и приводит частоту кадров к 25 Гц линейной интерполяцией. Согласованная с ней подсистема подготовки аудио оперирует уже корректным потоком кадров.
4. Двухступенчатый алгоритм сопоставления
Пусть
На грубом этапе и видеоряд, и спектрограмма нарезаются на перекрывающиеся блоки длительностью 5 с (125 кадров) со сдвигом в 1 с (25 кадров). Для каждого блока пакетно рассчитывается эмбеддинг соответствующей модальности с помощью обученных энкодеров
Пусть
В матрице каждая строка соответствует отдельному видеоблоку, а каждый столбец — отдельному аудиоблоку. Элемент
где
Выбор шага скользящего окна в 1 секунду является компромиссным. Уменьшение шага обеспечивает более плотное покрытие, но пропорционально увеличивает количество прогонов через сеть и общее время обработки. Увеличение шага, наоборот, ускоряет вычисления, однако повышает риск пропустить точную точку совпадения. На тестовой подвыборке при шаге в 1 с алгоритм корректно отыскивает совпадение в 92,0% случаев; при шаге в 2 с этот показатель падает до 88,4%, а при шаге в 0,5 с возрастает лишь до 92,8%, что не окупает почти двукратного замедления. Размер мини-пакета (64 блока) подобран таким образом, чтобы загрузить вычислительные ресурсы GPU NVIDIA RTX 3060 и при этом удерживать пиковое потребление видеопамяти в пределах 4 ГБ.
Грубый этап возвращает по одному кандидату на каждый видеоблок, и среди них неизбежно встречаются ошибочные — например, фрагменты с тишиной, короткими речевыми паузами или невнятной артикуляцией. Использовать такой результат без дополнительной обработки невозможно: в нём могут попадаться отдельные «выбросы», когда несколько соседних видеоблоков получили совпадения в близких аудиопозициях, а один — в семантически не связанной точке записи.
Очистка совпадений выполняется методом
Каждому полученному сегменту приписывается средний уровень уверенности по всем входящим в него совпадениям; впоследствии это число используется при сортировке выдачи. Сегменты с уверенностью ниже эмпирически подобранного порога 0,3 по умолчанию сопровождаются предупреждением: модель в их корректности не уверена, и пользователю желательно проверить такой результат вручную.
Точность работы двухступенчатого алгоритма проверялась на тестовой подвыборке из 50 пар вида «короткое видео — длинная аудиозапись». В каждой паре видеоматериал представлял собой фрагмент длительностью от 10 до 30 секунд, выделенный из записей, не пересекающихся с обучающей частью датасета. Аудиоматериал — полная запись, охватывающая этот фрагмент, с длительностью от 10 до 60 минут. Используемые метрики и их значения представлены в таблице 2.
Показатели качества двухступенчатого алгоритма на тестовой подвыборке из 50 пар
| Метрика | Значение |
| Доля правильно найденных совпадений, % | 92,0 |
| Средняя абсолютная ошибка начала сегмента, мс | 71 |
| Медианная абсолютная ошибка, мс | 44 |
| Доля случаев с ошибкой начала < 100 мс, % | 78,0 |
| Доля грубых ошибок (>1 с или неверный сегмент), % | 8,0 |
Цифры 92,0% верно отыскиваемых совпадений и 71 мс средней абсолютной погрешности по началу корректного сегмента отвечают уровню, готовому к серьёзной эксплуатации. В большинстве сюжетов видеоредактору достаточно просто принять предлагаемый результат, тогда как для 8% трудных случаев низкая уверенность модели сразу подсвечивает необходимость ручного контроля. Промежуточная категория — примерно 14% пар — попадает в диапазон погрешности в 0,1–1,0 с. Здесь, как правило, достаточно слегка скорректировать границы вручную. Все зафиксированные грубые сбои (та самая доля в 8%) приходятся на ролики с откровенно низким качеством записи, заметным фоновым шумом и одновременным присутствием в кадре нескольких говорящих — то есть на условия, в которых модель не тренировалась.
5. Подсистема автоматизированного сбора датасета
Качественное обучение нейросети невозможно без репрезентативной коллекции видеозаписей с крупным планом лица говорящего
[9][10][11][12]
Высокоуровневая логика массового сбора реализована в отдельном скрипте download_training_data.py. Он обрабатывает заранее подготовленный список из 40 англоязычных поисковых запросов, охватывающих разнообразные сюжеты с одиночным говорящим: интервью, подкасты, лекции, обучающие материалы и обзоры. Для каждого запроса скрипт скачивает по три ролика. Между запросами выдерживается пятиминутная пауза — это снижает вероятность временной блокировки со стороны видеохостинга. Перед каждым новым запросом проверяется объём свободного места на диске: если он падает ниже 30 ГБ скрипт аккуратно завершает работу, сохраняя всё ранее загруженные файлы. Состав запросов специально подобран так, чтобы обеспечить вариативность условий съёмки, ракурсов, освещения, голосов и тем — без этого обучаемая модель не получит достаточной обобщающей способности.
Когда загрузка завершена, скачанные ролики проходят пакетную предобработку, которую запускает команда python -m av_sync.main preprocess <video_dir>. В ходе предобработки формируются серии кадров с губами, рассчитываются мел-спектрограммы, которые затем нарезаются под видеокадры. Итог записывается на диск в формате .npy с поддержкой memory-mapping. Такая схема хранения избавляет от необходимости держать весь датасет в RAM при дальнейшей работе. Файлы, прошедшие обработку ранее, пропускаются автоматически — это даёт возможность инкрементально дополнять корпус новыми записями. Если обработка отдельного ролика срывается (например, видеоконтейнер повреждён либо в кадрах не нашлось лица), скрипт пишет об этом в журнал и переходит к следующему файлу, не останавливая обработку остальных.
6. Интерфейсы пользователя
Оконный интерфейс реализован на PyQt6 — официальной привязке Python к фреймворку Qt 6, который давно стал отраслевым стандартом для кроссплатформенных настольных приложений. Главное окно поделено на четыре функциональные зоны: панель выбора входных файлов (видео и аудио — через системные диалоги открытия файлов), панель прогресса с указанием текущей стадии обработки, область визуализации полученного результата и панель управления экспортом.
Визуальная зона ответа включает два связанных компонента: тепловую карту, которая отрисовывает матрицу косинусных сходств, и табличный перечень обнаруженных сегментов. Тепловую карту строит Matplotlib
[13]
Ресурсоёмкие стадии обработки — подготовка видео, инференс сети и сборка итогового файла — вынесены в отдельный QThread, что предотвращает «зависание» основного потока GUI. Прогресс передаётся в главное окно посредством механизма сигналов Qt и отображается в виде процентной шкалы с подписью текущего этапа. При прерывании операции пользователем (нажатии кнопки «Отмена») во внутреннем потоке устанавливается флаг отмены, который регулярно проверяется во всех длительных циклах подсистем. Благодаря этому циклы корректно завершают работу и освобождают захваченные ресурсы.
Для удобства встраивания инструмента в автоматизированные конвейеры, предусмотрен запуск без графической оболочки. Весь цикл обработки поднимается одной командой python -m av_sync.main sync video.mp4 audio.wav output.mp4. На выходе сохраняется готовый файл по указанному пути, а в стандартный вывод поступают журнал работы и числовые показатели качества в формате JSON, что упрощает их подхват внешними инструментами. Стандартный код выхода (нулевой при удаче, иной — при ошибке) делает инструмент совместимым со скриптовыми оболочками Bash и PowerShell, утилитой Make и привычными системами непрерывной интеграции.
7. Эксплуатационные характеристики
Замеры производительности проводились на трёх показательных конфигурациях: рабочей станции с GPU NVIDIA RTX 3060, ноутбуке с процессором Intel Core i7-12700H без отдельного графического ускорителя и облачной виртуальной машине с 4 vCPU. Тестовая нагрузка во всех случаях была одна и та же — пара «видеоклип длиной 10 с в 720p плюс 15-минутная звуковая запись». На каждой конфигурации фиксировались две величины: полное время прохода и пик потребления памяти. Сводка результатов представлена в таблице 3.
Время обработки одной пары для различных пользовательских конфигураций
| Этап | RTX 3060 (GPU) | Intel i7 (CPU) | VM 4 vCPU |
| Предобработка видео, с | 3,2 | 3,5 | 4,1 |
| Предобработка аудио, с | 1,8 | 2,1 | 2,4 |
| Инференс сети, с | 1,4 | 23,8 | 47,2 |
| Постобработка матчей, с | 0,2 | 0,2 | 0,3 |
| Сборка MP4 (FFmpeg), с | 2,6 | 8,1 | 12,7 |
| Полное время, с | 9,2 | 37,7 | 66,7 |
| Пик ОЗУ, ГБ | 2,1 | 2,3 | 2,5 |
| Пик видеопамяти, ГБ | 3,4 | – | – |
При использовании отдельной видеокарты NVIDIA RTX 3060 полный проход одной пары укладывается в 9,2 с. При этом непосредственно прогон через сеть отнимает порядка 1,4 с, а основная часть времени уходит на подготовительные стадии и финальную сборку. Если же расчёт выполняется исключительно на CPU ноутбука Intel Core i7-12700H, то общее время вырастает до 37,7 с. Примерно 24 с из них тратятся на инференс: здесь даёт себя знать отсутствие того массового параллелизма по блокам, который GPU обеспечивает «бесплатно». В сценарии облачной виртуальной машины с 4 vCPU время обработки увеличивается до 66,7 с — это самый медленный из проверенных режимов, однако и в нём инструмент остаётся работоспособным. Что касается потребления памяти, верхняя планка ОЗУ во всех трёх замерах не превышает 2,5 ГБ. Диапазон 2,1–2,5 ГБ обусловлен разной кэш-стратегией с GPU и без него. Пиковое потребление видеопамяти остаётся в пределах 3,4 ГБ — такие требования вполне посильны даже для бюджетных потребительских ускорителей.
8. Заключение
В настоящей статье изложены архитектура и двухступенчатый алгоритм сопоставления, образующие основу программного комплекса автоматической синхронизации аудио- и видеопотоков по артикуляции говорящего. Сформулируем главные итоги.
1. Построена модульная архитектура комплекса, объединяющая шесть функциональных подсистем — подготовку видео, подготовку аудио, собственно синхронизацию, обучение и оценку, графический интерфейс и сбор обучающих данных, — которые связаны простыми типами данных и общим конфигурационным модулем. Принятая архитектура одинаково поддерживает работу как через оконный интерфейс, так и в пакетном режиме из командной строки и не требует изменения исходного кода при переключении между CPU и GPU.
2. Разработан и реализован двухступенчатый алгоритм сопоставления. Грубый этап выполняет пакетный расчёт эмбеддингов для пятисекундных блоков и собирает матрицу косинусных сходств. Этап постобработки включает медианную фильтрацию аудиопозиций, проверку их монотонности с интерполяционной заменой выбросов и слияние смежных совпадений в непрерывные сегменты. На тестовой подвыборке из 50 пар «короткое видео — длинная аудиозапись» алгоритм корректно локализует совпадение в 92,0% случаев со средней абсолютной ошибкой начала корректно найденного сегмента 71 мс.
3. Эксплуатационные испытания, проведённые в трёх характерных средах, дали следующие показатели: полный проход одной пары занимает 9,2 с при наличии массовой видеокарты и 37,7 с на CPU обыкновенного ноутбука; верхний предел по оперативной памяти ограничен 2,5 ГБ, по видеопамяти — 3,4 ГБ. Такая комбинация скорости и скромного потребления ресурсов делает разработанный инструмент пригодным для тех ниш, в которых громоздкие исследовательские реализации SyncNet, Wav2Lip и им подобные просто не работают: для повседневной работы журналистов и видеомонтажёров на личных машинах, для архивных учреждений, для дешёвых виртуальных серверов общедоступных хостингов.
Дальнейшее развитие комплекса видится в нескольких направлениях. Во-первых, обработка кадров, в которых одновременно говорят несколько человек. Во-вторых, добавление онлайн-режима, позволяющего синхронизировать потоки по мере их поступления, — это важно для систем видеоконференций. В-третьих, подключение к популярным редакторам нелинейного видеомонтажа через плагины.
The additional file for this article can be found as follows:
Further description of analytic pipeline and patient demographic information. DOI: