✖


Jump to content

Потоковая передача с адаптивным битрейтом

(Перенаправлено из протокола Microsoft Smooth Streaming )

Обзор адаптивной потоковой передачи
Адаптивная потоковая передача в действии

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

В то время как в прошлом большинство технологий потоковой передачи видео или аудио использовали протоколы потоковой передачи, такие как RTP с RTSP , сегодняшние технологии адаптивной потоковой передачи основаны почти исключительно на HTTP . [1] и предназначены для эффективной работы в крупных распределенных сетях HTTP.

пользователя Потоковая передача с адаптивным битрейтом работает путем определения пропускной способности и мощности процессора в режиме реального времени и соответствующим образом регулирует качество медиапотока. [2] Для этого требуется использование кодера , который кодирует один исходный носитель (видео или аудио) с разными скоростями передачи данных . Клиент игрока [3] переключается между потоковой передачей различных кодировок в зависимости от доступных ресурсов. [4] В результате обеспечивается очень небольшая буферизация , более быстрое время запуска и удобство работы как для высокопроизводительных, так и для низкопроизводительных соединений. [5]

Более конкретно, потоковая передача с адаптивным битрейтом — это метод потоковой передачи видео через HTTP, при котором исходный контент кодируется с разными скоростями передачи данных. Каждый из потоков с различной скоростью передачи данных сегментируется на небольшие многосекундные части. [6] Размер сегмента может варьироваться в зависимости от конкретной реализации, но обычно он составляет от двух до десяти секунд. [4] [6] Сначала клиент загружает файл манифеста , который описывает доступные сегменты потока и соответствующие им скорости передачи данных. Во время запуска потока клиент обычно запрашивает сегменты из потока с самой низкой скоростью передачи данных. Если клиент обнаружит, что пропускная способность сети превышает скорость передачи загруженного сегмента, он запросит сегмент с более высокой скоростью передачи данных. Позже, если клиент обнаружит, что пропускная способность сети ухудшилась, он запросит сегмент с более низкой скоростью передачи данных. Алгоритм адаптивного битрейта (ABR) в клиенте выполняет ключевую функцию принятия решения о том, какие сегменты битрейта загружать, на основе текущего состояния сети. Несколько типов алгоритмов ABR используются в коммерческих целях: алгоритмы на основе пропускной способности используют для принятия решений пропускную способность, достигнутую в ходе последних предыдущих загрузок (например, правило пропускной способности в Dash.js ), алгоритмы на основе буфера используют только текущий уровень буфера клиента (например, , БОЛА [7] в Dash.js ), а гибридные алгоритмы объединяют оба типа информации (например, DYNAMIC [8] в Dash.js ).

Текущее использование

[ редактировать ]

Пост-продакшн , сети доставки контента и студии используют технологию адаптивной скорости передачи данных, чтобы предоставить потребителям видео более высокого качества, используя меньше рабочей силы и ресурсов. Создание нескольких видеовыходов, особенно для потоковой передачи с адаптивной скоростью передачи данных, представляет большую ценность для потребителей. [9] Если технология работает правильно, контент конечного пользователя или потребителя должен воспроизводиться без перерывов и потенциально остаться незамеченным. Медиакомпании уже много лет активно используют технологию адаптивной скорости передачи данных, и это, по сути, стало стандартной практикой для провайдеров потокового вещания высокого класса; разрешение небольшой буферизации при потоковой передаче каналов с высоким разрешением (начинается с низкого разрешения и поднимается вверх).

Преимущества потоковой передачи с адаптивным битрейтом

[ редактировать ]

Традиционная потоковая передача с адаптивным битрейтом, управляемая сервером, предоставляет потребителям потокового мультимедиа наилучшие возможности, поскольку медиасервер автоматически адаптируется к любым изменениям в сети каждого пользователя и условиям воспроизведения. [10] Индустрия СМИ и развлечений также получает выгоду от потоковой передачи с адаптивным битрейтом. По мере роста видеопространства сети доставки контента и видеопровайдеры могут предоставить клиентам превосходные впечатления от просмотра. Технология адаптивного битрейта требует дополнительного кодирования , но упрощает общий рабочий процесс и дает лучшие результаты.

Технологии потоковой передачи с адаптивным битрейтом на основе HTTP дают дополнительные преимущества по сравнению с традиционной потоковой передачей с адаптивным битрейтом, управляемой сервером. Во-первых, поскольку технология потоковой передачи построена на базе HTTP , в отличие от адаптивной потоковой передачи на основе RTP , пакеты без проблем проходят через межсетевой экран и устройства NAT . Во-вторых, поскольку потоковая передача HTTP управляется исключительно клиентом, вся логика адаптации находится на клиенте. Это снижает потребность в постоянных соединениях между сервером и клиентским приложением. Более того, серверу не требуется хранить информацию о состоянии сеанса на каждом клиенте, что повышает масштабируемость. Наконец, можно легко адаптировать существующую инфраструктуру доставки HTTP, такую ​​как HTTP-кэши и серверы. [11] [12] [13] [14]

Масштабируемая CDN используется для доставки потокового мультимедиа интернет-аудитории. CDN получает поток от источника на своем исходном сервере, а затем реплицирует его на многие или все свои пограничные кэш-серверы . Конечный пользователь запрашивает поток и перенаправляется на «ближайший» пограничный сервер. Это можно проверить с помощью libdash [15] и набор данных Distributed DASH (D-DASH), [16] которая имеет несколько зеркал в Европе, Азии и США. Использование адаптивной потоковой передачи на основе HTTP позволяет пограничному серверу запускать простое программное обеспечение HTTP-сервера, стоимость лицензии которого дешевая или бесплатная, что снижает стоимость лицензирования программного обеспечения по сравнению с дорогостоящими лицензиями медиасервера (например, Adobe Flash Media Streaming Server). Стоимость CDN для потокового мультимедиа HTTP в этом случае аналогична стоимости CDN веб-кэширования HTTP.

История

[ редактировать ]

Адаптивная скорость передачи данных через HTTP была создана DVD Forum в группе WG1 Special Streaming в октябре 2002 года. Сопредседателями группы выступили Toshiba и Phoenix Technologies . Экспертная группа рассчитывает при сотрудничестве Microsoft , Apple Computer , DTS Inc. , Warner Brothers , 20th Century Fox , Digital Deluxe , Disney , Macromedia и Akamai . [ сомнительно – обсудить ] [ нужна ссылка ] Первоначально технология называлась DVDoverIP и была неотъемлемой частью книги DVD ENAV. [17] Идея возникла из хранения секторов DVD TS MPEG-1 и MPEG-2 в небольших файлах размером 2 КБ, которые будут передаваться плееру с помощью HTTP-сервера. Сегменты MPEG-1 обеспечивали поток с более низкой полосой пропускания, тогда как MPEG-2 обеспечивал поток с более высокой скоростью передачи данных. Исходная схема XML предоставляла простой список воспроизведения со скоростью передачи данных, языками и серверами URL. Первый рабочий прототип был представлен на DVD-форуме компанией Phoenix Technologies в лаборатории Harman Kardon в Филлингене, Германия. [ нужна ссылка ]

Реализации

[ редактировать ]

Потоковая передача с адаптивной скоростью передачи данных была представлена ​​компанией Move Networks в 2006 году. [18] и в настоящее время разрабатывается и используется Adobe Systems , Apple , Microsoft и Octoshape . [19] В октябре 2010 года компания Move Networks получила патент на потоковую передачу с адаптивной скоростью передачи данных (патент США № 7818444). [20]

Динамическая адаптивная потоковая передача через HTTP (DASH)

[ редактировать ]
Основная статья: Динамическая адаптивная потоковая передача через HTTP

Динамическая адаптивная потоковая передача через HTTP (DASH), также известная как MPEG-DASH, является единственным решением потоковой передачи на основе HTTP с адаптивной скоростью передачи данных, которое является международным стандартом. [21] Технология MPEG-DASH была разработана в рамках MPEG . Работа над DASH началась в 2010 году и стала проектом международного стандарта в январе 2011 года и международным стандартом в ноябре 2011 года. [21] [22] [23] Стандарт MPEG-DASH был опубликован как ISO/IEC 23009-1:2012 в апреле 2012 года.

MPEG-DASH — это технология, связанная с Adobe Systems HTTP Dynamic Streaming , Apple Inc. HTTP Live Streaming (HLS) и Microsoft Smooth Streaming . [24] DASH основан на адаптивной потоковой передаче HTTP (AHS) в версии 9 3GPP и на адаптивной потоковой передаче HTTP (HAS) в Open IPTV Forum . версии 2 [25] В рамках сотрудничества с MPEG компания 3GPP Release 10 приняла DASH (с определенными кодеками и режимами работы) для использования в беспроводных сетях. [25]

Цель стандартизации решения адаптивной потоковой передачи — убедить рынок в том, что это решение может работать универсально, в отличие от других решений, более специфичных для определенных поставщиков, таких как HLS от Apple, Smooth Streaming от Microsoft или HDS от Adobe.

на базе HTML5. Bitdash Доступные реализации: проигрыватель MPEG-DASH [26] а также библиотеку клиентского доступа DASH с открытым исходным кодом libdash от bitmovin GmbH, основанную на C++, [15] инструменты DASH Института информационных технологий (ITEC) Университета Альпен-Адрия в Клагенфурте, [3] [27] мультимедийная структура группы GPAC в Telecom ParisTech, [28] и Dash.js [29] игрок DASH-IF .

Прямая потоковая передача Apple HTTP (HLS)

[ редактировать ]
Основная статья: Прямая трансляция HTTP

HTTP Live Streaming (HLS) — это протокол передачи потокового мультимедиа на основе HTTP, реализованный Apple Inc. как часть QuickTime X и iOS . HLS поддерживает как прямой эфир, так и видео по запросу . Он работает путем разбиения медиапотоков или файлов на короткие фрагменты (медиасегменты), которые сохраняются в виде файлов MPEG-TS или фрагментированных файлов MP4. Обычно это делается при нескольких битрейтах с использованием приложения сегментатора потока или файла, также известного как упаковщик. Одна из таких реализаций сегментатора предоставлена ​​Apple. [30] Доступны дополнительные упаковщики, в том числе бесплатные предложения с открытым исходным кодом, такие как Shaka Packager от Google. [31] а также различные коммерческие инструменты, такие как Unified Streaming. [32] Сегментатор также отвечает за создание набора файлов списков воспроизведения в формате M3U8, которые описывают медиа-фрагменты. Каждый список воспроизведения привязан к определенному битрейту и содержит относительные или абсолютные URL-адреса фрагментов для этого битрейта. Затем клиент несет ответственность за запрос соответствующего списка воспроизведения в зависимости от доступной пропускной способности.

HTTP Live Streaming — стандартная функция iPhone 3.0 и более поздних версий. [33]

Apple представила свое решение на рассмотрение IETF в виде информационного запроса на комментарии . [34] Это было официально принято как RFC   8216 Существует ряд проприетарных решений и решений с открытым исходным кодом как для реализации сервера (сегментатор), так и для клиентского проигрывателя.

Потоки HLS можно идентифицировать по расширению формата URL-адреса списка воспроизведения: m3u8 или MIME-тип приложения/vnd.apple.mpegurl. [35] Эти адаптивные потоки могут быть доступны с разными скоростями передачи данных, и клиентское устройство взаимодействует с сервером, чтобы получить наилучшую доступную скорость передачи данных, которая может быть надежно доставлена.

Воспроизведение HLS поддерживается на многих платформах, включая Safari и собственные приложения для macOS/iOS, Microsoft Edge в Windows 10, ExoPlayer для Android и платформу Roku. Многие смарт-телевизоры также имеют встроенную поддержку HLS. Воспроизведение HLS на других платформах, таких как Chrome/Firefox, обычно достигается с помощью реализации проигрывателя браузера/JavaScript. Доступно множество проигрывателей с открытым исходным кодом и коммерческих проигрывателей, включая hls.js, http-streaming video.js, BitMovin, JWPlayer, THEOplayer и т. д.

Динамическая потоковая передача Adobe HTTP (HDS)

[ редактировать ]

«HTTP Динамическая потоковая передача — это процесс эффективной доставки потокового видео пользователям путем динамического переключения между различными потоками различного качества и размера во время воспроизведения. Это обеспечивает пользователям наилучшие впечатления от просмотра, которые их полоса пропускания и локальное компьютерное оборудование ( ЦП может поддерживать ). Еще Основная цель динамической потоковой передачи — сделать этот процесс плавным и плавным для пользователей, чтобы в случае необходимости повышения или понижения качества потока это было плавное и почти незаметное переключение, не нарушающее непрерывное воспроизведение». [36]

Последние версии Flash Player и Flash Media Server поддерживают потоковую передачу с адаптивной скоростью передачи данных по традиционному протоколу RTMP , а также HTTP , аналогично решениям на основе HTTP от Apple и Microsoft. [37] Динамическая потоковая передача HTTP поддерживается в Flash Player 10.1 и более поздних версиях. [38] Преимущество потоковой передачи на основе HTTP заключается в том, что не требуется открывать какие-либо порты брандмауэра, кроме обычных портов, используемых веб-браузерами. Потоковая передача на основе HTTP также позволяет кэшировать фрагменты видео браузерами , прокси-серверами и CDN , что значительно снижает нагрузку на исходный сервер.

Microsoft Smooth Streaming (MSS)

[ редактировать ]

Smooth Streaming — это расширение IIS Media Services , которое обеспечивает адаптивную потоковую передачу мультимедиа клиентам через HTTP. [39] Спецификация формата основана на базовом формате мультимедийных файлов ISO и стандартизирована Microsoft как защищенный совместимый формат файлов. [40] Microsoft активно участвует в 3GPP , MPEG и DECE усилиях организаций по стандартизации потоковой передачи HTTP с адаптивной скоростью передачи данных. Microsoft предоставляет комплекты разработки программного обеспечения Smooth Streaming Client для Silverlight и Windows Phone 7 , а также комплект Smooth Streaming Porting Kit, который можно использовать для других клиентских операционных систем, таких как Apple iOS, Android и Linux. [41] В службах IIS Media Services 4.0, выпущенных в ноябре 2010 года, появилась функция, которая позволяет динамически переупаковывать видео Live Smooth Streaming H.264/AAC в формат Apple HTTP Adaptive Streaming и доставлять их на устройства iOS без необходимости повторного кодирования.Microsoft успешно продемонстрировала доставку HD-видео 1080p в реальном времени и по запросу с помощью Smooth Streaming для клиентов Silverlight. В 2010 году Microsoft также в партнерстве с NVIDIA продемонстрировала потоковую передачу стереоскопического 3D-видео 1080p на ПК, оснащенные технологией NVIDIA 3D Vision . [42]

Общий формат мультимедийных приложений (CMAF)

[ редактировать ]

CMAF — это формат контейнера презентаций, используемый для доставки как HLS, так и MPEG-DASH. Следовательно, он предназначен для упрощения доставки потокового мультимедиа на основе HTTP. Он был предложен в 2016 году Apple и Microsoft и официально опубликован в 2018 году. [43]

Адаптивная потоковая передача QuavStreams через HTTP

[ редактировать ]

QuavStreams Adaptive Streaming — это технология потоковой передачи мультимедиа, разработанная Quavlive. Сервер потоковой передачи — это HTTP-сервер, который имеет несколько версий каждого видео, закодированных с разными битрейтами и разрешениями. Сервер доставляет закодированные видео/аудиокадры, переключаясь с одного уровня на другой в соответствии с текущей доступной полосой пропускания. Управление полностью серверное, поэтому клиенту не нужны специальные дополнительные возможности. В управлении потоковой передачей используется теория управления с обратной связью. [44] В настоящее время QuavStreams поддерживает кодеки H.264/MP3, мультиплексированные в контейнер FLV, и кодеки VP8/Vorbis, мультиплексированные в контейнер WEBM.

восходящая линия связи

[ редактировать ]

Uplynk обеспечивает потоковую передачу HD с адаптивным битрейтом на несколько платформ, включая iOS, Android, Windows Mac, Linux и Roku, в различных комбинациях браузеров, кодируя видео в облаке с использованием единого незапатентованного формата адаптивной потоковой передачи. Вместо потоковой передачи и хранения нескольких форматов для разных платформ и устройств, Uplynk хранит и передает только один. Первой студией, которая использовала эту технологию для доставки, была Disney–ABC Television Group , которая использовала ее для кодирования видео для веб-приложений, мобильных и планшетных потоковых приложений в приложениях ABC Player, ABC Family и Watch Disney, а также в прямом эфире канала Watch Disney Channel. Посмотрите Disney Junior и посмотрите Disney XD. [45] [46]

Самообучающиеся клиенты

[ редактировать ]

В последние годы преимущества алгоритмов самообучения в потоковой передаче с адаптивным битрейтом исследовались в научных кругах. Хотя большинство первоначальных подходов к самообучению реализованы на стороне сервера [47] [48] [49] (например, выполнение контроля доступа с использованием обучения с подкреплением или искусственных нейронных сетей ), более поздние исследования сосредоточены на разработке самообучающихся клиентов HTTP Adaptive Streaming. В литературе было представлено несколько подходов с использованием SARSA. [50] или Q-обучение [51] алгоритм. Во всех этих подходах состояние клиента моделируется с использованием, среди прочего, информации о текущей воспринимаемой пропускной способности сети и уровне заполнения буфера. На основе этой информации самообучающийся клиент самостоятельно решает, какой уровень качества выбрать для следующего сегмента видео. Процесс обучения управляется с использованием информации обратной связи, представляющей качество опыта (QoE) (например, на основе уровня качества, количества переключений и количества зависаний видео). Кроме того, было показано, что многоагентное Q-обучение может применяться для повышения справедливости QoE среди нескольких клиентов адаптивной потоковой передачи. [52]

Критика

[ редактировать ]

Технологии адаптивной скорости передачи данных на основе HTTP значительно более сложны в эксплуатации, чем традиционные технологии потоковой передачи. Некоторые из задокументированных соображений включают такие вещи, как дополнительные затраты на хранение и кодирование, а также проблемы с поддержанием качества во всем мире. Также была обнаружена интересная динамика взаимодействия между сложной логикой адаптивной скорости передачи данных, конкурирующей со сложной логикой управления потоком TCP. [11] [53] [54] [55] [56]

Однако на практике эта критика перевешивается экономичностью и масштабируемостью доставки HTTP: в то время как решения потоковой передачи, отличные от HTTP, требуют массового развертывания специализированной инфраструктуры серверов потоковой передачи, потоковая передача с адаптивной скоростью передачи данных на основе HTTP может использовать те же веб-серверы HTTP, которые используются для доставлять весь остальной контент через Интернет. [ нужна ссылка ]

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

Метод сегментации файлов на более мелкие файлы, используемый в некоторых реализациях (как, например, в HTTP Live Streaming ), может считаться ненужным из-за способности HTTP-клиентов запрашивать диапазоны байтов из одного файла видеоресурса, который может иметь несколько видеодорожек с разными битами. скорости, при этом в файле манифеста указывается только номер дорожки и скорость передачи данных. Однако этот подход позволяет обслуживать фрагменты любым простым HTTP-сервером и, следовательно, гарантирует совместимость с CDN . Реализации, использующие диапазоны байтов, такие как Microsoft Smooth Streaming, требуют выделенного HTTP-сервера, такого как IIS, для ответа на запросы фрагментов видеоресурсов.

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Саамер Ахшаби; Али К. Беген; Константин Довролис (2011). Экспериментальная оценка алгоритмов адаптации скорости в адаптивной потоковой передаче через HTTP . В материалах второй ежегодной конференции ACM по мультимедийным системам (MMSys '11). Нью-Йорк, штат Нью-Йорк, США: ACM.
  2. ^ А. Бенталеб, Б. Таани, А. Беген, К. Тиммермер и Р. Циммерманн, «Обзор схем адаптации битрейта для потокового мультимедиа через HTTP», в IEEE Communications Surveys & (IEEE COMST), Vol, стр. 101-1 1-1,
  3. ^ Jump up to: а б DASH в ITEC, плагин VLC, DASHEncoder и набор данных К. Мюллера, С. Ледерера, К. Тиммерера
  4. ^ Jump up to: а б «Шаблон протокола – WORD» (PDF) . Проверено 16 декабря 2017 г.
  5. ^ Ганнес, Лиз (10 июня 2009 г.). «Следующее большое событие в видео: потоковая передача с адаптивным битрейтом» . Архивировано из оригинала 19 июня 2010 года . Проверено 1 июня 2010 г.
  6. ^ Jump up to: а б «mmsys2012-final36.pdf» (PDF) . Проверено 16 декабря 2017 г.
  7. ^ Спитери, Кевин; Ургаонкар, Рахул; Ситараман, Рамеш К. (2016). «BOLA: адаптация битрейта, близкая к оптимальному, для онлайн-видео. IEEE INFOCOM, 2016 г., Спитери, Ургаонкар и Ситараман, IEEE INFOCOM, апрель 2016 г.». arXiv : 1601.06748 . дои : 10.1109/TNET.2020.2996964 . S2CID   219792107 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  8. ^ «От теории к практике: улучшение адаптации битрейта в эталонном проигрывателе DASH, Спитери, Ситарамаман и Спарацио, конференция ACM Multimedia Systems, июнь 2018 г.» (PDF) .
  9. ^ Маршалл, Дэниел (18 февраля 2010 г.). «Отчет о выставке: обработка видео, критически важная для управления цифровыми активами» . Элементальные технологии. Архивировано из оригинала 4 октября 2011 года . Проверено 15 октября 2011 г.
  10. ^ Зойферт, Майкл; Эггер, Себастьян; Сланина, Мартин; Зиннер, Томас; Хоссфельд, Тобиас; Тран-Гиа, Фуок (2015). «Опрос качества работы адаптивной потоковой передачи HTTP» . Опросы и учебные пособия IEEE по коммуникациям . 17 (1): 469–492. дои : 10.1109/COMST.2014.2360940 . S2CID   18220375 .
  11. ^ Jump up to: а б Саамер Ахшаби; Али К. Беген; Константин Довролис. «Экспериментальная оценка алгоритмов адаптации скорости в адаптивной потоковой передаче через HTTP» (PDF) . Архивировано из оригинала (PDF) 17 октября 2011 года . Проверено 15 октября 2011 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  12. ^ Энтони Ветро. «Стандарт MPEG-DASH для потоковой передачи мультимедиа через Интернет» (PDF) . Проверено 10 июля 2015 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  13. ^ Ян Озер (28 апреля 2011 г.). «Что такое адаптивная потоковая передача?» . Проверено 10 июля 2015 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  14. ^ Йерун Фамаи; Стивен Латре; Нильс Бутен; Вим Ван де Меерше; Барт де Влишаувер; Вернер Ван Ликвейк; Филип Де Турк (май 2013 г.). «О достоинствах адаптивной потоковой передачи HTTP на основе SVC» : 419–426 . Проверено 10 июля 2015 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  15. ^ Jump up to: а б libdash: клиентская библиотека DASH с открытым исходным кодом от bitmovin.
  16. ^ «Распределенный набор данных DASH | ITEC – динамическая адаптивная потоковая передача через HTTP» . Itec.uni-klu.ac.at . Проверено 16 декабря 2017 г.
  17. ^ DVD Book Construction , DVD Forum, май 2005 г.
  18. ^ Ян, Хонгюн (2014). «Возможности и проблемы адаптивной потоковой передачи HTTP» (PDF) . Международный журнал коммуникаций и сетей будущего поколения . 7 (6): 165–180.
  19. ^ Ганнес, Лиз (10 июня 2009 г.). «Подробнее о потоковой передаче HTTP с адаптивным битрейтом от Apple» . Архивировано из оригинала 19 июня 2010 года . Проверено 24 июня 2010 г.
  20. ^ «Move получает патент на потоковую передачу; Adobe и Apple находятся под угрозой? – Новости онлайн-видео» . Гигаом.com. 15 сентября 2010 года. Архивировано из оригинала 22 октября 2011 года . Проверено 15 октября 2011 г.
  21. ^ Jump up to: а б «MPEG ратифицирует проект стандарта для DASH» . МПЕГ. 2 декабря 2011 года. Архивировано из оригинала 20 августа 2012 года . Проверено 26 августа 2012 г.
  22. ^ Тиммерер, Кристиан (26 апреля 2012 г.). «HTTP-потоковая передача мультимедиа в формате MPEG – запись в блоге» . Multimediacommunication.blogspot.com . Проверено 16 декабря 2017 г.
  23. ^ «ISO/IEC DIS 23009-1.2 Динамическая адаптивная потоковая передача через HTTP (DASH)» . Исо.орг . Проверено 16 декабря 2017 г.
  24. ^ Обновления DASH - запись в блоге.
  25. ^ Jump up to: а б ETSI 3GPP 3GPP TS 26.247; Прозрачная сквозная потоковая служба с коммутацией пакетов (PSS); Прогрессивная загрузка и динамическая адаптивная потоковая передача через HTTP (3GP-DASH)
  26. ^ «bitdash HTML5 MPEG-DASH-проигрыватель» . Dash-player.com. 22 января 2016 года. Архивировано из оригинала 10 июля 2016 года . Проверено 16 декабря 2017 г.
  27. ^ «Плагин медиаплеера VLC, обеспечивающий динамическую адаптивную потоковую передачу через HTTP» (PDF) . Проверено 16 декабря 2017 г.
  28. ^ «GPAC Telecom ParisTech» . Архивировано из оригинала 24 февраля 2012 года . Проверено 28 марта 2013 г.
  29. ^ "dash.js" . Гитхаб.com . Проверено 16 декабря 2017 г.
  30. ^ Библиотека разработчиков Mac , Apple , получено 2 июня 2014 г.
  31. ^ Репозиторий Shaka Packager на Github , Google , получено 3 января 2023 г.
  32. ^ Unified Streaming , Unified Streaming , получено 3 января 2023 г.
  33. ^ Принц Маклин (9 июля 2009 г.). «Apple запускает стандарт HTTP Live Streaming в iPhone 3.0» . AppleInsider . Проверено 15 октября 2011 г.
  34. ^ Р. Пантос, HTTP Live Streaming , IETF , получено 11 октября 2011 г.
  35. ^ РФК 8216 . сек. 4. дои : 10.17487/RFC8216 .
  36. ^ Хассун, Дэвид. «Динамическая потоковая передача в Flash Media Server 3.5 – Часть 1: Обзор новых возможностей» . Связь с разработчиками Adobe . Системы Adobe. Архивировано из оригинала 30 марта 2014 года.
  37. ^ «Динамическая потоковая передача HTTP» . Системы Adobe . Проверено 13 октября 2010 г.
  38. ^ «Часто задаваемые вопросы о динамической потоковой передаче HTTP» . Системы Adobe . Проверено 12 января 2015 г.
  39. ^ «Плавное вещание» . IIS.net. Архивировано из оригинала 15 июня 2010 года . Проверено 24 июня 2010 г.
  40. ^ Крис Ноултон (8 сентября 2009 г.), Защищенный совместимый формат файлов , Microsoft , получено 15 октября 2011 г.
  41. ^ «Комплексная платформа Microsoft обеспечивает работу Silverlight и IIS нового поколения на нескольких экранах» . Майкрософт. 8 апреля 2010 года . Проверено 30 июля 2011 г.
  42. ^ «Первый день МДС» . Майкрософт. Архивировано из оригинала 2 февраля 2011 года . Проверено 22 января 2011 г.
  43. ^ Трейси Рютер (23 января 2019 г.). «Что такое CMAF?» . Проверено 13 января 2022 г.
  44. ^ Лука Де Чикко; Саверио Масколо; Витторио Пальмизано. «Управление обратной связью для адаптивного потокового видео в реальном времени» (PDF) . ММСИС2011 . Проверено 9 сентября 2012 года .
  45. ^ Дин Такахаши (16 января 2013 г.). «Uplynk создает для Disney дешевый и эффективный способ потоковой передачи видео» . ВенчурБит . Проверено 16 декабря 2017 г.
  46. ^ Драйер, Трой (16 января 2013 г.). «UpLynk выходит из скрытого режима; DisneyABC — первый клиент — журнал Streaming Media» . Стримингмедиа.com . Проверено 16 декабря 2017 г.
  47. ^ Ю. Фей; ВВС Вонг; ВКМ Люнг (2006). «Эффективное обеспечение QoS для адаптивного мультимедиа в сетях мобильной связи посредством обучения с подкреплением» . Мобильные сети и приложения . 11 (1): 101–110. CiteSeerX   10.1.1.70.1430 . дои : 10.1007/s11036-005-4464-2 . S2CID   13022779 .
  48. ^ В. Шарвилла; Р. Григорас (2007). «Обучение с подкреплением для динамической мультимедийной адаптации». Журнал сетевых и компьютерных приложений . 30 (3): 1034–1058. дои : 10.1016/j.jnca.2005.12.010 .
  49. ^ Д. У. МакКлари; В.Р. Сиротюк; В. Лекюр (2008). «Адаптивная потоковая передача звука в мобильных одноранговых сетях с использованием нейронных сетей». Специальные сети . 6 (4): 524–538. дои : 10.1016/j.adhoc.2007.04.005 .
  50. ^ В. Меньковский; А. Лиотта (2013). «Интеллектуальное управление адаптивным потоковым видео». Международная конференция IEEE по бытовой электронике (ICCE) . Вашингтон, округ Колумбия. стр. 127–128. дои : 10.1109/ICCE.2013.6486825 .
  51. ^ М. Клейс; С. Латре; Дж. Фамей; Ф. Де Турк (2014). «Проектирование и оценка самообучающегося HTTP-клиента адаптивного потокового видео» . Коммуникационные письма IEEE . 18 (4): 716–719. дои : 10.1109/lcomm.2014.020414.132649 . hdl : 1854/LU-5733061 . S2CID   26955239 .
  52. ^ С. Петранджели; М. Клейс; С. Латре; Дж. Фамей; Ф. Де Турк (2014). «Мультиагентная платформа Q-Learning для достижения справедливости в адаптивной потоковой передаче HTTP». Симпозиум IEEE по сетевым операциям и управлению (NOMS) . Краков. стр. 1–9. дои : 10.1109/NOMS.2014.6838245 .
  53. ^ Пит Мастин (28 января 2011 г.). «Адаптивная скорость передачи данных — это дорога из желтого кирпича или золото дураков для потоковой передачи HD?» . Архивировано из оригинала 7 сентября 2011 года . Проверено 15 октября 2011 г.
  54. ^ Лука Де Чикко; Саверио Масколо. «Экспериментальное исследование адаптивного потокового видео Akamai» (PDF) . Проверено 29 ноября 2011 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  55. ^ «Адаптивный стриминг: сравнение» . Архивировано из оригинала 19 апреля 2014 года . Проверено 17 апреля 2014 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  56. ^ Крис Ноултон (28 января 2010 г.). «Адаптивное сравнение потоков» . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

Дальнейшее чтение

[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Adaptive_bitrate_streaming&oldid=1236993333#Microsoft_Smooth_Streaming_(MSS)"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 60953b3a19d063c211088ecb0f5d00db__1722083520
URL1:https://arc.ask3.ru/arc/aa/60/db/60953b3a19d063c211088ecb0f5d00db.html
Заголовок, (Title) документа по адресу, URL1:
Adaptive bitrate streaming - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)