Количество цветов и цветовое разрешение видеосигнала описывается цветовыми моделями. Для стандарта PAL применяется цветовая модель YUV, для SÉCAM модель YDbDr, для NTSC модель YIQ, в компьютерной технике применяется в основном RGB (и αRGB), реже HSV, а в печатной технике CMYK. Количество цветов, которое может отобразить монитор или проектор зависит от качества монитора или проектора.
Человеческий глаз может воспринять, по разным подсчётам, от 5 до 10 миллионов оттенков цветов. Количество цветов в видеоматериале определяется числом бит, отведённым для кодирования цвета каждого пикселя (англ. bits per pixel, bpp). 1 бит позволяет закодировать 2 цвета (обычно чёрный и белый), 2 бита — 4 цвета, 3 бита — 8 цветов, …, 8 бит — 256 цветов (28 = 256), 16 бит — 65 536 цветов (216), 24 бита — 16 777 216 цветов (224). В компьютерной технике имеется стандарт и 32 бита на пиксель (αRGB), но этот дополнительный α-байт (8 бит) используется для кодирования коэффициента прозрачности пикселя (α), а не для передачи цвета (RGB). При обработке пикселя видеоадаптером, RGB-значение будет изменено в зависимости от значения α-байта и цвета подлежащего пикселя (который станет «виден» через «прозрачный» пиксель), а затем α-байт будет отброшен, и на монитор пойдёт только цветовой сигнал RGB.
Северный поток. Что произошло на самом деле?
Ширина (иначе говорят скорость) видеопотока или битре́йт (англ. bit rate) — это количество обрабатываемых бит видеоинформации за секунду времени (обозначается «бит/с» — бит в секунду, или чаще «Мбит/с» — мегабит в секунду; в английском обозначении «bit/s» и «Mbit/s» соответственно). Чем выше ширина видеопотока, тем в общем лучше качество видео.
Например, для формата VideoCD ширина видеопотока составляет всего примерно 1 Мбит/с, а для DVD составляет около 5 Мбит/с. Конечно, субъективно разницу в качестве нельзя оценить как пятикратную, но объективно это так. А формат цифрового телевидения HDTV использует ширину видеопотока около 10 Мбит/с. При помощи скорости видеопотока также очень удобно оценивать качество видео при его передаче через Интернет.
Различают два вида управления шириной потока в видеокодеке — постоянный битрейт (англ. constant bit rate, CBR) и переменный битрейт (англ. variable bit rate, VBR). Концепция VBR, ныне очень популярная, призвана максимально сохранить качество видео, уменьшая при этом суммарный объём передаваемого видеопотока. При этом на быстрых сценах движения, ширина видеопотока возрастает, а на медленных сценах, где картинка меняется медленно, ширина потока падает. Это очень удобно для буферизованных видеотрансляций и передачи сохранённого видеоматериала по компьютерным сетям. Но для безбуферных систем реального времени и для прямого эфира (например, для телеконференций) это не подходит — в этих случаях необходимо использовать постоянную скорость видеопотока.
Источник: studopedia.su
Контроль качества транспортных потоков и мониторинг ТВ-каналов ( вебинар от 28.07.2020)
Какой Протокол Стриминга Лучше для Вас: RTMP или RTSP
Сравним протоколы потоковой передачи RTMP и RTSP. Расскажем, как они работают, какие у каждого плюсы и минусы. Подскажем, как выбрать в вашем случае.
Если вы хотите запустить платформу для трансляции видео с минимальной задержкой, у вас будет весьма ограниченное количество протоколов потоковой передачи данных для решения этой задачи. При этом если в качестве канала передачи видеопотока вы хотите использовать интернет, выбор будет еще меньше, поскольку вам нужно будет преодолеть ряд трудностей, например — джиттер, лаги или потеря пакетов. В этой статье мы сравним два таких протокола связи — RTMP и RTSP, опишем их преимущества с недостатками, а также дадим некоторые рекомендации по выбору наиболее подходящего для вас варианта.
Что такое протокол связи
Задержка при потоковой передаче данных посредством популярных протоколов связи. Источник
Прежде всего стоит уточнить, что и RTMP, и RTSP — это протоколы потоковой передачи данных, что означает, что они представляют собой наборы определенных соглашений интерфейса логического уровня, определяющих метод передачи видео, аудио и других типов данных между различными платформами, системами или устройствами. Эти правила нужны, чтобы задать стандарт передачи информации и обработки ошибок, что нужно для нормальной работы любой видеотрансляции.
Если сравнить видео, которые нужно отправить зрителям, с автомобилем, то протокол потоковой передачи — это правила дорожного движения и сама дорога, по которой автомобиль перемещается из одного места в другое. Если дорога хорошая, машина без проблем доедет до своей цели. Если же на дороге будут ухабы и ямы, то движение займет больше времени и машина может получить повреждения.
С видеоданными все так же: если протокол хороший, видеосигнал доберется до зрителя с минимальной задержкой и будет высокого качества. Если же протокол плохо реализован или не соответствует задаче, то видео на экране зрителя может «сыпаться», часто прерываться для подзагрузки, содержать артефакты, вовсе не грузиться или аудио- и видеосигналы будут рассинхронизированы.
Различные протоколы потоковой передачи данных ориентированы на разные аспекты потока (задачи). Обычно их делят на протоколы с адаптивным битрейтом, которые нацелены на уменьшение задержек и буферов для видеопотока, и те, что направлены на максимальное сокращение задержки, что позволяет передавать видеосигнал зрителям практически в реальном времени — live streaming.
RTMP и RTSP — это, пожалуй, два наиболее распространенных протокола, ориентированных на стриминг видео с минимальной задержкой. И хотя они созданы для достижения схожих целей, при пристальном сравнении между ними легко обнаружить существенные различия, которые важно знать.
Что такое RTMP и как он работает
Протокол обмена сообщениями в реальном времени, или RTMP — это стандартизированный протокол для передачи мультимедийных данных через интернет. Данная технология была разработана Macromedia (в настоящее время принадлежит Adobe), и изначально она использовалась для передачи данных между RTMP-сервером и Flash-плеером на устройстве пользователя. Сейчас Flash больше не используется из-за проблем с безопасностью, но RTMP все еще популярен.
Как протокол связи технология RTMP нацелена на обеспечение стабильной и плавной передачи увеличивающихся объемов данных, необходимых для передачи и приема видео в реальном времени. Что достигается посредством фрагментирования потока данных на небольшие одинаковые части (по умолчанию составляют 64 байта для аудиоданных и 128 байтов для видеоданных) и их последовательную передачу на принимающее устройство, которое затем снова собирает их в видеопоток.
После того как Flash устарел в 2020 году (Google и другие крупные игроки полностью прекратили поддержку Adobe Flash Player), RTMP стал использоваться в качестве протокола с открытым исходным кодом для вклада первой мили (передачи от кодировщика к сетевому видеохосту). Именно таким образом RTMP сейчас использует Facebook, YouTube, Periscope и большинство других платформ.
Сейчас RTMP существует в 5 вариантах:
Как работает потоковая передача RTMP
Как правило, прямая видеотрансляция работает следующим образом: камера снимает видео (или видеокарта захватывает экран) и отправляет его на хост или сервер видеоплатформы через кодировщик (этот этап обычно называют «первой милей»). Затем сервер или видеоплатформа обрабатывает этот поток и передает его дальше через сеть доставки контента (CDN) для распространения видеопотока на устройства пользователей (это «последняя миля»). Когда еще работал Flash, оба эти этапа проходили посредством RTMP, но с тех пор, как Flash устарел, RTMP больше не работает на «последней миле». С этого момента поток должен перехватить другой протокол связи (HLS, MPEG-DASH, CMAF или WebRTC).
На диаграмме показаны четыре отдельных этапа в цепочке доставки видео в реальном времени. Первый этап обычно называют «первой милей» (передача видео от камеры до сервера), а четвертый — «последней милей» (видео доставляется на экран пользователя, например телевизор). Источник
Однако на первой миле RTMP по-прежнему актуален, поскольку он отлично справляется с обеспечением стабильного и плавного видеопотока между источником видео и RTMP-сервером за счет разделения больших объемов данных на маленькие блоки и их передачу через несколько виртуальных каналов. При этом RTMP также открывает постоянное соединение между источником потока и сервером, позволяя протоколу выступать в качестве носителя для доставки пакетов данных.
- TCP/IP-рукопожатие. Клиент и сервер обмениваются между собой информацией, чтобы «договориться» о передаче потока.
- Установление связи. Клиент и сервер согласовывают все параметры и спецификации соединения с помощью последовательности сообщений.
- Передача потока. Клиент отправляет серверу вызов «create Stream», за которым следует сообщение проверки связи и воспроизведение.
Преимущества и недостатки RTMP
- Низкая задержка. С точки зрения прямых эфиров низкая задержка в основном означает надежное соединение, которое не отключится, даже если канал между сервером и зрителем немного нестабильный. Данный показатель также чрезвычайно важен для качества видео. Стабильное соединение RTMP обеспечивает благодаря тому, что он по умолчанию создается на TCP, тогда как низкая задержка достигается благодаря использованию эксклюзивного порта 1935, что устраняет необходимость буферизации видеопотока.
- Адаптируемость. В контексте трансляций адаптируемость означает возможность подключаться к трансляции и отключаться от нее когда угодно, кроме того, пользователи могут проматывать стрим назад (а затем и вперед) и присоединяться к прямому эфиру после его начала. Это очень полезные функции для онлайн-конференций, живых эфиров, стриминга видеоигр и простого видеозвонка.
- Гибкость. Технология RTMP позволяет интегрировать различные типы мультимедийного контента в один целостный пакет, «бесшовно» смешивая видео, аудио и текст (субтитры) на экране зрителя. Помимо этого, протокол поддерживает аудиопотоки в AAC- и MP3-форматах, а для передачи видео могут использоваться такие форматы, как MP4-, FLV- и F4V.
- Нет поддержки HTML5. Протокол RTMP не поддерживается HTML5-плеерами, которые на данный момент являются отраслевым стандартом для воспроизведения видео на стороне пользователя (в браузерах Mozilla, Google, Microsoft, Apple и Opera). Для «преобразования» RTMP-потока в HTML нужен конвектор, например HLS (протокол Http Live Stream, разработанный Apple).
- Проблемы с пропускной способностью. У RTMP есть некоторые уязвимости, связанные с низкой пропускной способностью. Они могут стать причиной периодических прерываний потоковой передачи видео, которые, как правило, очень сильно портят впечатление от просмотра видео.
- Несовместимость с HTTP. Последний недостаток RTMP — это невозможность передачи RTMP-потока через HTTP. Чтобы опубликовать RTMP-поток на сайте, нужно реализовать специальный сервер, такой как Flash Media Server, и использовать CDN или платформу потокового видео.
Что такое RTSP и как он работает
Протокол потоковой передачи в реальном времени, или RTSP — это менее известный, чем RTMP, набор правил для потоковой передачи видео с помощью интернета. Его представили RealNetworks, Netscape и Колумбийский университет в 1996 году для управления развлекательными и коммуникационными системами видеотрансляций в «стиле VHS». Это подразумевает, что во время передачи потока RTSP-сервер может обрабатывать команды на VHS-пульте: «Воспроизведение», «Пауза», «Стоп», а также «Прокрутить вперед» и «Прокрутить назад».
Для обеспечения плавной и согласованной потоковой передачи данных RTSP использует два других сетевых протокола связи — TCP для выдачи и приема команд управления (например, запроса на воспроизведение или остановку) и UDP (протокол пользовательских датаграмм) для доставки аудио, видео и данных. Благодаря этому клиент может начать воспроизводить RTSP-поток во время загрузки потока.
Хотят RTSP можно использовать как для прямых трансляций, так и для передачи видео по запросу, сейчас его обычно используют на последней миле для передачи видеопотока с облака в проигрыватель устройства пользователя, поскольку данный протокол позволяет зрителю воспроизводить, приостанавливать и перематывать видео. Кроме того, RTSP также популярен в системах, где нужно передать видеосигнал с камер по IP, например с IP-камер или камер видеонаблюдения.
Как работает потоковая передача RTSP
Схема передачи видео через RTSP. Источник
Как протокол связи RTSP работает следующим образом. Когда пользователь (программа, приложение или камера) хочет передать видеосигнал с удаленного источника, пользовательское устройство отправляет RTSP-запрос на специальный сервер (или платформу потокового видео), чтобы определить доступные параметры, такие как воспроизведение, пауза, перемотка и запись. Затем сервер возвращает на устройство сигнал со списком запросов, которые он может принимать через RTSP.
Как только устройство (плеер) узнает список команд и как сделать запрос, он передает запрос описания видеоконтента на сервер потоковой передачи, и сервер отвечает описанием этого мультимедиа. Дальше устройство отправляет запрос на загрузку, а сервер отвечает информацией о транспортном механизме, и дальше инициируется процесс потоковой передачи видео через указанный механизм.
Так как RTSP зависит от выделенного сервера и полагается на RTP, данный протокол не поддерживает шифрование видеоконтента или повторную передачу потерянных пакетов. Кроме того, RTSP не совместим с HTTP, следовательно, он не позволяет напрямую воспроизводить видеопоток в веб-браузере. Для этого нужно конвертировать видеопоток через специальный промежуточный сервер.
Преимущества и недостатки RTSP
- Сегментированная потоковая передача. Это означает возможность просмотра видео без необходимости его загрузки целиком перед просмотром, что удобно, если вам нужно организовать передачу видео по запросу.
- Настройка. RTSP позволяет создавать собственные приложения для потоковой передачи видео, которые будут использовать многопротокольный подход TCP + UCD — от видеомессенджеров до программного обеспечения для онлайн-видеоконференций.
- Меньшая популярность. Большинство веб-браузеров, видеоплееров и потоковых сервисов не поддерживают RTSP, что затрудняет трансляцию видеосигнала напрямую в браузер. Для этого необходимо использовать специальную службу потоковой передачи RTSP в реальном времени.
- Несовместимость с HTTP. Поскольку RTSP изначально создавался для использования в частных сетях, вы не можете напрямую передавать RTSP через HTTP. Для этого нужно специальное программное обеспечение, которое будет принимать видеопоток с RTSP-сервера, встраивать его на веб-страницу и давать возможность зрителям воспроизводить его на своих экранах.
Технические характеристики RTMP vs RTSP
Какой протокол лучше для вас
В подавляющем большинстве случаев выбор между RTMP и RTSP определяется задачей проекта и устройствами, используемыми для потоковой передачи видео в реальном времени. Вот несколько рекомендаций о том, когда какой протокол потоковой передачи видео лучше использовать в вашем случае.
IP-камеры → RTSP. Практически все IP-камеры поддерживают RTSP, что обусловлено тем, что IP-камеры существовали задолго до создания протокола RTMP. И поскольку RTSP был (и остается) достаточно простым и эффективным инструментом для передачи видеосигнала, нет необходимости что-то менять.
В связке RTSP и IP-камеры, сама IP-камера действует как RTSP-сервер. Это означает, что для подключения видеокамеры к серверу IP-камеры и трансляции видео необходимо запустить RTSP-клиент, например, посредством Restreamer Red5 Pro. Данный плагин позволяет подключиться к потоку в качестве клиента и перенаправить его на другие конечные точки, поддерживающие Red5 Pro (браузер, работающий с WebRTC).
IoT-устройства → RTSP или RTMP. Датчики, дроны, роботы, машины и другие устройства Интернета вещей могут выиграть от возможности транслировать видео в реальном времени. Поскольку такая трансляция не только покажет, что «видит» IoT-устройствоно и позволит управлять им в реальном времени. Благо, в большинство этих устройств изначально встроено программное обеспечение с поддержкой RTSP. Однако некоторые производители, такие как DJI, предпочитают RTMP.
Red5 Pro Mobile SDK → RTSP. Обычно мобильные устройства не поддерживают RTSP. Однако его можно легко добавить с помощью Red5 Pro Mobile SDK, который использует RTSP для трансляции видеоконтента в реальном времени на мобильные устройства и обратно через приложение Red5 Pro. Таким образом можно создавать как отдельные соединения источник-зритель, так и вести большое количество трансляций к большому количеству зрителей (подписчиков стримера).
YouTube, Twitch, Facebook → RTMP. Несмотря на отказ от Flash Media Player, RTMP до сих пор используется в качестве протокола приема во многих сторонних потоковых сервисах и приложениях, например в YouTube Live, Twitch и Facebook. В Zoom также встроена поддерживает вывод видео потока по RTMP.
Старый аппаратный кодировщик → RTMP. Многие аппаратные кодировщики видео (особенно это актуально для старых устройств) принимают только RTMP-потоки. Если ваша задача / проект требует использования такого кодировщика, то выбор между RTMP и RTSP для вас будет очевиден.
Заключение
Споры о том, какой протокол потоковой передачи лучше — RTMP или RTSP, продолжаются уже больше двадцати лет, и, похоже, им не будет конца, пока один из протоколов не устареет окончательно. Что, скорее всего, случится еще нескоро из-за резкого роста числа влогеров, стримеров и прочих энтузиастов live-трансляций.
Правда, если подумать, вам не обязательно выбирать между одним из этих протоколов потокового видео. Выбрав надежного технического партнера, такого как компания-разработчик Merehead, вы можете разработать решение, которое вберет в себе лучшее этих двух протоколов и обойдет их недостатки. Кастомная разработка потребует немного больше времени и ресурсов, чем готовые решения, но в долгосрочной перспективе она все равно будет более выгодной.
Оцените (242 оценки — 4.2 из 5)
Источник: merehead.com
Головная станция IPTV сети
Основная функция головной станции IPTV это формирование видео-контента и последующая трансляция выходного потока видеоданных в формате Video over IP (видео по IP протоколу). Также для магистральной (опорной части сети) может использоваться формат IP-Video over ATM (IP видео поверх ATM). Это связано с широким распространением магистральных ATM сетей. Для трансляции видео-контента через ATM / SDH сети многие операторы используют, например, хорошо известную станцию цифрового телевидения Teleste ATMux.
Рисунок 9 – Компоненты IP TV сети
Рассмотрим подробнее требования к головной станции IPTV.
Современная станция IPTV должна работать с широким диапазоном входных источников видео-контента, в том числе:
— спутниковые ТВ каналы в формате DVB-S, получаемые через DVB-ASI интерфейс приемников или «потоковых дескремблеров» в режиме однопрограммного транспортного потока (SPTS) или многопрограммного транспортного потока (MPTS);
— аналоговое и цифровое некомпрессированное видео, получаемое от студийного ТВ оборудования в форматах SDI, S-video, композитный видеосигнал, а также можно предположить использование цифровых интерфейсов DVI (Digital video interface) и HDMI (High-Definition Multimedia Interface);
— эфирные цифровые программы через DVB-ASI интерфейс DVB-T — приемников и с меньшей вероятностью аналоговые эфирные каналы в формате композитного видео, полученное с выхода аналоговых эфирных демодуляторов;
— видео-контент, передаваемый через транспортные сети в форматах IPTV (MPEG over IP), Video over ATM; IP-video over ATM.
Формирование видео-контента в форматах DVB-ASI (SPTS/MPTS) производится «обычной» цифровой головной станцией DVB, которая часто уже существует у оператора и уже некоторое время обслуживает его кабельную DVB-C сеть. В самом простейшем случае это комплект спутниковых цифровых приемников с ASI-выходом.
Более сложной и меньше знакомой операторам является вторая составная часть станции, формирующая выходные IP-потоки или собственно IPTV станция. Используют также термины IP-инкапсулятор и IP-стриммер.
Приведем термины, обозначающие основные процессы, производимые IPTV головной станцией:
— IP-encapsulation («IP-инкапсуляция») – базовая функция станции, обеспечивает включение транспортных MPEG-пакетов в качестве полезной информационной нагрузки в состав кадров протокола PDU (protocol data unit), и последующую передачу данных в телекоммуникационных сетях Gigabit Ethernet и ATM;
— transrating («трансрейтинг») – изменение (понижение) скорости потока данных, используется также аналогичный по смыслу термин rateshaping;
— transcoding («транскодинг») – транскодирование, изменение формата сжатия медиа-данных, например поток MPEG2 транскодируется в MPEG4;
— encoding («энкодинг») – компрессия несжатого видео с целью получения на выходе «энкодера» транспортного потока в формате MPEG2 (4) или VC-1 / Windows Media VC-9 (на входе энкодера видеосигнал может быть в аналоговом, например, композитное видео, S-video или в цифровом, например SDI формате);
— decoding («декодинг») – декодирование, восстановление исходной несжатой информации;
— re-encoding («ре-энкодинг»)– в цифровом телевидении восстановление несжатой информации и повторное энкодирование с целью значительного изменения скорости потока (иногда этим термином называют также изменение формата сжатия, т.е. фактически могут подразумевать транскодинг);
— scrambling («скремблинг») – буквально шифрование, подразумевается использование системы условного доступа (CAS);
— de-scrambling («де-скремблинг») – буквально дешифрование, подразумевается раскрытие скремблированных ТВ каналов;
— multiplexing или remultiplexing – мультиплексирование, в цифровом телевидении этим термином обычно обозначается мультиплексирование входных однопрограммных транспортных потоков (SPTS) и/или мультипрограммных транспортных потоков (MPTS) в необходимый оператору выходной мультипрограммный транспортный поток (MPTS), при этом также производится фильтрация незначащих и лишних данных путем редакции PSI данных, строго говоря даже однопрограммный транспортный поток является результатом мультиплексирования трех потоков – видео, аудио и данных;
— de-multiplexing – демультиплексирование, операция обратная мультиплексированию;
— statistical multiplexing – статистическое мультиплексирование, используется главным образом для MPTS потоков, направляемых от земной станции на спутник (up-link), при этом виде обработке общая скорость многопрограммного потока является почти постоянной, но скорость каждого из однопрограммных потоков, составляющих общий MPTS поток является переменной (VBR). Статистическое мультиплексирование позволяет эффективно использовать полосу спутникового транспондера, но вынуждает операторов IPTV, (особенно для DSL-сетей) использовать трансрейтинг или даже ре-энкодинг;
— PSI redaction — редактирование таблиц сервисной информации (PSI, Program Specific Information — специальная информация о программах).
Функция PSI redactionхорошо известна операторам в «обычном» цифровом телевидении (DVB-S, -C). Предполагается примерно следующий базовый набор возможностей создания и редактирования сервисных таблиц:
— создание оператором NIT таблицы (Network Information Table), определяющей сетевые параметры;
— добавление и удаление оператором собственных идентификаторов в таблицы PMT (Program Map Table), SDT (Service Descriptor Table), NIT (Network Information Table) или CAT (Conditional Access Table);
— редактирование оператором частоты повторения выходных таблиц.
IP — инкапсуляция
Это самый главный процесс, выполняемый IPTV станцией. Для передачи транспортных MPEG-потоков через традиционные сети с пакетной передачей данных, головная станция IPTV объединяет множество 188-ми байтовых MPEG транспортных пакетов и формирует из них полезную нагрузку кадра PDU (protocol data unit).
Рисунок 10 – Процесс инкапсуляции
Следующие два рисунка 11 и 12 иллюстрируют инкапсуляцию MPEG-пакетов в Gigabit Ethernet сетях.
На рисунке 11 показан кадр в формате MPEG over UDP/IP over Gigabit Ethernet. Замыкающая часть кадра это как обычно CRC (cyclic redundancy code) – контрольный циклический избыточный код.
Рисунок 11а показывает инкапсуляцию MPEG over Gigabit Ethernet в реальном времени с использованием протокола RTP.
Рисунок 11 – Инкапсуляция кадра в формате MPEG over UDP/IP в Gigabit Ethernet
Протокол RTP (Real-time transport protocol) определяет и компенсирует потерянные пакеты, обеспечивая безопасность передачи контента и распознавание информации. Протокол RTP функционирует поверх протокола UDP (User Datagram Protocol), расположенного в стеке протоколов TCP/IP над протоколом IP. Разница между двумя рисунками только в добавлении RTP-заголовка в секцию заголовка протокола (Protocol Header).
Рисунок 11a — Инкапсуляция кадра в формате MPEG в Gigabit Ethernet с использованием RTP
Рисунок 12 иллюстрирует формат MPEG over UDP/IP over ATM с классической IP-инкапсуляцией (RFC 2684 LLC инкапсуляция маршрутизируемых протоколов). В состав полезной нагрузки AAL-5 входит IP-пакет, с нагрузкой из множества транспортных пакетов MPEG, плюс RFC 2684 заголовок и замыкающая часть кадра. В этом случае полный кадр AAL-5 PDU предоставлен уровню ATM для дальнейшей сегментации в ATM ячейки. (Padding в секции Trailer это заполнение секции незначащей информацией).
Для других RFC 2684 ATM подобных инкапсуляций производятся соответствующие изменения. Так, например, для инкапсуляции в реальном времени после заголовка UDP был бы заголовок RTP. А для мостовой (bridged) инкапсуляции Ethernet был бы заголовок Ethernet MAC перед IP заголовком.
Рисунок 12a показывает инкапсуляцию MPEG over Native ATM. Он очень похож на предыдущие рисунки, различие заключается в удалении UDP/IP и RFC 2684 уровней (собственно, поэтому такой метод и называется “Native” (наследственный) ATM, так как он не имеет каких-либо дополнительных протоколов). Для этого метода заголовок протокола является пустым и этот метод более эффективно использует ширину полосы, чем другие ATM методы. Однако присутствие UDP/IP заголовков в других методах позволяет поддерживать множество однопрограммных транспортных потоков (SPTS) через одну виртуальную ATM цепь, что невозможно в методе ATM Native.
Рисунок 12 — Инкапсуляция кадра в формате MPEG over UDP/IP в ATM
Рисунок 12a — Инкапсуляция кадра в формате MPEG over Native ATM
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru