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). Радиостанции также работают онлайн; такое вещание называют интернет-радио. И IPTV, и интернет-радио используются по всему миру для освещения самых разных событий, от показов мод до мировых чемпионатов по футболу и отборочных состязаний по крикету. Помимо этого, с помощью технологии живого IP-вещания провайдеры кабельного телевидения создают собственные вещательные системы. Эта технология широко используется малобюджетными проектами от сайтов для взрослых до зоопарков. При современном уровне технологий практически любой человек может быстро и без значительных затрат начать живое вещание.
Один из подходов к живому вещанию сводится к тому, чтобы записывать контент на диск. Пользователь может подключиться к архивам сервера, выбрать любую передачу и скачать ее для прослушивания или просмотра. Скачанный выпуск программы называют подкастом (podcast).
Потоковая трансляция событий в реальном времени иногда вносит дополнительные сложности. В случае прямой трансляции спортивных событий, новостей и длинных речей политиков можно по-прежнему использовать метод буферизации (илл. 7.34). После авторизации пользователя на сайте с прямой трансляцией события в течение первых нескольких секунд видео не отображается, пока не заполнится буфер. После этого все происходит так же, как при просмотре фильма. Плеер извлекает данные из буфера, который непрерывно заполняется. По сути, разница лишь в том, что при потоковой передаче фильма сервер может загружать 10 с видеофайла за 1 с, если соединение достаточно быстрое. При прямой трансляции события это невозможно.
IP-телефония
Хорошим примером потоковой трансляции в реальном времени, при которой невозможна буферизация, является передача телефонного разговора по интернету (иногда с видео, как в случае Skype и FaceTime). Когда-то голосовые звонки передавались коммутируемой телефонной сетью общего пользования, а сетевой трафик был преимущественно голосовым (с небольшим количеством данных). Затем появились интернет и Всемирная паутина. С годами объем данных возрастал, и к 1999 году информационный трафик сравнялся с голосовым (сегодня речь оцифрована, поэтому и то и другое можно измерить в битах). К 2002 году информационный трафик на порядок превысил голосовой, и его экспоненциальный рост продолжается. Между тем объем голосового трафика сохраняется практически неизменным.
В результате телефонные сети стали вытесняться интернетом. На сегодняшний день голосовой трафик передается с помощью интернет-технологий и занимает лишь малую часть пропускной способности сети. Эта прорывная технология известна как IP-телефония (Voice over IP — передача голоса по протоколу IP), или интернет-телефония. Это название относится и к видеоконференциям, когда при разговоре используется видео или в нем участвует больше двух человек.
Самое главное отличие интернет-телефонии от потоковой онлайн-передачи фильмов в том, что в данном случае необходим низкий уровень времени ожидания. В телефонной сети оно составляет не более 150 мс в одном направлении; при превышении этого порога задержка становится заметной и начинает раздражать абонентов. (У международных звонков время ожидания иногда доходит до 400 мс, что дает не слишком приятный пользовательский опыт.)
Обеспечить столь низкий уровень задержки трудно. Конечно, буферизация 5–10 с мультимедиа (как это происходит при прямой спортивной радиотрансляции) не сработает. Вместо этого системы видео и голосовой IP-телефонии должны предусматривать разнообразные методы минимизации времени ожидания. Это ведет к выбору UDP вместо TCP, потому что повторные передачи TCP добавляют к задержке как минимум один полный обход.
Однако некоторые виды времени ожидания невозможно снизить даже c UDP. Например, расстояние между Сиэтлом и Амстердамом составляет около 8000 км. Задержка распространения со скоростью света в оптическом волокне для этого расстояния равна 40 мс. Пожелаем удачи тому, кто попробует ее сократить! На практике задержка распространения по сети будет больше, поскольку она покроет еще большее расстояние (биты идут не по кратчайшему пути). Кроме того, имеются задержки передачи, так как каждый IP-маршрутизатор сохраняет и пересылает пакет. Эти фиксированные задержки съедают общее допустимое время задержки.
Другой источник времени ожидания связан с размером пакета. Как правило, большие пакеты являются наилучшим способом использования пропускной способности сети, поскольку они эффективнее. Но для звукового сигнала с частотой дискретизации 64 Кбит/с пакет размером 1 Кбайт будет заполняться 125 мс (и даже дольше, если сэмплы сжаты). Такая задержка превысит общее время ожидания. Кроме того, если пакет в 1 Кбайт будет отправлен по широкополосному каналу, скорость которого равна 1 Мбит/с, передача займет 8 мс. Затем добавятся еще 8 мс, чтобы пакет прошел через широкополосное соединение на другом конце. Очевидно, что большие пакеты не подходят.
Вместо этого в системах IP-телефонии используются небольшие пакеты, чтобы сократить время ожидания за счет снижения эффективности использования пропускной способности. Звуковые сэмплы доставляются небольшими блоками, обычно по 20 мс. При скорости 64 Кбит/с это 160 байт данных (и еще меньше при сжатии). Однако задержка при использовании такого пакета составит всего 20 мс. Задержка передачи также будет меньше, потому что пакет короче. В нашем примере она сократится примерно до 1 мс. Минимальная задержка в одном направлении для небольшого пакета Сиэтл — Амстердам снижается с недопустимой — 181 мс (40 + 125 + 16) до приемлемой — 62 мс (40 + 20 + 2).
Мы даже не затронули издержки программного обеспечения, а оно тоже расходует часть допустимого времени ожидания. Это особенно характерно для видео, так как для его передачи с учетом имеющейся пропускной способности обычно требуется сжатие. В отличие от потоковой передачи сохраненного файла, в этом случае нет времени на работу кодировщика, требующего сложных вычислений и обеспечивающего высокую степень сжатия. И кодировщик, и декодировщик должны действовать быстро.