В середине 1990-х идея передачи видео по имевшимся сетям IP была столь же далека от реальности, как затея перевозить слонов на метро в час пик, с гарантированной скоростью и в больших количествах. Однако перспектива показа видео по сетям IP была слишком заманчива, чтобы отказаться от нее. С тех пор инженерная мысль предложила множество идей, как обеспечить качество доставки видео.
Передача видео на расстояние долгое время была недостижимой мечтой для человечества. Футурологи XIX века предсказывали такую возможность и высказывали различные предположения о том, как это изменит мир. По своему значению мечта об удаленном видении (то есть телевидении) была сродни мечте о полете по воздуху. Ее очень долго, но безуспешно пытались реализовать, а удалось ее воплотить в реальность лишь около 70 лет назад Владимиру Козьмичу Зворыкину, эмигранту из России, жившему и работавшему в США. Массовое же распространение телевидение получило уже после Второй мировой войны.
Телевидение примерно на полвека опередило по времени своего появления Интернет, который был изобретен в 70-е, а массовое распространение получил в 90-х годах XX века. Так что в первые полвека своего существования телевизионные технологии были единственной возможностью передать видео на расстояние. Однако массовое распространение Интернета и частных сетей IP, рост скоростей подключения и пропускной способности каналов натолкнули инженеров на мысль о возможности передачи видео через Интернет или другие сети IP.
Первые опыты передачи видео по сетям IP в университетских лабораториях проводились еще в середине 90-х годов, но вызывали скепсис у представителей бизнеса. Я в это время уже занимался этой тематикой и хорошо помню слова одного из авторитетных экспертов по телекоммуникациям: «IP — это протокол, не предназначенный для передачи видео». Но уже в 1997 году на рынок вышел первый коммерческий продукт для потокового вещания видео в Интернете — сервер RealVideo. Примерно тогда же появились и первые системы корпоративной видео-конференц-связи, использовавшие IP в качестве транспорта, — хотя основной технологией передачи при организации таких конференций все равно оставалась ISDN.
Следующей вехой в развитии потокового вещания видео стал 2002 год, когда во Flash-плеере, установленном к тому времени на 90% компьютеров, впервые появилась возможность проигрывания видео. А в 2005 году на базе этой технологии был запущен видеохостинг YouTube, который быстро приобрел огромную популярность. Технология Flash стала на несколько лет де-факто стандартом для показа видео в Интернете.
ПОДХОДЫ К ОБЕСПЕЧЕНИЮ КАЧЕСТВА ПЕРЕДАЧИ ВИДЕО
Как же оказалось возможным, что технология передачи видео по сетям IP, которой в середине 90-х годов попросту не было и в помине, стала общедоступной уже через десятилетие? Ведь высказывание о неприспособленности сетей IP к передаче видео представлялось в 1996 году вполне обоснованным. Действительно, на тот момент пропускная способность каналов была низкой, а видеокодеки обеспечивали довольно посредственный уровень компрессии и при этом были чувствительны к потерям пакетов. Более того, не существовало никаких гарантий качества доставки контента: пакеты, содержащие видео, могли теряться из-за перегрузки портов маршрутизаторов или потерь в каналах сети IP. В общем, идея передачи видео по тогдашним сетям IP была столь же далека от реальности, как идея перевозить слонов на метро в час пик, с гарантированной скоростью и в больших количествах.
Однако перспектива показа видео по сетям IP была слишком заманчива, чтобы отказаться от нее. Инженерная мысль предложила множество идей, как обеспечить качество доставки видео. Все эти идеи можно условно разделить на три типа:
- резервирование сетевых ресурсов;
- опережающее наращивание емкости сети;
- адаптивное вещание видео.
Об этих подходах и конкретных технологиях, их реализующих, мы и расскажем ниже.
РЕЗЕРВИРОВАНИЕ СЕТЕВЫХ РЕСУРСОВ
Начнем с первого подхода — резервирование сетевых ресурсов для пропуска видеотрафика, то есть фактически его приоритизация. Для этого было разработано несколько механизмов, подробнее остановимся на одном из них — протоколе резервирования сетевых ресурсов (Resource ReSerVation Protocol, RSVP), который позволяет забронировать полосу пропускания IP-канала от отправителя до получателя до начала передачи видео по сети.
Работает протокол RSVP следующим образом (см. Рисунок 1): узел-отправитель до передачи данных, которым необходимо определенное нестандартное качество обслуживания (например, постоянная пропускная способность для передачи видеоинформации), посылает по сети специальное сообщение о пути (path message), содержащее сведения о типе передаваемой информации и требуемой пропускной способности. Сообщение передается от маршрутизатора к маршрутизатору по всему пути от узла-отправителя до адресата, при этом фиксируется последовательность маршрутизаторов, на которых необходимо зарезервировать определенную полосу пропускания.
Рисунок 1. Принципы работы протокола резервирования сетевых ресурсов RSVP. |
Маршрутизатор, получив такое сообщение, проверяет свои ресурсы с целью определения возможности выделения требуемой пропускной способности. При ее отсутствии запрос отвергается. Если требуемая пропускная способность достижима, то маршрутизатор настраивает алгоритм обработки пакетов таким образом, чтобы указанному потоку всегда предоставлялась требуемая пропускная способность, а затем передает сообщение следующему маршрутизатору вдоль пути. В результате по всему пути от узла-отправителя до адреса назначения резервируется необходимая пропускная способность с целью обеспечения запрашиваемого качества обслуживания, а пакеты, содержащие фрагменты видео, гарантированно доходят от источника до потребителя, качество видеопотока при этом не снижается.
Однако проблема внедрения протокола RSVP, как и всех протоколов управления трафиком, заключается в том, что их применение при прохождении трафика через две сети или более практически невозможно. Встречается очень мало примеров, когда владельцы сетей договариваются о сквозной поддержке механизмов управления трафиком, — эксплуатация этих механизмов на стыках сетей оказывается затруднительной из-за сложности процесса поиска и устранения возможных проблем. Поэтому применение метода резервирования сетевых ресурсов для обеспечения качества видео возможно только в рамках одной корпоративной или операторской сети. Соответственно, область применения этого метода ограничена, как правило, внутренними задачами организаций. Примерами таких задач являются построения корпоративных систем видео-конференц-связи или корпоративного телевидения.
ОПЕРЕЖАЮЩЕЕ НАРАЩИВАНИЕ ЕМКОСТИ СЕТИ
Другой подход к обеспечению качества передачи видео состоит в том, что владелец сети повышает скорость имеющихся каналов таким образом, чтобы быть уверенным в том, что реальный видеотрафик будет всегда меньше, чем пропускная способность составляющих ее маршрутизаторов и каналов связи. Такой подход, конечно же, приводит к дополнительным затратам по сравнению с методом резервирования ресурсов, поскольку заставляет владельца сети наращивать ее мощность опережающими темпами. Но вместе с тем при его применении эксплуатация сетей упрощается, так как метод несет в себе меньший риск человеческой ошибки.
Следует заметить, что метод опережающего наращивания емкости сети фактически применяется многими интернетпровайдерами — иначе мы бы не могли сегодня круглосуточно смотреть онлайнвещание видео в Интернете. Хотя, конечно, в основном к нему прибегают только те провайдеры, которые могут себе это позволить: например, расположенные в Москве или Санкт-Петербурге, где цены на Интернет достаточно низки и есть точки обмена трафиком.
АДАПТИВНОЕ ВЕЩАНИЕ ВИДЕО
Если бы эта статья писалась три года назад, то после предыдущего параграфа мне бы пришлось поставить точку. Однако с тех пор появилась еще одна интересная технология, применение которой положительно сказывается на качестве вещания видео по сетям IP. Речь идет о технологии адаптивного потокового вещания (в англоязычной терминологии — adaptive streaming). Эта технология позволяет подстраивать скорость доставки видео под состояние сети: при наличии широкой полосы пропускания видео будет транслироваться с максимальным качеством, а при снижении пропускной способности сети начинает передаваться менее качественный видеопоток — характеристики потока подбираются таким образом, чтобы он дошел до пользователя с минимальными потерями. Фактически технология адаптивного вещания является противоположностью ранее рассмотренной технологии резервирования сетевых ресурсов: первая позволяет подстраивать контент так, чтобы его можно было передать через сеть, тогда как вторая подстраивает сеть под задачу доставки контента.
В технологии адаптивного вещания видеопоток делится на множество небольших сегментов (частей) и кодируется одновременно с несколькими уровнями качества. Эти части обычно имеют продолжительность 2–4 с. На уровне видеокодека это означает, что каждый фрагмент не зависит от предыдущих или последующих частей. Таким образом, каждый фрагмент кодируется, а затем и демонстрируется на экране пользователя — независимо от других.
Сейчас технология адаптивного вещания переживает период «войны форматов»: свои форматы представили каждый из крупных игроков рынка. Adobe продвигает HTTP Dynamic Streaming (HDS), Apple — HTTP Live Streaming (HLS), Microsoft — Smooth Streaming. Все эти технологии, как следует из их названий, предполагают использование протокола HTTP для передачи данных между клиентом и сервером. Однако форматы передаваемых данных у каждой из этих технологий разные. Возможно, в ближайшее время отрасль внедрит единый для всех стандарт MPEG-DASH (см. Рисунок 2), который объединяет в себе преимущества всех вышеперечисленных технологий, но пока он не реализован ни одним из вендоров.
Технологию адаптивного вещания видео внедрили в своих сетях практически все операторы сетей доставки контента (CDN). Операторы CDN предоставляют услуги потокового вещания видео, ими можно воспользоваться для показа видео в Интернете. Для трансляции видео в частной сети можно лицензировать технологию CDN и построить свою собственную сеть CDN.
Ярослав Городецкий — генеральный директор CDNvideo. С ним можно связаться по адресу: gorod@cdnvideo.ru.