Что значит «в синхроне»: ITU-R BT.1359, окна lip-sync, заметность

Коротко

Звук и изображение почти никогда не доходят до ваших глаз и ушей в один и тот же момент – и это нормально, потому что человеческое восприятие работает не с одной «правильной» точкой, а с целым окном допуска. Главный вещательный стандарт, ITU-R BT.1359-1, говорит: зритель начинает замечать рассинхрон, когда звук опережает картинку примерно на 45 миллисекунд или отстаёт от неё примерно на 125 миллисекунд, а неприемлемым он становится за пределами примерно +90 / −185 миллисекунд. Окно несимметрично намеренно: опоздавший звук мы прощаем гораздо охотнее, чем звук, пришедший раньше, потому что в реальном мире звук всегда доходит до нас позже света. Эта статья объясняет, откуда взялись эти числа, почему окно асимметрично и как превратить вещательные цифры в бюджет, под который реально проектировать систему.

Почему это важно

Рассинхрон губ – это дефект, который зритель замечает быстрее всего и о котором жалуется громче всего: быстрее, чем о мягкой картинке, быстрее, чем о тихом миксе. Если вы делаете сервис видеоконференций, стриминговую платформу, OTT-приложение или телемедицину, тикет «звук не совпадает» вы получите обязательно, и первое, что должны выяснить ваши инженеры, – действительно ли смещение вышло за окно допуска, или это просто чувствует один особо чувствительный пользователь. Без стандартных чисел этот спор не заканчивается никогда. Эта статья даёт продакт-менеджеру, QA-лиду и инженеру один общий словарь и одну общую таблицу, чтобы разговор стал «мы отстаём на 70 мс – это внутри порога заметности BT.1359, но за пределами постадийного лимита EBU R37», а не «мне кажется, что сломано». Знание окна также подсказывает, куда тратить силы: совершенство не нужно – нужно удержаться внутри полосы, которая шире, чем думает большинство.

То, в чём никто не признаётся: идеального синхрона не существует

Начнём с факта, который удивляет почти всех. Когда вы смотрите на говорящего человека через комнату, звук его голоса доходит до вас позже, чем вы видите движение губ. Свет распространяется со скоростью около 300 миллионов метров в секунду; звук в воздухе – около 343 метров в секунду. На дистанции в 10 метров свет приходит примерно за 33 наносекунды – фактически мгновенно, – а звуку нужно около 29 миллисекунд, чтобы пройти ту же дистанцию. То есть в обычной жизни звук всегда чуть-чуть опаздывает, и ваш мозг всю жизнь учился тому, что это норма.

Один этот факт объясняет почти всё в допусках lip-sync. Мозг не измеряет, совпадают ли звук и картинка с точностью до микросекунды. Он задаёт более мягкий вопрос: попадает ли эта пара в диапазон отношений между видом и звуком, который я научился ожидать? Поскольку опоздавший звук – естественный случай, мозг терпит много опоздания и очень мало опережения. Звук, пришедший раньше картинки, в природе не встречается, поэтому на экране он ощущается неправильным гораздо раньше.

Технически узкий диапазон временных рассогласований, который зритель принимает, называется окном допуска синхронизации, или коротко окном lip-sync. Задача каждого стандарта в этой статье – поставить на это окно числа. Задача каждого инженера – удержать доставленное смещение внутри него.

Одно замечание о терминах, прежде чем двигаться дальше, потому что половина всей путаницы с lip-sync – это словарь. По всей статье положительное число означает, что звук опережает картинку (audio leads video – неестественный, быстрее замечаемый случай). Отрицательное число означает, что звук отстаёт от картинки (audio lags video – естественный, лучше переносимый случай). Это знаковое соглашение из ITU-R BT.1359, и мы держимся его везде ниже. Где число может быть неоднозначным, мы дополнительно проговариваем его словами.

Нажмите, чтобы увеличить

Числа, которые все гуглят: ITU-R BT.1359-1

Когда вещательному инженеру нужно закрыть спор о lip-sync, он берёт один документ: ITU-R BT.1359-1, «Relative timing of sound and vision for broadcasting», утверждённый в ноябре 1998 года и действующий в 2026-м. Он короткий, бесплатно скачивается с сайта ITU и делает одну ценную вещь: переводит десятилетия исследований восприятия в две пары чисел.

Рекомендация определяет два порога, каждый – как окно с правым краем (звук опережает) и левым краем (звук отстаёт).

Порог заметности – это точка, в которой средний зритель начинает замечать, что что-то не так, даже если не может сказать, что именно. BT.1359-1 ставит его на +45 миллисекунд (звук опережает картинку) и −125 миллисекунд (звук отстаёт от картинки). Внутри этого окна подавляющее большинство зрителей воспринимает звук и видео как синхронные. Это ваша целевая полоса: если вы внутри +45 / −125, вы, по сути, выиграли.

Порог приемлемости – более широкая точка, за которой рассогласование не просто заметно, но и раздражает: зритель уже отвлекается, и впечатление ухудшается. BT.1359-1 ставит его на +90 миллисекунд (звук опережает) и −185 миллисекунд (звук отстаёт). Между заметностью и приемлемостью – серая зона: чувствительные зрители замечают, но большинство потерпит это на протяжении программы.

Перечитайте эти два окна – и асимметрия бросается в глаза. На стороне «звук отстаёт» у вас 125 миллисекунд запаса до обнаружения и 185 до того, как станет раздражать. На стороне «звук опережает» – всего 45 и 90. Левая половина окна примерно в 2,7 раза шире правой. Это не случайность и не артефакт округления; это тот самый факт об акустике комнаты из предыдущего раздела, измеренный и записанный в стандарт. Опоздавший звук естественен, поэтому мы терпим его почти втрое больше.

Вот окно BT.1359-1 в виде единой таблицы – той, которую открытый интернет почему-то нигде не выкладывает аккуратно в одном месте.

Таблица 1. Пороги lip-sync по ITU-R BT.1359-1 (11/98). Положительное = звук опережает картинку; отрицательное = звук отстаёт.

Один момент дисциплины стоит проговорить прямо, потому что это самая частая ошибка в сети. Многие статьи приводят одно симметричное число – «lip-sync должен быть в пределах ±40 мс» или «в пределах одного кадра», – будто окно центрировано на нуле. Это не так. Окно BT.1359-1 асимметрично, и сведение его к одной симметричной цифре выбрасывает самое полезное, что стандарт сообщает: у вас гораздо больше запаса на опоздавший звук, чем на опережающий. Когда вы проектируете буфер или коррекцию задержки, именно эта асимметрия – тот люфт, который вы хотите использовать.

Откуда взялись числа: восприятие, а не инженерия

Пороги BT.1359-1 родились не в комитете по стандартам. Они родились в лабораториях восприятия, на десятилетия раньше, и самое цитируемое отдельное исследование – Dixon and Spitz (1980), «The Detection of Auditory Visual Desynchrony».

Их метод изящен, и его стоит представить. Участникам показывали непрерывное видео – либо говорящего человека, либо молоток, бьющий по колышку, – которое начиналось идеально синхронно, а затем медленно расходилось с постоянной скоростью около 51 миллисекунды смещения на секунду видео. Участники нажимали кнопку в момент, когда впервые замечали, что звук и картинка разошлись. Медленный дрейф, а не мгновенный скачок к фиксированному смещению, имитирует то, как реальные вещательные и стриминговые системы действительно ломаются: синхрон редко рвётся сразу – он ползёт.

Результаты прямо ложатся на асимметрию BT.1359. Для говорящего лица зрители терпели отставание звука примерно на 258 миллисекунд до обнаружения, но только опережение примерно на 131 миллисекунду. Для молотка – резкого ударного события с чётким визуальным моментом – пороги ужесточались примерно до 188 миллисекунд отставания и всего 75 миллисекунд опережения. Отсюда два вывода. Первый: в обоих случаях опоздавший звук переносится гораздо лучше, чем опережающий, что подтверждает историю про естественную акустику. Второй: тип контента имеет значение – резкий транзиент (удар молотка, бой барабана, хлопушка) мозг контролирует куда строже, чем мягкую размытую артикуляцию непрерывной речи.

BT.1359 идёт осторожным путём. Вместо щедрых порогов, которые дают непрерывная речь, он задаёт более жёсткие, не зависящие от контента числа, которые держатся даже для требовательных транзиентов. Поэтому стандартные +45 / −125 строже, чем речевые +131 / −258 у Dixon и Spitz: вещательный стандарт должен защищать худший случай, а не средний.

Есть и более глубокая причина, почему мозг так вкладывается в тайминг губ, и у неё есть имя: эффект Мак-Гурка (McGurk and MacDonald, 1976). Если проиграть звук «ба», показывая лицо, артикулирующее «га», большинство людей слышат ни то, ни другое – они слышат «да», слияние, которое мозг придумывает, чтобы примирить конфликтующие органы чувств. Иллюзия непроизвольна; она сохраняется, даже когда вы знаете подвох. Вывод для нас: мозг не считает движение губ украшением поверх речи. Он использует губы как первичное свидетельство о том, что говорится, сплавляя зрение и слух ниже уровня сознания. Когда они расходятся, вы замечаете не косметический сбой – вы ломаете механизм восприятия, который мозг запускает постоянно, чтобы понимать речь. Поэтому ошибки lip-sync ощущаются настолько неправильными, и поэтому именно о них зрители сообщают в первую очередь.

Нажмите, чтобы увеличить

Другие стандарты, с которыми вы встретитесь

BT.1359 – перцептивный якорь, но это рекомендация со стороны зрителя: она описывает то, что аудитория способна вытерпеть в конце цепочки. В продакшене вы встретите ещё два документа, которые строже, потому что они управляют точками выше по потоку, где у ошибок ещё есть запас, чтобы накопиться.

EBU R37, «The relative timing of the sound and vision components of a television signal», – продакшен-правило европейских вещателей. Оно делает две вещи, которых BT.1359 не делает. Во-первых, задаёт жёсткий постадийный бюджет: на любом отдельном устройстве в цепочке звук должен оставаться в пределах +5 миллисекунд (опережение) и −15 миллисекунд (отставание) относительно видео. Во-вторых, задаёт общий лимит на выходе, питающем передатчик: +40 миллисекунд (опережение) и −60 миллисекунд (отставание). Логика – это управляемый бюджет: если каждая стадия укладывается в свой маленький допуск, ошибки суммируются в то, что зритель не заметит. Постадийные числа – не перцептивные пороги (никто не чувствует 5 миллисекунд), а лимиты накопления ошибки, спроектированные так, чтобы десятистадийная цепочка всё ещё уверенно попадала в окно BT.1359.

ATSC IS-191 – североамериканский аналог, заключение Implementation Subcommittee для цифрового ТВ. Оно указывает, что на входе DTV-кодировщика звук никогда не должен опережать видео больше чем на 15 миллисекунд и отставать больше чем на 45 миллисекунд. Как и EBU R37, оно намеренно строже зрительского порога и контролирует именно вход кодировщика – точку, после которой любая ошибка запекается в вещательный поток и больше не правится дёшево.

Заметьте закономерность во всех трёх. Рекомендация со стороны зрителя (BT.1359) – самая свободная, потому что описывает финальный перцептивный бюджет. Продакшен-правила (EBU R37, ATSC IS-191) – строже, потому что управляют промежуточными точками, у которых ещё есть стадии впереди. Это та же логика, что и в финансовом бюджете: чем ближе вы к началу цепочки, тем меньшую долю общего допуска вам разрешено потратить, чтобы хватило всем после вас.

Таблица 2. Три стандарта рядом. Все используют знаковое соглашение BT.1359: положительное = звук опережает картинку. Продакшен-правила строже зрительского восприятия, потому что управляют точками выше по потоку.

Перевод окон в кадры: единица, которой реально пользуется ваша видеокоманда

Аудиоинженеры думают в миллисекундах; видеоинженеры – в кадрах. Чтобы говорить с обоими, нужен перевод, и это одно деление.

Длительность кадра – единица, делённая на частоту кадров. Подставим распространённые частоты:

длительность кадра = 1 ÷ частота кадров

24 fps  →  1 ÷ 24  = 0,04167 с  =  41,67 мс на кадр
25 fps  →  1 ÷ 25  = 0,04000 с  =  40,00 мс на кадр
30 fps  →  1 ÷ 30  = 0,03333 с  =  33,33 мс на кадр

Теперь окно заметности BT.1359 становится наглядным в кадрах. Край «звук отстаёт» на −125 миллисекунд – это около трёх кадров при 24 fps (125 ÷ 41,67 ≈ 3,0) и около 3,75 кадра при 30 fps (125 ÷ 33,33 ≈ 3,75). Край «звук опережает» на +45 миллисекунд – едва один кадр при 24 fps (45 ÷ 41,67 ≈ 1,08). Так что старое вещательное правило большого пальца – «держи в пределах одного кадра вперёд, трёх кадров назад» – это просто BT.1359, переведённый в счёт кадров на киношных и вещательных частотах. Оно верно, и теперь вы точно знаете, откуда оно.

Здесь же прячется частая ошибка. Команда скажет «мы в пределах одного кадра, значит всё ок», имея в виду один кадр в любую сторону. Но один кадр вперёд при 24 fps (около 42 мс) – это прямо на краю заметности, тогда как один кадр назад (тоже около 42 мс) – комфортно внутри окна. Симметричное правило «один кадр» слишком щедро на стороне опережения и слишком строго на стороне отставания. Окно асимметрично; ваша проверка допуска тоже должна быть такой.

Разобранный пример: бюджет синхрона в реальном конвейере

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

Пусть живое событие проходит через пять стадий, и на каждой аудио- и видеопути имеют чуть разные задержки:

Стадия 1  Захват камеры + микрофона        звук  −8 мс  (путь микрофона чуть медленнее)
Стадия 2  Кодирование аудио + видео        звук  −12 мс (аудиокодер буферизует больше)
Стадия 3  Упаковка в сегменты              звук  +5 мс  (видеосегментер добавляет задержку)
Стадия 4  CDN + сетевой транспорт          звук   0 мс  (оба едут в одних пакетах)
Стадия 5  Декод + рендер в плеере          звук  −10 мс (декод видео тяжелее)

Итоговое накопленное смещение = (−8) + (−12) + (+5) + (0) + (−10) = −25 мс

Звук в итоге отстаёт от видео на 25 миллисекунд. Сверим с таблицей: −25 миллисекунд – глубоко внутри порога заметности BT.1359 (−125), внутри общего лимита EBU R37 (−60) и внутри лимита кодировщика ATSC IS-191 (−45). Этот конвейер можно отгружать. Коррекция не нужна.

Теперь поменяем одно число. Пусть аудиокодер на стадии 2 застопорился под нагрузкой и добавил −90 миллисекунд вместо −12. Сумма становится −8 − 90 + 5 + 0 − 10 = −103 миллисекунды. Это всё ещё внутри заметности BT.1359 (−125) – большинство зрителей не заметит, – но это вылетело за общий лимит EBU R37 (−60) и за ATSC IS-191 (−45). Вещатель это отклонит; стриминговый сервис может отгрузить и поставить на то, что зрители останутся ниже порога обнаружения. Это реальное решение, с которым сталкиваются команды, и таблица – то, что превращает его в решение, а не в догадку.

«Частая ошибка: погоня за нулём. Инженеры, новые в синхроне, часто пытаются загнать смещение ровно в 0 мс и тратят на это огромные силы. Они оптимизируют точку, которой перцептивно не существует и которую природа никогда не даёт. Правильная цель – попасть внутрь окна, в идеале чуть на позднюю сторону, где окно шире всего, и никогда – на раннюю. Доставленное смещение −30 мс (звук чуть отстаёт) – лучшая инженерная цель, чем хрупкая дорогая попытка достичь 0 мс, потому что оно сидит в самой глубокой части чаши допуска и деградирует мягко, если следующая стадия добавит ещё немного отставания.»

Почему стриминг и реалтайм ломают синхрон по-разному

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

В адаптивном стриминге – HLS, DASH, CMAF – аудио и видео обычно отдельные дорожки, нарезанные на сегменты и собираемые плеером по таймстемпам. Синхрон полностью зависит от того, верны ли эти таймстемпы и правильно ли плеер их выравнивает. Классический отказ – это вставка рекламы: основная программа и реклама закодированы разными системами с разными допущениями о тайминге, и точка склейки вносит смещение, которое плеер не может исправить. Поэтому поток, идеально синхронный во время передачи, дрейфует на ролике. Подробная механика таймстемпов – в нашей статье-компаньоне PTS, DTS и таймстемп элементарного потока, а стриминг-специфичные отказы – в lip-sync в HLS и DASH: где он чаще всего ломается.

В реалтайм-коммуникациях – видеозвонки WebRTC – аудио и видео идут как независимые RTP-потоки, у каждого свои часы, и приёмник должен выровнять их по тайминговой информации из RTCP sender reports. Только что присоединившийся участник может быть кратко рассинхронизирован в первую секунду звонка, пока приёмник не накопит достаточно тайминговых данных, чтобы сцепить два потока вместе. Это разбираем в RTP-таймстемпы, RTCP sender reports и синхронизация по NTP и в SFU-специфике в lip-sync в WebRTC.

Перцептивное окно одинаково во всех трёх мирах – мозгу зрителя всё равно, откуда пришло смещение: из вещательной цепочки, из склейки рекламы или из рассогласования RTP. BT.1359 +45 / −125 – универсальная линейка. Меняется как ломается синхрон и куда идти его чинить. Окно говорит, есть ли у вас проблема; статьи по конкретной доставке говорят, почему и как.

Где здесь Фора Софт

Мы поставляем критичный к lip-sync звук в видеоконференциях, телемедицине, e-learning, OTT и прямых трансляциях с 2005 года, и в каждой из этих вертикалей синхрон – дефект, который пользователь замечает первым. В реалтайм-продуктах трудность – выровнять независимые аудио- и видеопотоки RTP при переменном сетевом джиттере; в стриминговых – удержать отдельные аудио- и видеорендиции выровненными через границы сегментов и вставки рекламы. Стандарты из этой статьи – линейка, по которой мы меряем во время QA, а асимметричное окно – тот люфт, вокруг которого мы проектируем буферы, смещаясь к слегка опоздавшему звуку, где восприятие наиболее снисходительно, а не гоняясь за нулём, которого нет. Когда клиент сообщает о проблеме со звуком, первое, что мы устанавливаем, – вышло ли измеренное смещение за окно BT.1359 или это просто чувствует один особо чувствительный рецензент, потому что именно это различие решает, есть ли вообще баг, который надо чинить.

Главное

• Идеального синхрона нет; восприятие принимает окно допуска, а не точку.
• ITU-R BT.1359-1: заметно за +45 мс (звук опережает) или −125 мс (отстаёт).
• Окно асимметрично – опоздавший звук терпят примерно в 2,7 раза больше.
• Продакшен-правила (EBU R37, ATSC IS-191) строже, чтобы контролировать накопление.
• При 24 fps один кадр ≈ 41,67 мс; «один вперёд, три назад» – это BT.1359 в кадрах.
• Цельтесь чуть в опоздание, в самую широкую часть окна – никогда в опережение.

Что почитать дальше

• PTS, DTS и таймстемп элементарного потока
• RTP-таймстемпы, RTCP sender reports и синхронизация по NTP
• Методика тестирования lip-sync: хлопушки, time-of-flight, перцептивные проверки