Кодек, контейнер, протокол и профиль: слова, которые постоянно путают

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

Последняя сверка: 2026-05-20 со стандартами: ISO/IEC 14496-10:2022 (H.264/AVC), ITU-T H.265 v9 (2023), AV1 Bitstream & Decoding Process Specification v1.0.0 с erratа 2024, ISO/IEC 14496-14:2020 (MP4), ISO/IEC 14496-12:2022 (ISOBMFF), ISO/IEC 13818-1:2023 (MPEG-2 Transport Stream), ISO/IEC 23000-19:2024 (CMAF), ISO/IEC 23009-1:2022 (DASH), RFC 8216 (HLS, август 2017), RFC 9725 (WHIP, март 2025), Apple HLS Authoring Specification ревизия 2025-09.

TL;DR

Кодек – это алгоритм, сжимающий сырое видео до короткого потока бит; контейнер – это файл или коробка, которая собирает этот сжатый поток вместе со звуком, субтитрами и временной разметкой; протокол – это система доставки, переносящая байты контейнера от сервера к плееру через сеть; профиль – это поименованный поднабор правил внутри одного из других трёх слоёв, который ограничивает, что энкодер, упаковщик или плеер вправе использовать. Четыре слова называют четыре разных слоя стримингового стека, и на каждом слое вы делаете независимый выбор – поэтому один видеофайл может быть H.265 в фрагментированном MP4, доставленным по LL-HLS с использованием профиля CMAF. Почти каждая продуктовая ошибка в этой части стека – несовместимое воспроизведение на iOS, манифесты, которые не играют на Roku, вставка рекламы, которая дропает не тот кадр – приходит из путаницы четырёх слоёв и попытки считать один выбор определяющим остальные. После этой статьи вы сможете читать любой спек-лист стриминга, диалог энкодера или вакансию и сразу понимать, на каком слое живёт каждое слово.

Зачем это понимать

Терминология «кодек, контейнер, протокол, профиль» – главный источник путаницы для всех, кто учит стриминг, и она остаётся непрозрачной годами, потому что вендоры, блог-посты и даже некоторые стандарты используют эти слова взаимозаменяемо. Продукт-менеджер, не отличающий кодек от контейнера, выберет неправильный дефолт в диалоге энкодера, выпустит поток, который не играет на половине устройств, и не поймёт, почему команда инженеров каждый раз спрашивает «какой профиль поддерживает плеер». Неаккуратность здесь не безобидна: она ведёт к выкинутым деньгам на CDN, к сломанному воспроизведению на Apple, к ad-tech-интеграциям, которые тихо падают на границе SCTE-35, и к контрактам, обещающим «стриминг 4K HDR» без указания, какая комбинация кодека, контейнера и профиля это реально потащит. Статья даёт вам ментальную модель из четырёх слоёв, чтобы когда инженер говорит «мы кодируем H.264 high profile, упаковываем в fMP4 и доставляем через LL-HLS», вы сразу видели четыре независимых решения, которые описывает эта фраза, понимали, какие из них контролируете, и задавали правильные уточняющие вопросы.

Четыре слоя – по одному предложению на каждый

До любых деталей – четыре определения по одному предложению. Запомните их, и большинство стриминговых разговоров становится читаемыми.

Кодек – это алгоритм, который берёт сырые видеокадры и ужимает их до сильно меньшего потока бит, а потом на другом конце восстанавливает обратно в кадры. Слово – сокращение от coder–decoder, и кодек – это слой, который делает саму математику сжатия. H.264, H.265, AV1, VP9 и H.266 – кодеки. На аудио-стороне это MP3, AAC, Opus и FLAC.

Контейнер – это файловый формат, упаковывающий один или несколько сжатых потоков (обычно видео и аудио, часто плюс субтитры и метаданные) в один свёрток, знающий, как его части стыкуются во времени. Контейнер ничего не сжимает. Он несёт то, что произвёл кодек, плюс тайминги, sample table и метаданные, по которым плеер находит нужный кадр в нужный момент. MP4, fragmented MP4 (fMP4), MPEG-2 Transport Stream (MPEG-TS), Matroska/MKV, WebM и Ogg – контейнеры.

Протокол – это набор правил, по которым байты контейнера перемещаются от сервера, энкодера или пира к плееру, ингест-серверу или другому пиру через сеть. Протокол решает, как байты режутся на куски, адресуются, запрашиваются, темпируются, ретрансмитятся и аутентифицируются на проводе. HLS, MPEG-DASH, RTMP, SRT, WHIP, WHEP, WebRTC, RTSP, RIST и Media over QUIC – протоколы.

Профиль – это поименованный поднабор правил, определённый кодеком, контейнером или протоколом, который ограничивает, что энкодер, упаковщик или плеер вправе использовать из этого слоя. Профиль – это контракт: «если придерживаться этого поднабора, любой совместимый декодер сыграет ваш поток». H.264 Baseline, Main и High – профили кодека. CMAF – профиль контейнера на базе ISO Base Media File Format. Профили DASH Live и On-Demand – профили протокола MPEG-DASH. Слово «профиль» используется на каждом слое и каждый раз означает разное.

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

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

Слой 1 – кодеки: тут происходит сжатие

Кодек – единственный слой, который касается реальных пикселей. Всё, что выше кодека, работает с битами, которые он произвёл, а не с сырым видео.

Представьте сырое видео как стопку фотографий, снятых 30 или 60 раз в секунду. На 1080p, 30 fps, 8-битного цвета каждая фотография – это примерно 1080 × 1920 × 3 байта ≈ 6,2 МБ. Тридцать таких в секунду – около 186 МБ/с, почти 1,5 Гбит/с. Никто это не хранит, не перевозит и не стримит. Единственная задача кодека – превратить 1,5 Гбит/с в нечто терпимое (обычно 1–10 Мбит/с для 1080p) так, чтобы зритель потерь не заметил.

Арифметика сокращения впечатляющая. Кодек достигает её, эксплуатируя четыре вида избыточности: пиксели рядом внутри кадра похожи (пространственная избыточность), пиксели в следующем кадре почти идентичны соседним (временная избыточность), человеческое зрение чувствительнее к яркости, чем к цвету (психовизуальная избыточность), а статистика получаемых символов хорошо пакуется энтропийным кодированием. Все современные кодеки – H.264 от 2003, H.265 от 2013, AV1 от 2018, H.266 от 2020 – используют вариации на эти четыре идеи. Полный механизм мы разбираем в разделе Video Encoding; здесь остаёмся на стороне стриминга.

То, что производит кодек, называется элементарным потоком (elementary stream): длинная последовательность сжатых бит без таймингов, без аудио, без метаданных. Элементарный поток H.264 – это просто NAL-юниты подряд. Сыграть элементарный поток напрямую нельзя – в нём ничего не говорит плееру, когда показывать каждый кадр и какое аудио к какому видео относится. Это работа контейнера, слоем выше.

Кодеки, которые имеют значение для стриминга в 2026:

• H.264 (AVC), ISO/IEC 14496-10, финализирован в 2003 и до сих пор обновляется. Универсально поддерживается всеми устройствами примерно с 2010. Дефолтный кодек для стриминга, если нет причины брать что-то новее. Лицензионный через MPEG-LA, но патенты на самые ходовые фичи начали истекать с 2025.
• H.265 (HEVC), ITU-T H.265 / ISO/IEC 23008-2, финализирован в 2013. Примерно на 30–50% меньше файлы при том же визуальном качестве, что у H.264. Универсальная аппаратная поддержка на телефонах и ТВ с 2017, но клубок патентных пулов (MPEG-LA, HEVC Advance, Velos Media и десятки независимых правообладателей) сделал кодек непопулярным для бесплатного веб-стриминга. Safari играет нативно; Chrome добавил только в 2023.
• VP9, RFC 6386 (формат фрейминга) плюс спека битстрима Google, финализирован в 2013. Royalty-free, использовался YouTube как основной 4K-кодек с 2014, пока его не вытеснил AV1. Поддерживается в Chrome, Firefox, Edge, Android – не по умолчанию в Safari.
• AV1, AV1 Bitstream and Decoding Process Specification, финализирован Alliance for Open Media в 2018. Royalty-free, на 20–40% эффективнее HEVC, нативная поддержка в Chrome / Firefox / Edge / Safari (с iOS 17), аппаратное декодирование практически на всех ТВ и телефонах, отгруженных с 2024. Netflix tech blog в 2024 сообщал, что AV1 несёт примерно 30% их stream-hours глобально; в 2026 доля выше. Дефолтный выбор для новых деплоев, если не нужно legacy.
• H.266 (VVC), ITU-T H.266 / ISO/IEC 23090-3, финализирован в 2020. Ещё на 30–40% эффективнее HEVC. Лицензирование в 2026 спорное, аппаратных декодеров мало, внедрение в основном в бродкаст-пилотах. Стоит отслеживать; разворачивать пока рано.

Аудиокодеки идут по той же схеме. AAC-LC (1997) – универсальный дефолт стриминга. Opus (RFC 6716, 2012) – дефолт WebRTC и сильная замена AAC для HLS и DASH. xHE-AAC набирает тягу в стриминге за счёт устойчивости к адаптивному битрейту.

Главное, что нужно помнить про кодек: кодек – это алгоритм сжатия, а не файловый формат. Поток H.264 – это не файл, который вы дважды кликнете. Это последовательность бит, которой нужен контейнер сверху, чтобы превратиться в проигрываемый файл.

Слой 2 – контейнеры: тут собирают потоки вместе

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

Полезная аналогия: кодек делает стопку сжатых страниц по порядку. Контейнер – это переплёт, который держит страницы, добавляет нумерацию, печатает оглавление, помечает, какие страницы – главы, и подписывает, на каком языке текст. Без переплёта вы не найдёте страницу 47; без кодека переплёт пустой.

Пять контейнеров несут практически весь стриминг 2026:

MP4 (ISO/IEC 14496-14), построенный поверх ISO Base Media File Format (ISOBMFF, ISO/IEC 14496-12). Доминирующий контейнер для хранимого видео. Внутри MP4 данные организованы как дерево «боксов»: бокс ftyp в начале объявляет, какому бренду и версии файл соответствует; бокс moov несёт всю временную разметку (sample tables для каждой дорожки); боксы mdat несут собственно сжатые байты медиа. Обычный MP4 не стримится из коробки, потому что бокс moov может оказаться в конце файла – а значит, плееру придётся скачать файл целиком, прежде чем он сможет индексировать хоть что-то.

Fragmented MP4 (fMP4), определён внутри ISO/IEC 14496-12 как «фрагментированное» расширение. fMP4 режет длинный mdat на много маленьких фрагментов, каждому предшествует свой бокс moof (movie fragment) с разметкой только этого фрагмента. Плеер может начать воспроизведение после загрузки начального ftyp + moov (initialization segment) плюс первого фрагмента. fMP4 – современный стриминговый контейнер, лежит в основе HLS, DASH и CMAF.

MPEG-2 Transport Stream (TS), ISO/IEC 13818-1, изначально спроектирован для эфирного бродкаста в 1995. Файл TS – это последовательность пакетов фиксированной длины 188 байт, каждый несёт идентификатор Packet Identifier (PID), указывающий, какому элементарному потоку он принадлежит. TS был исходным контейнером HLS и до сих пор используется в легаси-деплоях HLS и в бродкаст-contribution. Накладные расходы значительные (примерно 2–5%) по сравнению с fMP4 из-за пакетной структуры.

Matroska (MKV) и её веб-подмножество WebM. MKV – гибкий контейнер, популярный для хранимого видео и записи; WebM – это MKV, ограниченный видео VP8/VP9/AV1 и аудио Vorbis/Opus, дефолтный веб-контейнер в Chrome. MKV в стриминге встречается редко – ни один крупный стриминговый протокол не использует его как формат сегмента.

CMAF, ISO/IEC 23000-19, финализирован в 2018 и обновлён в 2024. CMAF – не вполне новый контейнер, а строго ограниченный профиль fMP4. CMAF говорит: «если ваши fMP4-сегменты выглядят ровно вот так, одни и те же сегменты можно использовать и для HLS, и для DASH одновременно». До CMAF OTT-провайдер должен был кодировать две параллельные библиотеки (одна в MPEG-TS для HLS, другая в fMP4 для DASH); после CMAF одна библиотека обслуживает обе. Эта консолидация под снижение стоимости CDN – главная причина, по которой CMAF важен. Подробно – в статье CMAF: формат упаковки, объединивший HLS и DASH.

Главное, что нужно помнить про контейнер: контейнер – это файловый формат, а не механизм доставки. Файл fMP4 на диске – это контейнер. Протокол, отгружающий его байты по интернету плееру, – это следующий слой сверху.

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

Слой 3 – протоколы: тут переносят байты

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

Протоколы на стороне distribution (доставка плееру зрителя) и на стороне contribution (один сигнал от энкодера в облако) – очень разные семейства. Мы разбирали этот раздел в статье Push и Pull, Contribution и Distribution; здесь – короткое резюме, где какой протокол живёт и как он соотносится с контейнером и кодеком, которые он несёт.

HLS – HTTP Live Streaming. IETF RFC 8216, август 2017, плюс Apple HLS Authoring Specification (ревизия 2025-09), накладывающий нормативные требования сверху для экосистемы Apple. HLS – протокол доставки, работающий так: сервер отдаёт короткие медиа-сегменты (обычно 2–10 секунд) плюс текстовый файл playlist (расширение .m3u8), который их перечисляет. Контейнер внутри сегментов – либо MPEG-TS, либо fMP4 (Apple добавила поддержку fMP4 в 2016). Кодек внутри контейнера – на выбор паблишера: H.264 и HEVC чаще всего, AV1 валиден в HLS с iOS 17.

MPEG-DASH – Dynamic Adaptive Streaming over HTTP. ISO/IEC 23009-1:2022. Та же общая идея, что у HLS – сегменты плюс манифест – но манифест представляет собой XML-файл MPD (Media Presentation Description), а контейнер сегмента почти всегда fMP4. DASH – доминирующий протокол за пределами экосистемы Apple. DASH-IF, отраслевая организация, публикует Implementation Guidelines, которые де-факто и есть профиль.

Low-Latency HLS (LL-HLS) и Low-Latency DASH (LL-DASH). Расширения HLS и DASH, публикующие частичные сегменты – фрагменты в несколько сотен миллисекунд – вместо целых, что снижает end-to-end-задержку с 20+ секунд примерно до 3 секунд. Оба сильно опираются на chunked-кодирование CMAF, чтобы частичные сегменты были совместимы.

WebRTC (W3C Recommendation плюс RFC 8825–8866). Семейство протоколов реального времени, спроектированное под задержку меньше 500 мс. WebRTC не перевозит файловые сегменты – он перевозит RTP-пакеты с кадрами напрямую, по UDP, с собственной темпеализацией, шифрованием (SRTP) и congestion control. Понятие контейнера почти не применяется: в полёте нет ни MP4, ни TS. Кодек должен быть из mandatory-списка WebRTC (H.264, VP8, VP9, AV1, Opus, G.711).

RTMP – Real-Time Messaging Protocol от Adobe, 1996, формально устаревший у Adobe, но всё ещё самый используемый contribution-протокол, потому что все энкодеры умеют. Сегодня RTMP только на стороне contribution; в доставке мёртв.

SRT, RIST, WHIP – современные contribution-протоколы. SRT (Internet-Draft draft-sharabayko-srt-01) – это UDP-based надёжный транспорт с настраиваемыми FEC и retransmission. RIST (SMPTE TR-06-1/2/3) – broadcast-grade-альтернатива. WHIP (IETF RFC 9725, март 2025) – это WebRTC-based HTTP-сигналинг для ингеста в медиа-сервер. Ни один из них не доставка.

Media over QUIC (MoQ) – draft-ietf-moq-transport-17 (январь 2026), экспериментальное будущее низколатентного стриминга. MoQ работает поверх QUIC, рассматривает поток как дерево именованных объектов, а не как список сегментов, и нацелен на менее чем секундную задержку на CDN-масштабе. В 2026 не production-ready.

Главное, что нужно помнить про протокол: протокол несёт байты, он их не делает. Если коллега говорит «доставляем по HLS», он не сказал вам ничего про кодек или контейнер – это независимые выборы. И наоборот, «кодируем H.264 в fMP4» не говорит про протокол.

Слой 4 – профили: поименованные поднаборы, ограничивающие каждый слой

Профиль – это контракт, написанный людьми, определившими кодек, контейнер или протокол, который гласит: «если придерживаться этого поднабора правил, любой, кто поддерживает этот профиль, сможет декодировать или обработать ваш поток». На каждом слое есть свои профили, и слово везде значит немного разное – поэтому «профиль» и есть самое запутанное слово во всём этом словаре.

Профили кодека

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

Профили H.264 – канонический пример.

Стриминговый workflow 2026 практически всегда кодирует H.264 в High profile. Baseline остаётся только в легаси-WebRTC-клиентах, которые не обновились.

Профили HEVC устроены так же: Main, Main 10, Main Still Picture плюс несколько профессиональных расширений. HEVC добавляет ортогональное понятие tier – Main tier для consumer-grade-битрейтов, High tier для профессиональных. 4K-поток может выглядеть как «HEVC Main 10 profile, Main tier».

Профили AV1 проще: Profile 0 (Main, 4:2:0 8/10-бит), Profile 1 (High, добавляет 4:4:4), Profile 2 (Professional, добавляет 12-бит и full range). Profile 0 покрывает практически весь стриминг.

Профили кодека несут ещё levels – ортогональные числовые метки, ограничивающие максимальное разрешение, частоту кадров, битрейт и размер буфера. Поток H.264, помеченный как avc1.640028, – это High profile (6400), level 4.0 (28 в hex). Плеер с аппаратной поддержкой до level 5.1 декодирует любой поток level 5.1-и-ниже в этом профиле, но может захлебнуться на level 6.2 – требования к буферу превышают возможности железа. Полная строка кладётся в атрибут CODECS= HLS и @codecs DASH.

Профили контейнера

Профили контейнера сужают, что разрешено внутри контейнера. CMAF – канонический пример. Технически CMAF – это профиль fMP4 (который сам является расширением ISO Base Media File Format). CMAF говорит, среди прочего: каждый фрагмент должен начинаться с IDR-сэмпла, порядок боксов должен быть строго moof затем mdat, шифрование должно быть cbcs или cenc, аудио sample entry должен быть из фиксированного списка. Результат – настолько строгий fMP4, что один и тот же файл годится любому HLS-плееру и любому DASH-плееру.

Бокс ftyp в начале MP4 несёт список идентификаторов бренда, говорящих, каким профилям файл соответствует. Распространённые бренды: isom (ISO Base Media), iso6 (шестая ревизия, обязательна для fMP4 HLS по RFC 8216 §3.3), cmfc (CMAF Common Encryption track), mp42 (MP4 v2), dash (DASH-conformant). Один файл может объявлять несколько брендов.

Профили протокола

Профили протокола сужают, что разрешено делать имплементации протокола доставки.

В MPEG-DASH несколько профилей определены в ISO/IEC 23009-1 §8: ISO Base Media File Format On Demand profile (одна репрезентация – один файл, запросы по byte-range, под VOD), ISO Base Media File Format Live profile (URL сегментов по шаблону, под Live), MPEG-2 Transport Stream profile (для легаси DASH на TS) и CMAF profiles (добавлены в пятой редакции 2022), требующие контейнер CMAF. DASH-IF Implementation Guidelines накладывают дополнительные ограничения профиля сверху – DASH-IF IOP CMAF Live, DASH-IF IOP On Demand и так далее.

HLS формально не использует слово «профиль», но Apple HLS Authoring Specification публикует обязательные ограничения (правила вариантных стримов, длительности сегментов, codec strings, параметры шифрования), которые на практике и есть профиль. Apple обновляет спеку 1–3 раза в год; ревизия сентября 2025 – самая свежая.

WebRTC имеет неявные профили в виде codec mandatory-to-implement-списков в RFC 7742 (видео) и RFC 7874 (аудио) плюс параметр SDP profile-level-id для H.264.

Единственное правило, снимающее всю путаницу с профилями

Когда кто-то говорит «профиль» в разговоре про стриминг, первая реакция должна быть: какой слой? Если речь о High profile H.264 – это профиль кодека. Если о CMAF – профиль контейнера. Если о DASH-IF Live – профиль протокола. Одно и то же слово, три разных слоя. Спрашивайте.

Рецепт из четырёх слоёв на практике

Слои композируются. Реальный стриминговый продукт выбирает по одному варианту с каждого слоя.

Полный OTT-рецепт 2026 выглядит так:

«H.265 Main 10 profile на level 5.1, аудио AAC-LC, упаковано в fMP4, соответствующий бренду CMAF, доставляется через Low-Latency HLS по Apple HLS Authoring Specification ревизия 2025-09.»

Читайте изнутри наружу – и каждый из четырёх слоёв мапится на свою фразу: кодек («H.265 Main 10 ... level 5.1»), контейнер («fMP4 ... CMAF brand»), протокол («Low-Latency HLS»), профили на каждом слое («Main 10», «CMAF», «HLS Authoring 2025-09»).

Распространённая ошибка – путать codec strings с расширением файла

Частая ошибка, особенно в вендорской документации, – путать кодек с расширением файла. Файл bigbuckbunny.mp4 может содержать видео H.264, H.265, AV1 или вообще что-то экзотическое – .mp4 ничего не говорит про кодек внутри. Наоборот, файл .mkv может держать видео H.265, которое HLS-пайплайн спокойно перекодирует и отдаст. Расширение называет контейнер, не кодек.

Правильный способ выразить, что внутри, – это MIME-тип с параметром codecs=, определённый в RFC 6381. Для потока H.264 High profile level 4.0 + AAC-LC в MP4 полный MIME-тип такой:

video/mp4; codecs="avc1.640028, mp4a.40.2"

Эта строка кладётся в атрибут CODECS= HLS-манифеста и в @codecs DASH MPD. Строка говорит плееру точно, какой кодек, какой профиль и какой level внутри контейнера. Та же логика для AV1 (av01.0.04M.08), HEVC (hev1.1.6.L93.B0) и Opus (opus).

Если codec strings неправильные, плееры, строго валидирующие манифест (а это большинство smart-TV-приложений), отбракуют поток ещё до попытки воспроизведения.

Краткое сравнение: где живёт каждое слово

Одна таблица, которую можно держать под рукой. Кодек, контейнер, протокол, профиль – рядом.

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

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

Мы поставляем видеостриминг, видеоконференции, OTT/Internet TV, e-learning, телемедицину и видеонаблюдение с 2005 года, и «на каком слое живёт это решение?» – один из первых вопросов на скоупинге. Мы переводили OTT-клиентов с HLS на MPEG-TS на CMAF fMP4, чтобы вдвое сократить CDN-хранение; переключали телемедицинские и e-learning конференц-пайплайны с RTMP-ингеста на WHIP ради задержки меньше секунды; помогали клиентам видеонаблюдения выбирать между H.265 и AV1 для архивного хранения с количественной оценкой полосы и лицензионных издержек. Четырёхслойная модель из этой статьи – это та модель, которой мы пользуемся внутри: она удерживает выборы кодека, контейнера, протокола и профиля от того, чтобы запутаться на стадии архитектуры.

Ключевые выводы

• Кодек, контейнер, протокол и профиль – четыре независимых слоя; путать их – главная стриминговая словесная ошибка.
• Кодек сжимает пиксели в биты. H.264, H.265, AV1, VP9, H.266 – кодеки.
• Контейнер собирает эти биты со звуком, субтитрами и таймингом. MP4, fMP4, MPEG-TS, MKV, WebM – контейнеры.
• Протокол перевозит байты контейнера через сеть. HLS, DASH, WebRTC, RTMP, SRT, WHIP, MoQ – протоколы.
• Профиль – это поднабор-ограничение, привязанный к кодеку, контейнеру или протоколу. Всегда спрашивайте, на каком слое.
• Реальный рецепт называет значение на каждом слое: например, H.265 Main 10 в fMP4-CMAF поверх LL-HLS.

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

• Что такое доставка видео и почему это сложнее, чем отдать JPEG – пилларная статья Блока 1, задающая весь словарь раздела.
• Конвейер стриминга от и до – где четыре слоя сидят внутри полного пайплайна «съёмка → рендер».
• CMAF: формат упаковки, объединивший HLS и DASH – подробный разбор профиля контейнера, который съел стриминговый мир.