Поскольку все коммерческие видео шифруются с целью защиты от пиратства, медиаплееры должны уметь дешифровать их по мере их поступления. Это пятая задача в приведенном выше списке.
DASH и HLS
Далее мы коснемся проблем, возникающих из-за многообразия устройств для просмотра мультимедийного контента. Если пользователь купил себе яркий, блестящий и очень дорогой монитор с разрешением экрана 8K, ему нужно предоставлять видео с разрешением 7680 × 4320 и частотой кадров 100 или 120 кадров/с. Но если в ходе просмотра интересного фильма он отправится к врачу и будет досматривать этот фильм в приемной на смартфоне с разрешением 1280 × 720 и максимальной частотой кадров 25 кадров/с, возникнет проблема. Перед сайтом потокового вещания встает вопрос о том, какое разрешение и частоту кадров использовать при кодировании фильмов.
Самый простой выход — использовать все возможные комбинации. В худшем случае место на диске тратится на кодирование каждого фильма с использованием семи разрешений экрана (в формате смартфона, форматах NTSC, PAL, 720P, HD, 4K, 8K) и шести частот кадров (25, 30, 50, 60, 100 и 120). В совокупности мы получаем 42 варианта, но дисковое пространство сегодня стоит не так уж дорого. Более крупной сопутствующей проблемой является вопрос о том, что произойдет, если зритель останется дома со своим большим блестящим монитором, но из-за перегрузок сети пропускная способность канала между ним и сервером будет сильно колебаться, не всегда позволяя использовать полное разрешение.
К счастью, в настоящее время уже реализовано несколько решений этой проблемы, в частности протокол динамической адаптивной потоковой передачи данных по HTTP (Dynamic Adaptive Streaming over HTTP, DASH). Он основан на простой идее и совместим с HTTP (и HTTPS), благодаря чему его можно использовать для потоковой передачи на веб-странице. Сначала сервер потокового вещания кодирует свои фильмы с разным разрешением и частотой кадров, сохраняя их на своих хранилищах. Каждая версия сохраняется в виде множества файлов (вместо одного), которые содержат, скажем, 10 с видео и аудио. Это значит, что для 90-минутного фильма, кодируемого с использованием семи разрешений экрана и шести частот кадров (что дает 42 варианта), потребуется 42 × 540 = 22 680 отдельных файлов с контентом для 10 с воспроизведения. Другими словами, каждый файл содержит сегмент фильма в конкретном разрешении и с определенной частотой кадров. С фильмом ассоциируется манифест — описание представления медиаданных (Media Presentation Description, MPD) — с именами всех файлов и их параметрами, включая разрешение, частоту кадров и номер кадра в фильме.
Чтобы этот подход работал, протокол DASH должен использоваться и плеером, и сервером. В качестве пользовательской стороны может выступать либо непосредственно браузер, либо плеер, встроенный в него в виде JavaScript-кода, либо специальное приложение (например, для мобильного устройства или телеприставки). Перед просмотром фильма DASH прежде всего доставляет манифест для него. Это небольшой файл, поэтому достаточно обычного HTTPS-запроса GET.
Затем плеер запрашивает у устройства, на котором он работает, информацию о максимальном разрешении и, возможно, другие сведения (к примеру, поддерживаемые аудиоформаты и количество динамиков). Затем он проводит ряд проверок, отправляя тестовые сообщения на сервер, чтобы оценить доступную пропускную способность. Получив эти данные и узнав разрешение экрана, плеер сверяется с манифестом, чтобы найти первые 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.