MPEG-DASH в nginx-rtmp-module: живое видео в браузере без флеша
Что такое MPEG-DASH
DASH — Dynamic Adaptive Streaming over HTTP. Стандарт DASH ISO/IEC 23009-1:2012 был разработан группой MPEG в 2011 году
Технология MPEG-DASH в целом аналогична другой известной технологии HLS (HTTP Live Streaming), разработанной компанией Apple и широко используемой на мобильных устройствах с iOS и Android. Поток представлен в виде небольших по длительности фрагментов и плейлиста (манифеста), содержащего метаданные потока и ссылки на фрагменты.
В HLS плейлист хранится в формате m3u8 (расширение m3u), а фрагменты — в MPEG-TS (часть стандарта MPEG-2). В MPEG-DASH плейлист (манифест) хранится в XML, а фрагменты могут иметь как формат MPEG-TS, так и ISO BMFF (проще говоря, mp4). На практике поддержка MPEG-TS клиентами ограничена, так что ориентироваться приходится на более современный mp4.
В чем же состоит преимущество MPEG-DASH? Главное преимущество в том, что поддержка этой технологии сегодня активно внедряется в браузеры, что дает возможность вещать видео без использования тяжелого и порядком надоевшего flash. Кроме того, MPEG-DASH поддерживается новыми моделями телевизоров в рамках стандарта HbbTV.
Далее я расскажу о самой технологии и опишу, как настроить live вещание в браузере с помощью nginx-rtmp-module и dash.js.
Манифест
Фрагменты
MPEG-DASH на сервере
Начиная с версии 1.0.8 в nginx-rtmp-module реализована поддержка вещания живых потоков в MPEG-DASH. Происходит это аналогично вещанию в HLS. В указанной директории создаются dash-фрагменты, а также файл манифеста. В процессе вещания старые фрагменты удалятся, новые появляются, плейлист обновляется.
После сборки настраиваем MPEG-DASH
Вот как выглядит срез MPEG-DASH потока с именем mystream
MPEG-DASH в браузере
Основной инструмент, с помощью которого в настоящий момент реализуется проигрывание MPEG-DASH в браузерах — это плеер dash.js, являющийся референсной реализацией MPEG-DASH клиента и разрабатываемый организацией DASH Industry Forum. Плеер треует от браузера поддержки Media Source Extensions.
В настоящий момент плеер хорошо работает со статичным видео, однако с проигрыванием живых потоков у неего все еще есть определенные проблемы. Так, для поддержки live-вещаний в Chrome мне пришлось немного доработать плеер. Модифицированная версия лежит в бранче live моего форка проекта. Авторы плеера обещали в следующей версии полностью решить проблему с живыми вещаниями.
Скачиваем и устанавливаем dash.js из форка
Открываем в редакторе baseline.html и находим строчку со стандартным урлом
Заменяем на наш урл
Добавляем локейшен в nginx для отдачи содержимиго dash.js, включая тестовую страницу
Теперь запускаем вещание с именем mystream
Статьи
SRT, HLS и MPEG-DASH – будущее потокового вещания
Компании и провайдеры сетей доставки контента (CDN) готовятся к будущему, где потоковое вещание получит ещё более широкое распространение. Поэтому потребность в более эффективных протоколах такого вещания становится как никогда актуальной. Встречайте будущее живых трансляций – SRT, HLS и MPEG DASH. Давайте посмотрим, что представляет собой каждый из этих протоколов прямой трансляции, их преимущества и применение. А чтобы помочь вам выбрать тот, который подходит именно вам, в конце этой статьи приведено краткое сравнение.
Secure Reliable Transport (SRT)
SRT – восходящая звезда потоковой передачи. Протокол обеспечивает высокое качество видео и аудио с низкой задержкой по ненадёжному общедоступному Интернету. Фактически вы можете контролировать величину задержки и устранять такие проблемы, как дрожание из-за потери пакетов в плохих сетях. SRT также упрощает обход файерволов без помощи IT-специалиста, а также экономичен при развёртывании в существующей сетевой инфраструктуре. Кроме того, SRT предлагает безопасную потоковую передачу с 256-битным шифрованием AES.
SRT – это потоковый протокол с открытым исходным кодом, который набирает популярность благодаря «Альянсу SRT», объединяющему усилия многих лидеров отрасли и разработчиков с целью его продвижения и внедрения. Epiphan Video является сертифицированным членом «Альянса SRT» наряду с YouTube, Akamai, Wowza и другими. SRT включает в себя популярное программное обеспечение, в которое уже встроены OBS Studio, gstreamer и VLC.
Это фактически «технология замены спутника» – низкая стоимость и способность SRT доставлять высококачественный контент через Интернет в режиме, близком к реальному времени, дают вещателям жизнеспособную альтернативу дорогостоящей спутниковой технологии.
Преимущества
Как работает SRT
Между источником SRT (кодер) и получателем SRT (декодер) устанавливается выделенная линия связи для управления и восстановления пакетов. Получателем может быть сервер, CDN или другое устройство SRT. SRT использует свой собственный метод восстановления после потери пакетов, используя UDP-пакеты по сети, которые можно настроить для адаптации к изменяющимся условиям сети. Когда сетевые условия плохие, можно добавить больше буферизации пакетов для улучшения качества видео. По мере улучшения условий в сети величина задержки может быть уменьшена для потоковой передачи практически в реальном времени.
SRT обеспечивает прохождение через любые файерволы между источником и получателем. Для этого протокол имеет три режима: рандеву и вызов/слушатель.
Режим рандеву является самым простым и обычно не требует участия IT-специалистов для настройки прохождения файрволов между источником и получателем SRT. Если вы не можете пройти через сетевой экран, то следует использовать режим вызов/слушатель. Однако для настройки пересылки трафика потребуется определённое участие IT-специалистов, чтобы трафик, полученный на общедоступный IP-адрес и порт устройства-получателя SRT, переадресовывался на устройство в локальной сети.
Применение SRT
SRT идеально подходит для отправки нескольких удалённых каналов новостей по непредсказуемым сетям в центральный пункт назначения для производства и распространения, например, в модели вещания, когда удалённые журналисты сообщают в прямом эфире о местонахождении. Он также отлично подходит для привлечения удалённых гостей с низкой задержкой для интервью или двусторонней беседы. Всякий раз, когда требуется высококачественное видео и аудио по сетям с непредсказуемым качеством, SRT намного превосходит качество любого вызова по Zoom, потока WebEx или WebRTC.
HTTP Live Streaming (HLS)
HLS – это адаптивный протокол потоковой передачи на основе HTTP, который отправляет видео- и аудиоконтент по сети в небольшие сегменты потокового мультимедиа на основе TCP, которые повторно собираются в месте назначения. Стоимость развёртывания HLS является низкой, поскольку она использует существующую сетевую технологию на основе TCP, что является привлекательным для CDN, желающих заменить старые (и дорогие) RTMP-серверы. Но поскольку HLS использует TCP, то он работает по принципу «качество важней задержки», поэтому время задержки может быть высоким (например, в секундах, а не в миллисекундах).
HLS был первоначально разработан Apple Inc. в качестве протокола для потоковой передачи мультимедиа на устройства Apple. С тех пор Apple разработала HLS (push), который является потоковым протоколом открытого стандарта, доступным для всех устройств. В настоящее время HLS поддерживает видео, кодированное с использованием кодеков H.264 или HEVC.
Преимущество HLS заключается в том, что он предназначен для адаптации к различным условиям сети. Разные версии потока отправляются с разными разрешениями и битрейтами. Зрители могут выбрать то качество потока, что они хотят. HLS также поддерживает несколько звуковых дорожек, что означает, что ваш поток может иметь несколько языковых дорожек, из которых пользователи могут выбирать нужную. Другие преимущества включают поддержку скрытых титров, метаданных, управления цифровыми правами (DRM) и даже встроенных рекламных объявлений (в не слишком отдалённом будущем).
Поддерживается безопасная потоковая передача по HTTP, а также алгоритмы хеширования MD5 и SHA для аутентификации имени пользователя и пароля.
Преимущества
Как работает HLS
Подход очень похож на передачу файлов. Сегменты потокового мультимедиа через порт HTTP 80 (или порт 443 для HTTPS), который обычно уже открыт для сетевого трафика. Таким образом, контент может легко проходить через файерволы практически без участия IT-специалистов.
HLS использует контейнер транспортного потока MPEG2-TS с полуконфигурируемой продолжительностью сегмента, а также с настраиваемым размером списка воспроизведения для повторной сборки принятых сегментов на центральном сервере. Также поддерживается фрагментированный MP4.
Поскольку HLS использует технологию, основанную на TCP, метод потери и восстановления сетевых пакетов является интенсивным. Это одна из причин увеличения задержки. Хотя имеется некоторый контроль над размером сегмента мультимедиа, возможность уменьшить задержку ограничена – особенно если сервер требует загрузки среднего сегмента определённого размера.
Применение HLS
HLS по-прежнему является стандартом для потоковой передачи на мобильные устройства и планшеты. Вы также можете использовать HLS для потоковой передачи на CDN, который не поддерживает RTMP, когда низкая задержка не является обязательным требованием. Важно отметить, что RTMP уже считается устаревшим во всё более увеличивающемся количестве CDN. HLS также хорошо подходит для безопасной потоковой передачи корпоративного обучения и трансляций через локальные сети (LAN), когда низкая задержка не является обязательным требованием, а условия сети плохие (при условии, что сеть поддерживает HLS).
MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
MPEG-DASH – это открытый стандарт адаптивного протокола потоковой передачи на основе HTTP, который отправляет видео и аудиоконтент по сети в виде небольших сегментов потокового мультимедиа на основе TCP, которые повторно собираются в месте назначения. Международная организация по стандартизации (ISO) и команда MPEG и MPEG-DASH спроектировали кодирование и разрешение независимо от других, что означает, что MPEG-DASH может передавать потоковое видео (и аудио) любого формата (H.264, H.265 и т. д.) и поддерживает разрешения до 4K. В остальном, MPEG-DASH функционирует почти так же, как и HLS.
Стоимость развёртывания MPEG-DASH низкая, поскольку в нём используется существующая сетевая технология на основе TCP, что является привлекательным для CDN. Но поскольку HLS использует TCP, то он работает по принципу «качество важней задержки», поэтому время задержки может быть высоким
MPEG-DASH также предназначен для адаптации к различным условиям сети. Разные версии потока отправляются с разными разрешениями и битрейтами. Зрители могут выбрать качество потока, который они хотят. Также поддерживаются несколько звуковых дорожек, а также расширенные функции, такие как скрытые титры, метаданные и управление цифровыми правами (DRM). Инфраструктура предназначена для будущих разработок, например, встроенной рекламу.
Поддерживается безопасная потоковая передача по HTTP, а также алгоритмы хеширования MD5 и SHA для аутентификации имени пользователя и пароля.
Преимущества
Как работает MPEG-DASH и его применение
MPEG-DASH работает так же, как HLS – отправляет короткие средние сегменты по HTTP (порт 80) или HTTPS (порт 443) для облегчения обхода файервола. Он использует контейнер транспортного потока MPEG2-TS с половиной настраиваемой длительности сегмента, а также настраиваемый размер списка воспроизведения для повторной сборки принятых сегментов на центральном сервере. Также поддерживается фрагментированный MP4.
Высокая задержка MPEG-DASH обусловлена главным образом потерей сетевых пакетов и методом восстановления, используемым во всех сетях на основе TCP. И хотя MPEG-DASH предлагает некоторый контроль над размером сегмента мультимедиа, возможность уменьшить задержку ограничена – особенно, если сервер требует загрузки среднего сегмента определённого размера.
MPEG-DASH лучше всего подходит для потоковой передачи на CDN, которые не поддерживают RTMP, в случаях, когда низкая задержка не является обязательным требованием. MPEG-DASH также хорошо подходит для безопасной потоковой передачи корпоративного обучения и трансляций через локальные сети (LAN), когда низкая задержка не является обязательным требованием, а условия сети плохие
Какой потоковый протокол подходит вам?
Хотя RTMP, безусловно, всё ещё является самым популярным потоковым протоколом, такие протоколы, как SRT, HLS и MPEG-DASH, бросают ему вызов. Так что они умеют такого, чего не умеет RTMP?
HLS и MPEG-DASH обеспечивают гораздо более простую и дешёвую масштабируемость, чем RTMP. Так как RTMP и обычно требует, чтобы порты были открыты вручную для прохождения через файерволы.
Если задержка или плохие условия сети не являются проблемой, то HLS или MPEG-DASH превосходит SRT. Протоколы адаптивной потоковой передачи на основе HTTP обеспечивают наилучшее возможное качество видео для зрителей с различными условиями сети и более просты в настройке, чем SRT.
Если требуется низкая задержка и вы используете потоковую передачу по сетям с непредсказуемым качеством, тогда SRT является предпочтительным протоколом потоковой передачи. SRT устанавливает свое собственное соединение для восстановления пакетов, которое намного эффективнее, чем TCP. Это позволяет SRT обеспечивать двустороннюю связь между хостом и удалёнными гостями в режиме практически реального времени. Вы также можете сами настроить задержку, чтобы приспособиться к условиям сети.
Заверните!
Многие CDN, такие, например, как Akamai, уже объявили о прекращении поддержки RTMP, как устаревшего и дорогого для развёртывания. С ростом популярности новых протоколов SRT, HLS и MPEG-DASH, RTMP вскоре уйдёт в прошлое. Вот почему мы в Epiphan Video, добавили поддержку SRT, HLS и MPEG-DASH в наше семейство систем видеопроизводства «все-в-одном» Pearl.
Теперь вы можете быть уверены, что Pearl Nano и Pearl Mini готовы к будущему потокового вещания. Семейство кодеров Pearl является одним из немногих устройств в своём ценовом диапазоне, которые сертифицированы для потоковой передачи HLS и MPEG-DASH на Akamai.
Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)
Нередко клиенты спрашивают, умеет ли наш сервер «mp4-стриминг в HTML5». В 99% случаев спрашивающий не понимает о чём говорит. В этом сложно винить клиентов: из-за путаницы с терминами, технической сложности и большого разнообразия вариантов стриминга запутаться очень легко.
В этой статье мы расскажем, какой бывает HTML5-стриминг, какие варианты хорошие, и почему, чёрт побери, нельзя говорить «mp4-стриминг».
▍Термины
HTML5-видео — это когда вы вставляете в веб-страницу тег и указываете ему какой-то src. HTML5-стриминг — это то же HTML5-видео, но когда в src не готовый файл, а постоянно обновляющийся видеопоток. Ролик на Ютубе — это HTML5-видео, трансляция в Твитче — HTML5-стриминг.
Тегу неважно, как видеопоток формируется и передаётся, и сможет ли браузер его проиграть. Главное, чтобы в src была ссылка на какой-то видеопоток. Говоря техническим языком, спецификация ничего не говорит о том, какие протоколы, транспорты и кодеки поддерживаются в HTML5-видео.
Протокол — это то, как два участника видеосвязи (почти всегда это клиент и сервер) обмениваются данными с целью получения данных. Клиентом называют того, кто приходит к серверу и инициирует сессию связи. Видеопоток может течь от сервера к клиенту (тогда это обычное проигрывание) или от клиента к серверу (тогда это публикация). Даже когда гигантский шкаф, жрущий электричество как многоквартирный дом приходит к маленькой IP-камере, то она будет сервером, а этот шкаф клиентом.
Протокол обычно подразумевает хотя бы команду Play (начать проигрывание), но иногда есть и расширенные варианты: пауза, продолжение, публикация, перемотка и т. п.
Примеры протоколов: RTSP, RTMP, HTTP, HLS, IGMP.
Транспорт, или транспортный контейнер, или контейнер — это то, как сжатое видео упаковывается в байты для передачи от одного участника к другому (по какому-то протоколу).
Примеры контейнеров: MPEG-TS, RTMP, RTP.
| Обратите внимание, что RTMP оказался и в протоколах, и в транспортах. Это потому, что в описании RTMP есть спецификация и того, что должны слать друг другу стороны, чтобы видео потекло (т. е. протокол), и того, как упаковывать видео (т. е. транспорт). Так бывает не всегда. Например в протоколе RTSP видео упаковывается в транспорт RTP. |
Кодек — многозначный термин. Здесь он означает способ сжать сырое видео. Разница между кодеком и транспортом в том, что кодек — это про подготовку видео, а транспорт — про передачу видео по протоколу. Видео, сжатое одним кодеком, можно пересылать по разными протоколам и разными транспортами. Большинство видеостриминговых серверов не залезают глубже кодированного видео и оперируют только протоколами и транспортами.
Примеры кодеков: h264, aac, mp3.
| Из-за того, что термин многозначный, возникает путаница с названиями. Например, H.264 — это стандарт того, как упаковать поток огромных сырых видеокадров в очень мало байтов, libx264 — это библиотека для сжатия по этому стандарту, а ещё есть одноимённый софт под Винду, который умеет декодировать h264 и проигрывать его на экране. |
Итак, в спецификации HTML5 не описаны протоколы, транспорты и кодеки. Поэтому авторы браузеров сами выбирают, что поддерживать, а под «HTML5-стримингом» подразумевают разные вещи.
При этом есть комбинации, которые поддерживаются значительной частью браузеров. Рассмотрим самые перспективные.
HLS — это h264-видео и aac- или mp3-аудио, упакованное в транспорт MPEG-TS. Поток разбивается на сегменты, описанные в m3u8-плейлистах, и раздается по HTTP. HLS поддерживает мультибитрейтные потоки, Live/VOD. Вариант очень простой, но в то же время имеет много деталей, из-за чего на разных устройствах работает по-разному.
Разработали HLS в Эппле, поэтому изначально он работал только в Сафари на iOS и MacOS. Даже Сафари на Windows не умел играть HLS (когда еще была версия под Win).
Тем не менее, сейчас HLS умеют проигрывать все телевизионные приставки и даже почти все устройства на Андроиде.
Но не всё гладко. Производители сторонних плееров плюнули на стандарт Эппла в части донесения разных аудиодорожек и добавили проигрывание всего что есть в обычном MPEG-TS: mpeg2 video, mpeg2 audio и т. п. Из-за этого приходится отдавать разные форматы плейлистов для разных плееров.
▍MPEG-DASH
MPEG-DASH — обычно это h264/h265-видео и aac-аудио, упакованное в транспорт mp4, или vp8/vp9, упакованное в WebM, хотя стандарт и не привязан к конкретным кодекам, протоколам и транспортам. Как и в HLS, поток может разбиваться на сегменты, но это необязательно. Вместо плейлистов — MPD-манифест в XML.
MPEG-DASH во многом похож на HLS. Возможно, он даже популярнее, ведь такие гиганты как Ютуб и Нетфликс уже несколько лет используют его как основной способ раздачи контента.
MPEG-DASH хорош тем, что в большинстве браузеров работает нативно, через MSE (о том, что это такое, — чуть ниже). Для него даже нет реализации на Флеше — это честный, бескомпромиссный HTML5.
Определенно, MPEG-DASH — самый настоящий HTML5-стриминг, за ним будущее.
Когда стало ясно, что Флеш всё-таки умрёт (после сотни ложных похорон), ребром встал вопрос о том, что придёт ему на смену. Хорошо было бы получить в браузерах возможность проигрывать видео по качеству и удобству близко к тому, что умеет Флеш (а он это делает всё-таки хорошо).
Во Флеше давно появился очень удобный механизм для универсального проигрывания разных вариантов — appendBytes. Суть в том, что пользовательский код сам как хочет скачивает кадры сжатого видео, упаковывает в оговоренный контейнер (с Флешем это flv) и засовывает в видеопроигрыватель. Т. е. протокол и транспорт реализуются в пользовательском коде, запускаемом в браузере.
MSE (Media Sources Extensions) — это расширение спецификации HTML5, которое позволяет делать то же, что делает appendBytes во Флеше. К сожалению, MSE намного сложнее как в понимании, так и в реализации.
MPEG-DASH, созданный на его базе, ещё хитрее, поэтому работать с ними то ещё удовольствие: тонны XML, парсинг бинарных контейнеров в Яваскрипте, непродуманные на этапе дизайна вопросы нарезки на сегменты — всё как мы любим, всё что нужно для единой безглючной реализации во всех браузерах.
Интересно, что MSE работает не только с MPEG-DASH, но и с HLS. Существует реализация hls.js, которая скачивает HLS-плейлисты, скачивает MPEG-TS-сегменты, перепаковывает их в нужный для MSE формат и играет через MSE. Эппл даже сделала шаг в сторону совместимости с MPEG-DASH — использование mp4-контейнеров в HLS.
К концу 2017 года Флеш скорее всего умрёт окончательно, и уже сегодня можно смело начинать проект с MPEG-DASH.
▍WebRTC
Во Флеше была сделана годная попытка в одной технологии реализовать и риалтайм-общение, и массовый броадкастинг. К сожалению, в HTML5 так не вышло. Для просмотра трансляций у нас есть MSE, а для видеозвонков — WebRTC.
WebRTC — это SIP в браузере: способ организовать аудио- и видеоканал и канал данных между двумя браузерами при посредничестве сервера.
Технология не предназначена для стриминга, но в принципе может и его, так что было бы неправильно забыть про него. WebRTC тоже считается HTML5, потому что вроде как ничего кроме Яваскрипта в браузере не требует. Зато требует наличия последних версий обоих популярных браузеров, а с Эджем пока вообще не совместимо.
Путаницу в понимании WebRTC вносит его использование в торрент-доставке телевидения. Суть в том, что браузеры через WebRTC организуют сеть каналов данных, а дальше по этой сети раздаются HLS- или MSE-сегменты видео, а проигрывание происходит через Флеш или MSE. Т. е. WebRTC — для доставки, MSE — для проигрывания. Важно не путать это с использованием WebRTC для проигрывания видео.
▍Так что там с mp4-стримингом?
Любой современный браузер скорее всего сможет по протоколу HTTP запросить файл, упакованный в транспорт mp4 и содержащий внутри видео, сжатое кодеком h264/aac. И даже попытаться проиграть его. Это самый удобный, понятный и стандартный вариант проигрывания файлов. Лежит себе файлик на диске, nginx его отдает. Код, проигрывающий mp4 в браузерах достаточно хорош. Например, он умеет даже скачивать куски видео по необходимости (в отличие от Флеш-плеера, который скачивает видео целиком).
Вокруг h264 сложилось немало шумихи по поводу его «закрытости» и «несвободности». Так что есть «открытая» альтернатива, которую форсит Гугл — видеокодеки vp8 и vp9, упакованные в транспорт WebM. WebM — это подмножество транспорта mkv (a. k. a. Матрёшка), который очень похож на mp4 по сути, но отличается от него своей «бинарностью».
Именно отсюда растут ноги у такого явления как «mp4-стриминг», который устроен как WebM. Дело в том что в обычном mp4 в самом начале указывается размер всего контейнера. Поэтому, если мы хотим отдать по обычному mp4 прямой эфир, у нас ничего не получится. А чтобы всё-таки получилось и можно было создавать mp4 без фиксированного конца, придуман следующий ход: сначала пишется mp4 без кадров, а потом в конце подписываются блоками по несколько секунд фрагменты с кадрами. Это называется mp4 fragmented, или mp4 streaming.
По сути это никакой не стриминг, а костыль, позволяющий создать его видимость. Mp4 — отличный формат для скачивания видео, но негодный для стриминга, так что про него можно просто забыть и никогда не использовать термин «mp4-стриминг».
Mpeg dash что это
MPEG DASH (Dynamic Adaptive Streaming over HTTP – динамический адаптивный стриминг по HTTP) это международный стандарт, ратифицированный MPEG и ISO.
Основная идея MPEG-DASH заключается в следующем: нарезать контент на сегменты (чанки-chunks) и предоставить возможность их получения с различными битрейтами и разрешениями. На рисунке ниже показан пример, где на HTTP-сервере мы имеем сегменты одинаковой длины в трёх различных качествах видео Low (низкое), Medium (среднее) и Best (лучшее), соответственно с различными битрейтами.
Адаптация к битрейту или разрешению видео выполняется на стороне клиента. Он может переключаться на более высокую битрейт – если позволяет пропускная способность. Это имеет несколько преимуществ, потому что клиентское устройство лучше знает свои возможности, доступную пропускную способность и опыт пользователя.
Чтобы описать временные и структурные отношения между сегментами, в MPEG-DASH введен так называемый MPD (Media Presentation Description) файл описания представления медиа. MPD представляет собой XML-файл, в котором указаны ссылки на различные качества медиа-контента с помощью HTTP URL (Uniform Resource Locators). Эта структура обеспечивает привязку сегментов к битрейту, разрешению, времени начала, длительности.
В результате, каждый клиент сначала запрашивает MPD, получая тем самым временную и структурную информацию о контенте, и уже на основе этой информации запрашивает отдельные сегменты для воспроизведения, которые в большей степени соответствуют возможностям и требованиям.
