Затем плеер запрашивает у устройства, на котором он работает, информацию о максимальном разрешении и, возможно, другие сведения (к примеру, поддерживаемые аудиоформаты и количество динамиков). Затем он проводит ряд проверок, отправляя тестовые сообщения на сервер, чтобы оценить доступную пропускную способность. Получив эти данные и узнав разрешение экрана, плеер сверяется с манифестом, чтобы найти первые 10 с фильма с наилучшим качеством для имеющейся конфигурации.

Но это еще не конец истории. По мере воспроизведения фильма плеер продолжает запускать проверки пропускной способности. Каждый раз, когда ему нужен дополнительный контент (если объем медиаданных в буфере опускается до нижнего предела), он снова сверяется с манифестом и запрашивает подходящий файл в зависимости от того, какая часть фильма требуется и какое разрешение и частоту кадров нужно при этом использовать. Если пропускная способность сильно колеблется по мере воспроизведения, формат фильма может переключаться несколько раз в минуту от 8K при 100 кадрах/с к HD при 25 кадрах/с и обратно. При данном подходе система быстро адаптируется к изменению параметров сети и обеспечивает наилучший опыт просмотра видео в соответствии с имеющимися ресурсами. Такие компании, как Netflix, опубликовали информацию о том, как они корректируют битрейт видеопотока в зависимости от степени заполненности буфера воспроизведения (Хуан и др.; Huang et al., 2014). Пример показан на илл. 7.35.

Илл. 7.35. Использование DASH для изменения формата видео во время просмотра фильма

На илл. 7.35 по мере снижения пропускной способности плеер запрашивает версии со все более низким разрешением. Однако он также мог использовать и другие способы уменьшения объема данных. Например, отправка 300 кадров для 10 с воспроизведения потребует гораздо меньше пропускной способности, чем отправка 600 или 1200 кадров для тех же 10 с (даже с высокой степенью сжатия). В крайнем случае плеер мог запросить черно-белую версию с частотой 10 кадров/с, разрешением 480 × 320 и одноканальным звуком при наличии такой версии в манифесте. Протокол DASH позволяет плееру корректировать воспроизведение согласно меняющимся условиям, тем самым обеспечивая наилучший пользовательский опыт в конкретной ситуации. Логика работы плеера и способ запрашивания сегментов варьируются в зависимости от характера сервиса воспроизведения и особенностей устройства. Сервисы, избегающие повторной буферизации, могут запрашивать множество сегментов целыми группами; если же сервис стремится к максимальной интерактивности, он извлекает DASH-сегменты в более постоянном, размеренном темпе.

Протокол DASH продолжает развиваться. Например, ведется работа по снижению задержки (Ле Февр и др.; Le Feuvre et al., 2015), улучшению надежности (Ван и Рен; Wang and Ren, 2019), повышению равнодоступности (Алтамини и Ширмохаммади; Altamini and Shirmohammadi, 2019), обеспечению поддержки виртуальной реальности (Рибеццо и др.; Ribezzo et al., 2018), а также по эффективной обработке видео формата 4K (Куинлан и Сринан; Quinlan and Sreenan, 2018).

DASH сегодня является самым распространенным протоколом потоковой передачи видео, хотя существуют и другие методы, о которых стоит упомянуть. Протокол потоковой передачи в реальном времени на основе HTTP (HTTP Live Streaming, HLS) от компании Apple также работает в браузере с использованием HTTP. Он рекомендуется для просмотра видео в браузере Safari на устройствах компании Apple (iPhone, iPad, MacBook и т.д.). Он также широко используется браузерами Microsoft Edge, Firefox и Chrome, на платформах Windows, Linux и Android. Кроме того, его часто поддерживают игровые консоли, «умные» телевизоры и другие устройства, способные воспроизводить мультимедийный контент.

Как и DASH, HLS требует, чтобы сервер кодировал фильм с разным разрешением и частотой кадров и каждый сегмент охватывал лишь несколько секунд видео. Это позволяет быстро адаптироваться к изменению условий. Протокол HLS также предлагает и ряд дополнительных функций, включая быструю прокрутку вперед и назад, субтитры на нескольких языках и многое другое. Он описан в RFC 8216.

Несмотря на одинаковые базовые принципы, протоколы DASH и HLS все же имеют некоторые различия. DASH инвариантен к кодеку: он может работать с видео, используя любой алгоритм кодирования. HLS работает только с теми алгоритмами, которые поддерживаются Apple, но поскольку туда входят H.264 и H.265, то этим различием можно пренебречь, ведь с их помощью сегодня сжимаются почти все видео. Протокол DASH позволяет третьей стороне легко вставлять рекламу в видеопоток, в то время как HLS не позволяет этого. С DASH можно использовать любую схему управления цифровыми правами, а HLS поддерживает только систему от Apple.

Протокол DASH — это открытый официальный стандарт, а HLS является проприетарным продуктом. При этом и у первого и у второго есть свои плюсы и минусы. Благодаря тому, что за HLS стоит мощный спонсор, он доступен на гораздо большем числе платформ, чем DASH, и его реализации отличаются чрезвычайной стабильностью. Однако, несмотря на то что на устройствах с iOS нет встроенной поддержки DASH, его используют и YouTube, и Netflix. По всей видимости, в ближайшие годы эти два протокола продолжат существовать параллельно.

Потоковое видео было одной из главных движущих сил интернета на протяжении десятилетий. Ретроспективный анализ этой технологии можно найти в работе Ли и др. (Li et al., 2013).

Актуальная проблема потоковой передачи видео — оценка QoE (то есть того, насколько пользователь доволен работой приложения). Измерить QoE напрямую довольно сложно: для этого пришлось бы опрашивать пользователей. Однако многие операторы сетей стремятся выявлять ситуации, когда потоковые приложения попадают в условия, влияющие на пользовательский опыт. Обычно операторы стараются оценить разрешение и величину задержки при запуске (как долго начинается воспроизведение видео), а также любые случаи остановки («повторной буферизации»). При зашифрованном видеопотоке получение этой информации осложняется, особенно если интернет-провайдер не имеет доступа к клиентскому ПО. В таких случаях оценка качества приложения сегодня все чаще производится с помощью методов машинного обучения (Мангла и др.; Mangla et al., 2018; Бронзино и др.; Bronzino et al., 2020).

7.4.4. Потоковая передача в реальном времени

Огромной популярностью в интернете пользуются не только готовые видеозаписи, но и потоковая передача видео в реальном времени. Когда появилась технология потоковой передачи аудио- и видеоданных через интернет, коммерческие радиостанции и телеканалы тут же воспользовались этим, чтобы транслировать свой контент не только в эфире, но и онлайн. Вскоре появились университетские интернет-радиостанции. Затем собственные онлайн-трансляции стали вести студенты.

Сегодня живую аудио- и видеотрансляцию осуществляют как отдельные люди, так и компании самых разных масштабов. Вещание в реальном времени стало колыбелью инноваций, возникли новые стандарты и технологии. Чтобы обеспечить онлайн-присутствие, крупные телеканалы транслируются в интернете; это называется IP-телевидением (IP TeleVision, IPTV). Радиостанции также работают онлайн; такое вещание называют интернет-радио. И