Opus: открытый кодек, захвативший WebRTC

Опубликовано: 5 июня 2026 · Время чтения: 18 мин · Автор: Николай Сапунов, CEO Фора Софт

Кратко

Opus – это аудиокодек, который выполняет две задачи, ранее требующие двух разных кодеков: в нём объединены речевой движок SILK и музыкальный движок CELT, и он переключается между ними – или смешивает – кадр за кадром. Благодаря этому один и тот же кодек одинаково хорошо передаёт шёпот в телефонном разговоре и звучание стереоконцерта. Он масштабируется от 6 кбит/с узкополосной речи до 510 кбит/с прозрачной стереомузыки, с длительностью кадров от 2,5 миллисекунды – именно поэтому его поддерживают все браузеры и все стеки реального времени. Кодек описан открытым стандартом (IETF RFC 6716) и свободен от роялти под лицензией, схожей с BSD, так что, в отличие от AAC, платить патентному пулу не нужно. Если ваш продукт работает с живым звуком или видеозвонками, вы почти наверняка уже используете Opus в сети.

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

Если в вашем продукте есть кнопка «присоединиться к звонку» – видеосвязь, телемедицина, класс в e-learning, голосовой канал в игре – звук, уходящий с микрофонов ваших пользователей, на практике является Opus. Веб-стандарт, на котором работают звонки в браузере, WebRTC, обязывает каждый браузер поддерживать Opus, поэтому он стоит по умолчанию и выбора у вас почти нет. Эта статья написана для менеджера продукта, основателя или операционного руководителя без аудиоподготовки: к концу вы поймёте, почему Opus выиграл звук реального времени, что его ключевые настройки (FEC, DTX, битрейт, размер кадра) на самом деле делают со звонком и когда Opus – правильный выбор по сравнению с AAC. Каждое утверждение опирается на спецификацию IETF или на открытого сопровождающего кодека, а не на пересказ из вторых рук.

Сорокалетний раскол, который привёл к закрытию Opus

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

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

Opus была стандартизирована Internet Engineering Task Force – тем же органом, который стандартизирует протоколы самого интернета, – как RFC 6716 в сентябре 2012 года. Её авторы представляли Mozilla (создатель Firefox), Skype и Xiph.Org – некоммерческую организацию, стоящую за рядом открытых медиаформатов. Эта родословная важна по одной причине, к которой мы вернёмся в конце: Opus создавался как открытый и свободный формат, а не для лицензирования.

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

SILK, CELT и переключение между ними

Откройте Opus – внутри вы увидите два движка, прикреплённых к одному кадру.

Первый движок – SILK, пришедший из Skype, где уже обработал миллиарды минут голосовых звонков. SILK – это кодер с линейным предсказанием, что является техническим названием подхода, моделирующего работу речевого аппарата: он предсказывает каждый момент сигнала на основе предыдущих, как можно угадать следующую ноту в знакомой мелодии, и передаёт лишь небольшую ошибку предсказания. Такой подход отлично работает для речи и нижних частот любого звука и экономичен по расходу битов. SILK обрабатывает нижние частоты дискретизации Opus – вплоть до wideband.

Второй движок – CELT, разработанный в Xiph.Org. CELT – это трансформный кодер, основанный на модифицированном дискретном косинусном преобразовании (MDCT) – той же технологии частотного анализа, что и в AAC. Кодек спроектирован для минимальной задержки, что необычно для музыкальных кодеков, и способен обрабатывать весь слышимый диапазон частот и музыкальный звук.

Между ними расположен селектор режимов. Opus работает в одном из трёх режимов, выбираемых автоматически в зависимости от битрейта, полосы частот и содержания:

• Режим только SILK – чистый речевой движок, предназначенный для передачи голоса при низких битрейтах и в более узких частотных диапазонах.
• Режим только CELT – чистый музыкальный движок, оптимальный для воспроизведения музыки и настроек с минимальной задержкой.
• Гибридный режим – оба кодека работают одновременно: SILK кодирует нижние частоты, а CELT – верхние, накладывая их поверх. Благодаря этому Opus обеспечивает полнополосное звучание речи, естественное на слух, не требуя полной мощности музыкального кодека.

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

Числа, делающие Opus гибким

Репутация Opus основана на его универсальности. Почти всё объясняется тремя регуляторами.

Первый регулятор – битрейт, то есть сколько бит в секунду расходуется. Opus поддерживает диапазон от 6 до 510 kbit/s и может менять скорость в любой момент без перезапуска потока (RFC 7587, §3.1). Чтобы сделать этот диапазон наглядным, спецификация предлагает «оптимальные» битрейты – такие скорости, при которых каждый тип контента звучит хорошо по соотношению качества и объёма, при стандартной длительности кадра 20 миллисекунд:

Таблица 1. Рекомендованные битрейты Opus из RFC 7587, §3.1.1. «Fullband» означает, что кодек передаёт весь слышимый диапазон до 20 кГц; «narrowband» – телефонную речь до 4 кГц.

Второй регулятор – полоса звука, то есть какая часть частотного диапазона передаётся кодеком. Opus предлагает пять настроек: от narrowband (телефонная речь до 4 кГц) через wideband и super-wideband до fullband (весь слышимый диапазон до 20 кГц при частоте дискретизации 48 кГц). Кодек может сузить полосу, чтобы сэкономить биты при слабой сети, а затем снова расширить её при восстановлении пропускной способности – посреди звонка, без заметного разрыва.

Третий регулятор – размер кадра, то есть сколько звука попадает в каждый пакет. Opus может кодировать кадры длительностью 2,5, 5, 10, 20, 40 или 60 миллисекунд и упаковывать несколько кадров в один пакет до 120 мс (RFC 7587, §4.2). Этот параметр – ключ к тому, почему Opus так хорошо работает в реальном времени, поэтому ему стоит уделить особое внимание.

Короткий кадр означает, что кодер отправляет данные раньше, не дожидаясь полного заполнения пакета. Это время ожидания – чистая, неустранимая задержка, которая добавляется к каждому произнесённому слову. Сравним кадр музыкального кодека с кадром Opus в реальном времени:

Кадр AAC-LC = 1024 отсчёта ÷ 48 000 отсчётов в секунду ≈ 21,3 мс на кадр
Кадр Opus   = 20 мс (типичная настройка реального времени)
Минимум Opus = 2,5 мс (настройка наименьшей задержки)

Двадцать одна миллисекунда вынужденной задержки перед тем, как пакет покидает кодер, может показаться небольшой, но в двустороннем разговоре она складывается с сетевой задержкой, джиттер-буфером и декодером – и именно эта сумма определяет, будет ли звонок тормозить или звучать естественно. Способность Opus снижать размер кадра до 2,5 мс при сохранении хорошего качества – одна из главных причин, почему именно он, а не AAC, используется во всех приложениях для звонков. Полный анализ всей цепочки задержки – в статье WebRTC-конвейере звука целиком.

«Подводный камень – погоня за самым коротким кадром может стоить дороже, чем экономит. Более короткий кадр снижает задержку кодера, но увеличивает накладные расходы, потому что каждый пакет несёт одни и те же фиксированные сетевые заголовки (IP, UDP, RTP), независимо от объёма передаваемого звука. Уменьшите размер кадра вдвое – и число пакетов удвоится, как и «налог» на заголовки. На перегруженной сети эта повышенная частота пакетов может спровоцировать потерю данных – ту самую, которую вы пытались предотвратить. Стандартная настройка для работы в реальном времени – 20 мс – как раз и выбрана потому, что обеспечивает баланс между задержкой и накладными расходами. Переходите на более короткие кадры только тогда, когда точно измерили, что выигрыш в задержке оправдывает эти издержки.»

Две функции, спасающие плохой звонок: FEC и DTX

Две настройки Opus влияют на качество звонка сильнее, чем любой объём чистого битрейта, потому что они решают главные проблемы живого звука: потерю пакетов и неэффективное использование полосы пропускания.

Первая – внутриполосная упреждающая коррекция ошибок, или FEC (Forward Error Correction). В интернете звук передаётся потоком пакетов, и некоторые из них просто не доходят. Обычно потеря пакета означает разрыв – щелчок или пропущенный слог. FEC решает эту проблему хитростью: когда кодер предсказывает потерю пакета, он помещает низкокачественную копию предыдущего пакета внутрь текущего (RFC 7587, §3.3). Так, если пакет номер 5 потерян, пакет номер 6 приходит с резервной копией пакета 5, и декодер восстанавливает пропущенный фрагмент вместо пустоты. Цена – несколько дополнительных килобит; выигрыш – речь остаётся разборчивой даже при потере пакетов, которые иначе сделали бы её обрывистой. Всё семейство методов восстановления потерь мы подробно разбираем в статье об упреждающей коррекции ошибок, FEC и RED-избыточности, а о том, как плеер маскирует оставшиеся разрывы, – в сокрытии потери пакетов (PLC).

Вторая – прерывистая передача, или DTX (Discontinuous Transmission). Когда вы замолкаете, передавать больше нечего – но наивный кодек продолжает отправлять тишину на полной скорости. DTX обнаруживает паузу и прекращает передачу аудиопакетов, отправляя лишь редкие крошечные обновления, чтобы удалённая сторона знала: соединение активно (RFC 7587, §3.1.3). На типичном звонке, где каждый говорит меньше половины времени, DTX может существенно снизить средний битрейт. Opus также генерирует собственный комфортный шум – слабое, естественно звучащее шипение – во время пауз, потому что полная цифровая тишина воспринимается слушателем как тревожная и «мёртвая», будто связь оборвалась. Подробности работы механизма обнаружения речи и прерывистой передачи см. в определении голосовой активности и прерывистой передаче.

Короткий пример демонстрирует совокупный эффект на звонке двух человек:

Оба микрофона непрерывно по 32 kbit/s каждый = 64 kbit/s всего
Каждый реально говорит ~40 % времени
С DTX в среднем отправляется ≈ 0,40 × 64 ≈ 26 kbit/s
FEC добавляет несколько kbit/s на защиту активной речи от потерь
Итог: устойчивый звонок примерно за полосу одного непрерывного потока

«Подводный камень – включить FEC, который приёмник не может использовать, – значит просто тратить полосу. FEC помогает только тогда, когда декодирующая сторона знает, что нужно искать резервную копию в следующем пакете. Если FEC включён на стороне отправителя, но приёмник не настроен на его использование, избыточные данные всё равно отправляются и затем отбрасываются – это чистая трата ресурсов (RFC 7587, §3.3 рекомендует не использовать FEC, если приёмник не может им воспользоваться). FEC и DTX согласуются при установке звонка через параметры SDP (useinbandfec, usedtx); убедитесь, что обе стороны пришли к согласию, а не включайте их автоматически.»

Почему каждый браузер включает Opus

Opus стал универсальным не благодаря маркетингу, а потому что стандарт, на котором работают звонки в браузере, сделал его обязательным.

WebRTC – это технология, позволяющая веб-странице получить доступ к микрофону и камере и установить соединение без установки плагинов. Правила обработки звука зафиксированы в IETF RFC 7874 (май 2016) и сформулированы однозначно: каждый WebRTC-эндпойнт обязан поддерживать кодек Opus, а также устаревший телефонный кодек G.711 для совместимости с традиционными телефонными системами. Если устройство способно обеспечить качество выше телефонного – а это почти всегда так, – спецификация рекомендует отдавать приоритет Opus. Практический результат: Chrome, Firefox, Safari и Edge по умолчанию кодируют звук с микрофона в формате Opus. Safari был последним из крупных браузеров, который внедрил эту поддержку – это произошло в 2021 году; к 2026 году все основные браузеры используют Opus как для отправки, так и для приёма аудио.

Поскольку браузеры выбрали Opus, на нём сошлось и серверное ПО, маршрутизирующее звонки между ними – mediasoup, Pion, LiveKit, Janus и другие. Кодек, гарантированно присутствующий на каждом эндпоинте, – это кодек, который никогда не нужно транскодировать, а транскодирование звука в середине звонка требует ресурсов CPU и добавляет задержку. То, что Opus везде, – это не просто удобно; это устраняет целый класс задач из системы реального времени. Как эти серверы маршрутизируют звук без перекодирования, – тема статьи звук в SFU, MCU и P2P.

Opus выходит за пределы реального времени. Он поддерживается в нескольких контейнерах – Ogg (описан в RFC 7845), WebM и Matroska, MP4/ISOBMFF и MPEG-TS, – поэтому используется и в стриминге по запросу через HLS и DASH, и в аудиоконтейнерах в целом. Исторически его слабым местом были аппаратные плееры и вещательные цепочки, которые ещё до появления Opus стандартизировались на AAC и Dolby – именно там AAC по-прежнему остаётся лидером.

Opus против AAC: выбор с ясным правилом

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

Таблица 2. Opus и AAC по ключевым параметрам проекта. «Кадр / задержка» – минимальная задержка кодека до отправки пакета, именно это значение важно для живого разговора.

Правило, вытекающее из таблицы: если звук – это живой двусторонний разговор, выбирайте Opus; если это одностороннее воспроизведение на широком парке устройств и телевизоров, отдавайте предпочтение AAC. Телемедицинский звонок использует Opus. Фильм, передаваемый на smart-TV, использует AAC. Продукт, совмещающий оба сценария – платформа e-learning с живыми занятиями и библиотекой записанных лекций, – разумно применяет Opus для живой части и AAC для материалов по запросу. Такой подход – распространённый и правильный шаблон, а не признак неспособности стандартизироваться.

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

Что добавил Opus 1.5: машинное обучение внутри кодека

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

Обновление 2017 года RFC 8251 стало своего рода наведением порядка: оно устранило две выявленные при фаззинге уязвимости в декодере и исправило мелкие баги качества, при этом полностью сохранив совместимость с исходным RFC 6716. Любой декодер, прошедший первоначальные тесты, продолжает работать.

Бóльший скачок произошёл с выходом Opus 1.5 от Xiph.Org в марте 2024 года – впервые машинное обучение было интегрировано внутрь самого кодека. Выделяются две ключевые функции. Deep PLC использует нейросеть для восстановления потерянных пакетов звука, создавая результат, который звучит значительно естественнее, чем старый метод «повтори и затухни». Deep Redundancy (DRED) существенно расширяет возможности FEC, позволяя декодеру восстанавливать речь даже при длительных всплесках потерь, которые обычно делали бы звонок неработоспособным. Эти технологии работают на стороне декодера, поэтому сервис может внедрить их на стороне воспроизведения и повысить устойчивость звонков для пользователей с плохим соединением. На 2026 год формат DRED всё ещё находится в разработке, так что стоит воспринимать его как экспериментальный, а не устоявшийся, но направление ясно: восстановление потерь, описанное в статье в классических терминах, теперь перестраивается на основе нейросетей, и Opus ведёт эту работу открыто.

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

Мы встраиваем звук в реальном времени в видеопродукты с 2005 года – видеосвязь, телемедицинские консультации, e-learning-курсы и AR/VR-опыт – и Opus лежит почти во всём этом, потому что WebRTC использует его по умолчанию, а он свободен для применения. В продакшене повторяющийся урок не про выбор Opus, а про его настройку: задать разумный кадр в 20 мс, включить FEC и DTX на обоих концах и позволить битрейту подстраиваться под сеть, а не фиксировать его на определённом значении. Когда клиенту нужна и библиотека по запросу рядом с живыми сессиями, мы комбинируем Opus для звонков с AAC для записей – тот же подход, что и рекомендует эта статья. Сбои, с которыми нас просят помочь, редко связаны с «не тем кодеком» и обычно – с «Opus с неправильными настройками»: FEC отключён в условиях потерь пакетов или размер кадра выбран без учёта накладных расходов.

Главное

• Opus – это единый кодек, сочетающий речевой движок (SILK) и музыкальный (CELT), которые автоматически переключаются в зависимости от сигнала.
• Он поддерживает битрейт от 6 до 510 кбит/с и длительность кадров от 2,5 до 60 мс, обеспечивая качественную передачу как голоса, так и музыки.
• Благодаря коротким кадрам и низкой задержке Opus, а не AAC, стал стандартом для звука в реальном времени.
• FEC восстанавливает потерянные пакеты, а DTX отключает передачу в периоды тишины – оба механизма следует включать на обоих концах соединения.
• WebRTC требует использование Opus, поэтому он включён по умолчанию в каждом современном браузере.
• Opus лицензирован по BSD и не требует роялти; в отличие от него, AAC облагается поштучными отчислениями патентному пулу.

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

• Как работает сжатие звука: четыре идеи за каждым современным кодеком
• WebRTC-конвейер звука целиком
• Семейство AAC: AAC-LC, HE-AAC v1, HE-AAC v2, xHE-AAC