Что значит «в синхроне»: 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

Когда вещательному инженеру нужно разрешить спор о синхронизации звука и изображения, он обращается к одному документу: 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). Если проиграть звук «ба», одновременно показывая лицо, артикулирующее «га», большинство людей слышат не «ба» и не «га» – они слышат «да», то есть смешанное восприятие, которое мозг создаёт, чтобы примирить противоречащие друг другу сигналы от разных органов чувств. Эта иллюзия возникает автоматически и сохраняется даже тогда, когда человек знает, в чём подвох.

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

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

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

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 для цифрового телевидения. Он устанавливает, что на входе кодировщика цифрового телевидения звук не должен опережать видео более чем на 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 кадрах в секунду один кадр длится около 41,67 мс; правило «один вперёд, три назад» соответствует рекомендациям BT.1359 в кадрах.
• Цельтесь в опоздание – в самую широкую часть окна допуска, но никогда не допускайте опережения звука.

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

• PTS, DTS и временные метки элементарного потока
• Временные метки RTP, отчёты RTCP о передатчике и синхронизация по NTP
• Методика тестирования lip-sync: хлопушки, время прохождения сигнала, перцептивные проверки