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

Опубликовано: 2026-06-05 · Время чтения: 18 мин · Автор: Nikolay Sapunov, CEO в Фора Софт

Кратко

Opus – это один аудиокодек, который делает две работы, прежде требовавшие двух кодеков: у него есть речевой движок SILK и музыкальный движок CELT, и он переключается между ними – или смешивает их – кадр за кадром, поэтому один и тот же кодек хорошо звучит и на шёпоте в телефонном разговоре, и на стереоконцерте. Он масштабируется от 6 kbit/s узкополосного голоса до 510 kbit/s прозрачной стереомузыки, с кадрами длиной от 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. CELT спроектирован для очень малой задержки, что необычно для кодека музыкального типа, и обрабатывает весь слышимый диапазон частот и музыкальный звук.

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

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

Читателю не нужно отслеживать, какой режим активен в каждый момент; кодер решает, а декодер следует, и всё это сигнализируется внутри потока. Важен результат: один кодек, которому никогда не нужно извиняться за тип звука, который ему дали.

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

Репутация Opus держится на его диапазоне. Три регулятора объясняют почти всё.

Первый регулятор – битрейт, то есть сколько бит в секунду вы тратите. Opus поддерживает 6 kbit/s на нижнем конце и до 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, и в аудиоконтейнерах в целом. Его историческим слабым местом были аппаратные плееры и вещательные цепочки, стандартизировавшиеся на AAC и Dolby за годы до появления Opus, – и именно там 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 kbit/s и от кадров 2,5 до 60 мс, покрывая голос и музыку.
• Короткие кадры и малая задержка – причина, почему Opus, а не AAC, владеет звуком реального времени.
• FEC восстанавливает потерянные пакеты; DTX перестаёт слать в тишине – включайте оба на обоих концах.
• WebRTC требует Opus, поэтому каждый современный браузер несёт его по умолчанию.
• Opus royalty-free под лицензией BSD; AAC несёт поштучные роялти патентного пула.

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

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