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

Опубликовано: 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 с errata 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 кадров в секунду и 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 в 2024 году, AV1 обеспечивает около 30% их стриминговых часов глобально; к 2026 году эта доля выросла. Кодек – выбор по умолчанию для новых развёртываний, если не требуется поддержка устаревших систем.
• 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 содержит всю временную разметку (таблицы образцов для каждой дорожки); боксы 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, а также в вещательных системах передачи контента. Накладные расходы значительны – около 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. Он формулирует простой принцип: «если ваши 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 секунд) и текстовый файл плейлиста (расширение .m3u8), в котором они перечислены. Внутри сегментов используется контейнер – либо MPEG-TS, либо fMP4 (поддержку fMP4 Apple добавила в 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, при которых публикуются частичные сегменты продолжительностью несколько сотен миллисекунд вместо полных сегментов. Это позволяет снизить конечную задержку с 20+ секунд примерно до 3 секунд. Оба формата активно используют chunked-кодирование CMAF, чтобы обеспечить совместимость частичных сегментов.

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

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

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

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

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

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

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

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

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

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

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

Профили HEVC устроены аналогично: Main, Main 10, Main Still Picture и несколько профессиональных расширений. В HEVC введено ортогональное понятие tier – Main tier для потребительских битрейтов, 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 покрывает практически весь стриминг.

Профили кодека также имеют уровни – ортогональные числовые метки, ограничивающие максимальное разрешение, частоту кадров, битрейт и размер буфера. Поток H.264, помеченный как avc1.640028, относится к профилю High (6400), уровень 4.0 (28 в hex). Плеер с аппаратной поддержкой до уровня 5.1 способен декодировать любой поток уровня 5.1 и ниже в этом профиле, но может не справиться с уровнем 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-совместимый). Один файл может объявлять несколько брендов.

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

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

В 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 публикуются обязательные ограничения – правила для вариантных стримов, длительности сегментов, строк кодеков и параметров шифрования, – которые на практике и выполняют роль профиля. Apple обновляет спецификацию 1–3 раза в год; ревизия сентября 2025 года – самая свежая.

WebRTC использует неявные профили в виде списков 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 на уровне 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»).

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

Частая ошибка, особенно в документации от вендоров, – путать кодек с расширением файла. Файл 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. Она сообщает плееру точные параметры кодека: тип, профиль и уровень внутри контейнера. Та же логика применяется к AV1 (av01.0.04M.08), HEVC (hev1.1.6.L93.B0) и Opus (opus).

Если строки кодеков указаны неверно, плееры, строго проверяющие манифест (а к таким относится большинство приложений для 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 – подробный разбор контейнера, который покорил стриминговый мир.