stringtranslate.com

Адаптивный поток битрейта

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

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

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

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

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

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

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

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

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

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

Масштабируемая CDN используется для доставки потоковой передачи мультимедиа интернет-аудитории. CDN получает поток из источника на своем сервере Origin, затем реплицирует его на многие или все свои кэширующие серверы Edge . Конечный пользователь запрашивает поток и перенаправляется на «ближайший» сервер Edge. Это можно проверить с помощью libdash [15] и набора данных Distributed DASH (D-DASH) [16] , который имеет несколько зеркал в Европе, Азии и США. Использование адаптивной потоковой передачи на основе HTTP позволяет серверу Edge запускать простое программное обеспечение 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 Forum компанией Phoenix Technologies в лаборатории Harman Kardon в Филлингене, Германия. [ необходима ссылка ]

Реализации

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

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

Dynamic Adaptive Streaming over 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 основана на Adaptive HTTP Streaming (AHS) в 3GPP Release 9 и на HTTP Adaptive Streaming (HAS) в Open IPTV Forum Release 2. [25] В рамках сотрудничества с MPEG, 3GPP Release 10 принял DASH (с определенными кодеками и режимами работы) для использования в беспроводных сетях. [25]

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

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

Прямая трансляция Apple HTTP (HLS)

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 application/vnd.apple.mpegurl. [35] Эти адаптивные потоки могут быть доступны во многих различных битрейтах, и клиентское устройство взаимодействует с сервером для получения наилучшего доступного битрейта, который может быть надежно доставлен.

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

Adobe HTTP Dynamic Streaming (HDS)

«HTTP Dynamic streaming — это процесс эффективной доставки потокового видео пользователям путем динамического переключения между различными потоками различного качества и размера во время воспроизведения. Это обеспечивает пользователям наилучшие возможности просмотра, которые могут поддерживать их пропускная способность и локальное компьютерное оборудование ( ЦП ). Другая важная цель динамической потоковой передачи — сделать этот процесс плавным и бесшовным для пользователей, так что если необходимо масштабирование или понижение качества потока, это будет плавным и почти незаметным переключением без прерывания непрерывного воспроизведения». [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 как Protected Interoperable File Format. [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 успешно продемонстрировала доставку как живого, так и по запросу 1080p HD видео с Smooth Streaming для клиентов Silverlight. В 2010 году Microsoft также сотрудничала с NVIDIA для демонстрации живого потокового 1080p стереоскопического 3D видео на ПК, оснащенных технологией 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, Watch Disney Junior и Watch Disney XD. [45] [46]

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

В последние годы преимущества алгоритмов самообучения в адаптивной потоковой передаче битрейта были исследованы в академических кругах. В то время как большинство первоначальных подходов к самообучению реализуются на стороне сервера [47] [48] [49] (например, выполнение контроля допуска с использованием обучения с подкреплением или искусственных нейронных сетей ), более поздние исследования сосредоточены на разработке самообучающихся клиентов HTTP Adaptive Streaming. В литературе было представлено несколько подходов с использованием алгоритма SARSA [50] или Q-learning [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), Том 1, выпуск 1 , стр. 1-1, 2018.
  3. ^ ab DASH в ITEC, плагин VLC, DASHEncoder и набор данных от C. Mueller, S. Lederer, C. Timmerer
  4. ^ ab "Proceedings Template – WORD" (PDF) . Получено 16 декабря 2017 г. .
  5. ^ Ганнес, Лиз (10 июня 2009 г.). «Следующее большое событие в видео: адаптивная потоковая передача битрейта». Архивировано из оригинала 19 июня 2010 г. Получено 1 июня 2010 г.
  6. ^ ab "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 г.). "Show Report: Video Processing Critical to Digital Asset Management". Elemental Technologies. Архивировано из оригинала 4 октября 2011 г. Получено 15 октября 2011 г.
  10. ^ Seufert, Michael; Egger, Sebastian; Slanina, Martin; Zinner, Thomas; Hoßfeld, Tobias; Tran-Gia, Phuoc (2015). «Обзор качества восприятия адаптивной потоковой передачи HTTP». IEEE Communications Surveys & Tutorials . 17 (1): 469–492. doi :10.1109/COMST.2014.2360940. S2CID  18220375.
  11. ^ ab Saamer Akhshabi; Ali C. Begen; Constantine Dovrolis. "Экспериментальная оценка алгоритмов адаптации скорости в адаптивной потоковой передаче по 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. ^ ab 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 Adaptive Bitrate от Apple». Архивировано из оригинала 19 июня 2010 г. Получено 24 июня 2010 г.
  20. ^ "Move Gets Streaming Patent; Adobe & Apple Hosed? – Online Video News". Gigaom.com. 15 сентября 2010 г. Архивировано из оригинала 22 октября 2011 г. Получено 15 октября 2011 г.
  21. ^ ab "MPEG ратифицирует свой проект стандарта DASH". MPEG. 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)". Iso.org . Получено 16 декабря 2017 г. .
  24. ^ Обновления DASH – запись в блоге
  25. ^ ab ETSI 3GPP 3GPP TS 26.247; Прозрачная сквозная служба потоковой передачи с коммутацией пакетов (PSS); Прогрессивная загрузка и динамическая адаптивная потоковая передача по HTTP (3GP-DASH)
  26. ^ "bitdash HTML5 MPEG-DASH player". 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". Github.com . Получено 16 декабря 2017 г. .
  30. ↑ Mac Developer Library, Apple , получено 2 июня 2014 г.
  31. ^ Репозиторий Shaka Packager Github, Google , получено 3 января 2023 г.
  32. ^ Unified Streaming, Unified Streaming , получено 3 января 2023 г.
  33. ↑ Prince McLean (9 июля 2009 г.). «Apple запускает стандарт HTTP Live Streaming в iPhone 3.0». AppleInsider . Получено 15 октября 2011 г.
  34. ^ R. Pantos, HTTP Live Streaming, IETF , получено 11 октября 2011 г.
  35. ^ RFC 8216. раздел 4. doi : 10.17487/RFC8216 .
  36. ^ Хассун, Дэвид. "Динамическая потоковая передача в Flash Media Server 3.5 – Часть 1: Обзор новых возможностей". Adobe Developer Connection . Adobe Systems. Архивировано из оригинала 30 марта 2014 г.
  37. ^ "HTTP Dynamic Streaming". Adobe Systems . Получено 13 октября 2010 г.
  38. ^ "FAQ HTTP Dynamic Streaming". Adobe Systems . Получено 12 января 2015 г.
  39. ^ "Smooth Streaming". IIS.net. Архивировано из оригинала 15 июня 2010 года . Получено 24 июня 2010 года .
  40. ↑ Крис Ноултон (8 сентября 2009 г.), Protected Interoperable File Format, Microsoft , получено 15 октября 2011 г.
  41. ^ «Microsoft End-to-End Platform Powers Next-Generation Silverlight and IIS Media Experiences Across Multiple Screens». Microsoft. 8 апреля 2010 г. Получено 30 июля 2011 г.
  42. ^ "First Day of IBC". Microsoft. Архивировано из оригинала 2 февраля 2011 года . Получено 22 января 2011 года .
  43. ^ Трейси Рютер (23 января 2019 г.). «Что такое CMAF?» . Получено 13 января 2022 г.
  44. ^ Лука Де Чикко; Саверио Масколо; Витторио Пальмизано. «Управление обратной связью для адаптивного потокового видео в реальном времени» (PDF) . ММСИС2011 . Проверено 9 сентября 2012 г.
  45. ↑ Дин Такахаши (16 января 2013 г.). «Uplynk создает для Disney дешевый и эффективный способ потоковой передачи видео». VentureBeat . Получено 16 декабря 2017 г.
  46. ^ Дрейер, Трой (16 января 2013 г.). «UpLynk выходит из скрытого режима; DisneyABC становится первым клиентом – Streaming Media Magazine». Streamingmedia.com . Получено 16 декабря 2017 г.
  47. ^ Y. Fei; VWS Wong; VCM Leung (2006). «Эффективное обеспечение QoS для адаптивных мультимедиа в сетях мобильной связи с помощью обучения с подкреплением». Мобильные сети и приложения . 11 (1): 101–110. CiteSeerX 10.1.1.70.1430 . doi :10.1007/s11036-005-4464-2. S2CID  13022779. 
  48. ^ V. Charvillat; R. Grigoras (2007). «Обучение с подкреплением для динамической адаптации мультимедиа». Журнал сетевых и компьютерных приложений . 30 (3): 1034–1058. doi :10.1016/j.jnca.2005.12.010.
  49. ^ DW McClary; VR Syrotiuk; V. Lecuire (2008). «Адаптивная потоковая передача звука в мобильных ad hoc сетях с использованием нейронных сетей». Ad Hoc Networks . 6 (4): 524–538. doi :10.1016/j.adhoc.2007.04.005.
  50. ^ В. Менковски; А. Лиотта (2013). «Интеллектуальное управление для адаптивной потоковой передачи видео». Международная конференция IEEE по потребительской электронике (ICCE) . Вашингтон, округ Колумбия. С. 127–128. doi :10.1109/ICCE.2013.6486825.
  51. ^ M. Claeys; S. Latré; J. Famaey; F. De Turck (2014). «Проектирование и оценка самообучающегося HTTP-клиента адаптивного потокового видео». IEEE Communications Letters . 18 (4): 716–719. doi : 10.1109/lcomm.2014.020414.132649. hdl : 1854/LU-5733061 . S2CID  26955239.
  52. ^ S. Petrangeli; M. Claeys; S. Latré; J. Famaey; F. De Turck (2014). «Многоагентная структура на основе Q-Learning для достижения справедливости в HTTP Adaptive Streaming». Симпозиум IEEE по сетевым операциям и управлению (NOMS) . Краков. С. 1–9. doi :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=( помощь )

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