Тема выпускной работы: Система моделирования технологической схемы производства и организации работы с документами

Научный руководитель: доцент кафедры компьютерной инженерии, кандидат технических наук Теплинский Сергей Васильевич

Перевод статьи

Методы доставки контента

Оригинальная статья:

Content Delivery Techniques / IIS Smooth Streaming Technical Overview

Alex Zambelli, Media Technology Evangelist

Microsoft Corporation — March 2009

Сегодня доставка медиа контента в Интернете осуществляется тремя методами: традиционное потоковое вещание, прогрессивная загрузка и адаптивное потокове вещание

Традиционное потоковое вещание

RTSP (Потоковый протокол передачи в реальном времени — англ: Real-Time Streaming Protocol) — хороший пример традиционного потокового протокола. RTSP определен как полноценный протокол, что означает, что с момента первого подключения клиента к потоковому серверу и до момента его отключения сервер отслеживает состояние клиента. Клиент сообщает свое состояние серверу при помощи посылки команд PLAY, PAUSE или TEARDOWN (первые две очевидны, последняя используется для отключения от сервера и закрытия сессии потоковой передачи).

После того, как связь между сервером и клиентом установлена, сервер начинает отсылку медиа в виде непрерывного потока небольших пакетов (формат таких пакетов известен под названием RTP). Размер типичного RTP пакета составляет 1452 байта, что подразумевает кодирование видеопотока в 1 мегабит в секунду (Mbps) и длительность одного кадра примерно 11 миллисекунд. В RTSP пакеты могут быть переданы либо через UDP, либо через TCP протоколы — последний предпочтителен, если файрволл или прокси блокируют UDP пакеты, однако его использование может приводить к увеличению задержки (пакеты TCP пересылаются до успешного получения).

Рисунок 1. RTSP — пример традиционного потокового протокола.

С другой стороны, HTTP, известный как протокол «без состояний». Когда клиент запрашивает некоторые данные, сервер отвечает посылкой данных, но он не будет помнить состояние клиента. Каждый запрос HTTP обрабатывается как полностью отдельная одноразовая сессия.

Сервисы Windows Media поддерживают потоковую передачу при помощи RTSP и HTTP. Но если HTTP является протоколом без состояний, то как может использоваться для потоковой передачи? Сервисы Windows Media использую модифицированную версию HTTP, известную как MS-WMSP (в сервисах Windows Media она называется Windows Media HTTP Streaming Protocol, или в общем случае, просто Windows Media HTTP). MS-WMSP использует стандарт HTTP для передачи данных и сообщений, при этом вводя состояния сессии, эффективно подключая их к протоколу потоковой передачи, например, RTSP. Сервисы Windows Media также поддерживают потоковую передачу через RTSP с 2003 года (в Windows Media Services 9 Series) через UDP и TCP. Его реализация публично задокументирована как MS-RTSP.

Из сервисов Windows Media Silverlight поддерживает доставку, основанную только на HTTP.

Наиболее важными аспектами традиционных потоковых протоколов, таких как RTSP и Windows Media HTTP (MS-WMSP), являются:

• Сервер посылает клиенту пакеты данных исключительно в режиме реального времени — это и есть битрейт, которым закодирован поток. Например, видео, закодированное при 500 килобитах в секунду (kbps), передается клиенту на скорости примерно 500 кб/с.
• Сервер просто посылает так много пакетов, сколько необходимо для заполнения клиентского буфера. Клиентский буфер обычно включает от 1 до 10 секунд (стандартный буфер проигрывателя Windows Media и Silverlight — 5 секунд). Это означает, что если вы приостановите потоковое видео и подождете 10 секунд, все равно только около 5 секунд видео будет загружено клиенту за это время.

Другими примерами традиционных потоковых протоколов являются проприетарный протокол передачи сообщений (RTMP, англ: Real Time Messaging Protocol) компании Adobe Systems и протокол RTSP over Real Data Transport (RDT) компании RealNetworks. Функция динамического переключения потоков (Dynamic Streaming stream-switching), реализованный в платформе Adobe® Flash® основан на протоколе RTMP и поэтому рассматривается как метод традиционного, а не адаптивного вещания.

Прогрессивная загрузка

Другая форма доставки медиа контента в Интернете — прогрессивная загрузка, которая является ни чем иным, как обычной загрузкой файла с HTTP сервера. Прогрессивную загрузку поддерживают большинство медиа проигрывателей и платформ, включая Adobe Flash, Silverlight, и проигрыватель Windows Media. Термин «прогрессивная» происходит от факта, что большинство проигрывателей клиентов разрешают воспроизведение медиа файла в то время, когда загрузка файла еще идет — до тех пор, пока файл полностью не загрузится на диск (обычно в кэш Web браузера). Клиенты с поддержкой спецификации HTTP 1.1 могут менять позицию чтения файла до завершения его загрузки путем выполнения серии запросов к Web серверу (при условии, что он также поддерживает HTTP 1.1).

Популярные Web сайты для обмена видео, включая YouTube, Vimeo, MySpace, и MSN Soapbox почти полностью используют прогресивную загрузку.

В противовес потоковым серверам, редко посылающим на клиентскую сторону более 10 секунд медиа данных за раз, HTTP Web серверы поддерживают поток данных до их полной загрузки. Если вы приостановите прогрессивно загруженное видео в начале и затем подождете, велика вероятность того, что все видео загрузилось в кэш браузера и вы сможете посмотреть полностью все видео без прерываний. Однако, у такого подхода есть обратная сторона медали — если посмотрев 30 секунд из 10 минутного видео, вы решите прекратить просмотр, то получится, что вы и ваш контент провайдер впустую потратили пропускную способность сети, равную 9,5 минутам видео. Во избежание этой провлемы, IIS 7.0 предлагает хорошее расширение, именуемое регулирование битрейта (англ: Bit Rate Throttling), позволяющее контент провайдерам регулировать скорость загрузки точно так же, как это делают потоковые сервера для снижения затрат при передаче.

Адаптивное потоковое вещание, основанное на HTTP

Адаптивное потоковое вещание — это гибридный метод доставки контента, который функционирует как потоковый сервер, но при этом основан на прогрессивной HTTP загрузке. Это весьма передовая методика, использующая HTTP, а не новый протокол. IIS Smooth Streaming и Move Networks Adaptive Stream являются примерами адаптивного вещания. Даже если две технологии используют различные кодеки, форматы и схемы шифрования, они обе полагаются на HTTP как на транспортный протокол и выполняют загрузку медиа в виде большой последовательности очень маленьких прогрессивных загрузок, а не одну большую прогрессивную загрузку.

В реализации обычного адаптивного вещания видео/аудио исходник делится на множество небольших сегментов (частей) и кодируется согласно выбранному формату. Части обычно имеют продолжительность 2-4 секунды. На уровне видео кодека это означает, что каждая часть определена в пределах GOP (англ: Group of Pictures, группа картинок — перев.) (каждая часть начинается с ключевого кадра) и не зависит от предыдущих или последующих частей/GOP. Это позволяет каждой части быть закодированной независимо от других частей.

Закодированные части размещаются на HTTP Web сервере. Клиент запрашивает части с Web сервера линейно и скачивает их, используя обычную прогрессивную загрузку по HTTP. Как только все части переданы клиенту, он воспроизводит эти части линейно в обратном порядке. Поскольку видео кодируется без пробелов и дублирования, части воспроизводятся как непрерывное видео.

«Адаптивная» часть этого подхода раскрывается, когда видео/аудио исходник кодируется разными битрейтами, генерируя множество частей различного размера для каждого промежутка 2-4 секунды видео. Теперь клиент может выбирать между частями различного размера. Так как Web сервера обычно доставляют данные с максимальной скоростью, клиент может оцениь пропускную способность пользовательского канала и решить, загружать ему большие или маленькие части. Размер проигрываемого/загруженного буфера является полностью настраиваемым.

Рисунок 2. Адаптивное потоковое вещание — гибридный метод доставки медиа.

Адаптивное вещание, как и другие виды HTTP доставки, имеет следующие преимущества перед обычным вещанием для поставщика контента:

• Экономичное развертывание из-за того, что адаптивное вещание использует обычные HTTP кэши/прокси и не требует специализированных серверов.
• Данный подход имеет лучшую масштабируемость, снимая воспрос «последней мили», так как он может гибко подстраиваться под меняющиеся условия сетей.
• Он позволяет потребителю выбирать понравившееся качество контента, а не вынуждает провайдеров догадываться о битрейте, который понравится потребителю

Оно также имеет такие преимущества для пользователя:

• Быстрый запуск и мгновенная перемотка, так как для этих действий требуется низкий битрейт перед переходом на более высокий битрейт.
• Никакой буфферизации, отключений и остановки вопроизведения (если пользователь удовлетворяет требованиям минимального битрейта).
• Непрерывная смена битрейта, зависящая только от состяния сети и возможностей CPU.
• Гладкое воспроизведение.

Microsoft создала прототип реализации адаптивного потокового вещания, основанного на HTTP, для Web сайта телеканала NBC, посвященного Летним Олимпийским играм в Пекине (2008 год). Для того, чтобы соответствовать графику разработки проекта, реализация была очень простой. NBC использовала кодеры Digital Rapids и Anystream для создания множества файлов Windows Media Video (WMV) различного битрейта для каждого исходника. Кодеры не применяли никаких хитростей, а следовали строго по алгоритму (близкостоящие GOP, GOP равной длины, заголовки точек вхождения VC-1 и так далее.), который обеспечивал точное смещение кадров видео с различным битрейтом. Эти файлы WMV пропускались через инструмент пост-обработки, который физически делил каждый файл WMV на тысячи 2 секундных частей (файлов). Остальная часть решения заключалась в выгрузке частей на Web сервера CDN и запуске проигрывателя Silverlight, кторый был способен загружать части и вопроизводить их в правильной последовательности.

С такой реализацией NBC и Microsoft могли предложить лучшее, чем WMS, потоковое решение, используя лишь простую загрузку по HTTP. Возросшая зрительская аудитория привела к увеличению числа размещений рекламы и, следовательно, увеличению прибыли.

Однако, операторы CDN потратили сотни часов, управляя миллионами маленьких частей в своих системах. Представьте: если каждые 2 секунды видео делились на различные файлы и это повторялось для 5 доступных битрейтов, то для этого требовалось бы 150 файлов на каждую минуту видео, или 13500 файлов на 90-минутный футбольный матч!

Так что несмотря на то, что сайт Олимпиады телеканала NBC был огромным успехом для Silverlight и адаптивного потокового вещания, основанного на HTTP, довольно скоро стало очевидно, что для дальнейшего развития этой идеи и совершенствования методик управления файлами, необходимы значительные изменения.