Чтение онлайн

Благодаря протоколу, который позволяет сообщать серверу о необходимости остановки и запуска передачи, плеер может держать в буфере достаточно, но не слишком много медиаданных, чтобы обеспечить плавное воспроизведение. Поскольку ОЗУ на сегодняшний день стоит довольно дешево, медиаплеер даже на смартфоне может выделить достаточно места в буфере для нескольких минут воспроизведения, если нужно.

Механизм запуска и остановки обладает еще одной приятной особенностью: с ним скорость передачи сервера не привязана к скорости воспроизведения. Допустим, плееру нужно воспроизвести видео со скоростью 8 Мбит/с. Когда объем данных в буфере опустится до нижнего предела, плеер запросит у сервера доставку дополнительных данных. Если сервер способен производить доставку со скоростью 100 Мбит/с, это не вызовет проблем. Поступающие данные будут просто сохраняться в буфере. При достижении верхнего предела плеер сообщит серверу о необходимости остановки. Таким образом, скорость передачи сервера и скорость воспроизведения совершенно не зависят друг от друга. То, что изначально было системой реального времени, стало обычной системой передачи файлов. Избавление от всех требований к передаче в реальном времени — одна из причин, почему Youtube, Netflix, Hulu и другие сервисы потоковой передачи используют TCP. Это существенно упрощает дизайн всей системы.

Определить подходящий размер буфера не так просто. Если доступно много оперативной памяти, может показаться, что лучше использовать большой буфер, позволив серверу держать его почти заполненным, на случай перегрузки сети. Но следует учесть, что люди порой привередливы. Посчитав какую-нибудь сцену скучной, пользователь может нажать кнопку перемотки вперед, и большая часть или все содержимое буфера станет бесполезным. Как бы там ни было, переход к определенному моменту времени вперед или назад сработает, только если этот кадр является I-кадром. В противном случае плееру нужно найти ближайший I-кадр. Если новая точка воспроизведения находится за пределами буфера, его нужно полностью очистить и загрузить заново. То есть если пользователь часто перематывает видео вперед или назад (а так поступают многие), он фактически впустую тратит пропускную способность сети, делая бесполезными данные буфера, загрузка которых требовала определенных затрат. В рамках всей системы наличие пользователей, склонных часто перематывать видео, — серьезный аргумент в пользу ограничения размера буфера, даже несмотря на низкую стоимость больших объемов ОЗУ. В идеале медиаплеер должен понаблюдать за поведением пользователя и выбрать размер буфера, исходя из свойственной этому человеку манеры просмотра.

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

DASH и HLS

Далее мы коснемся проблем, возникающих из-за многообразия устройств для просмотра мультимедийного контента. Если пользователь купил себе яркий, блестящий и очень дорогой монитор с разрешением экрана 8K, ему нужно предоставлять видео с разрешением 7680 x 4320 и частотой кадров 100 или 120 кадров/с. Но если в ходе просмотра интересного фильма он отправится к врачу и будет досматривать этот фильм в приемной на смартфоне с разрешением 1280 x 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 x 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 x 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. По всей видимости, в ближайшие годы эти два протокола продолжат существовать параллельно.