Управление качеством видео

Немного истории

Передача видео на расстояние долгое время была недостижимой мечтой для человечества. Футуристы XIX века предсказывали такую возможность и предполагали, что это изменит мир. По своему значению мечта об удаленном видении (т.е. телевидении) была сродни мечте о полете по воздуху – ее очень долго, но безуспешно, пытались реализовать. Удалось это сделать лишь около 70 лет назад Владимиру Козьмичу Зворыкину, эмигранту из России, жившему и работавшему в США. Массовое же распространение же телевидение получило уже после Второй Мировой войны. Таким образом, телевидение примерно на полвека опередило в своем первоначальном развитии Интернет, который был изобретен в 70-х, а массовое распространение получил в 90-х годах XX века. Так что в первые полвека своего существования телевизионные технологии были единственным возможностью передать видео на расстоянии.

Однако, массовое распространение Интернета и частных IP-сетей, рост скоростей подключения и пропускных способностей каналов натолкнули инженеров на мысль о возможности передачи видео через Интернет или IP-сети. Первые опыты передачи видео по IP-сетям в университетских лабораториях проводились в середине 90-х годов, но вызывали скепсис у представителей бизнеса. Я в это время уже занимался этой тематикой и хорошо помню слова одного из авторитетных экспертов по телекоммуникациям того времени: «IP – это протокол, не предназначенный для передачи видео». Но уже в 1997 году появился первый коммерческий продукт для потокового вещания видео в Интернете – сервер RealVideo. Примерно тогда же появились и первые системы корпоративной видео-конференц-связи, поддерживающие IP в качестве транспорта – хотя основной технологией организации таких конференций все равно оставалась ISDN.

Следующей вехой в развитии технологий потокового вещания видео стал 2002 год, когда во Flash-плеер, установленном к тому времени на 90% компьютеров, впервые появилась возможность проигрывания видео. А в 2005-м году на базе этой технологии был запущен видеохостинг YouTube, который быстро приобрел массовую популярность и был продан компании Google через 21 месяц после основания за рекордные для отрасли 1,65 млрд долларов. Таким образом технология Flash стала на несколько лет де-факто стандартом для показа видео в Интернете.

Подходы к обеспечению качества передачи видео

Как же получилось, что технология передачи видео по IP-сетям, которой в середине 90-х годов попросту не было и в помине, оказалась общедоступной уже через десятилетие? Ведь высказывание о неприспособленности IP-сетей для передачи видео казалось в 1996 года вполне логичным. Действительно, на тот момент пропускные способности каналов были низкими, а видеокодеки обеспечивали довольно посредственный уровень компрессии и при этом были чувствительны к потерям пакетов. Более того, не существовало никаких гарантий качества доставки контента: пакеты, содержащие видео, могли теряться из-за перегрузок портов маршрутизаторов или потерь на каналах IP-сети. В общем, идея передачи видео по тогдашним IP-сетям была столь же далеко от реальности, как идея перевозить слонов на метро в час пик, с гарантированной скоростью и в больших количествах.

Однако, перспектива показа видео по IP-сетям была слишком заманчива, чтобы отказаться от нее. Инженерная мысль заработала, и мы увидели множество идей о том, как можно было бы обеспечить качество доставки видео. Все эти идеи можно условно разделить на три типа:

1. Резервирование сетевых ресурсов
2. Опережающее умощнение сети
3. Адаптивное вещание видео

Об этих подходах и конкретных технологиях, их реализующих, мы и расскажем ниже.

Резервирование сетевых ресурсов

Начнем, с первого подхода – резервирование сетевых ресурсов для пропуска видеотрафика, т.е. фактически его приоритизации. Механизмов было разработано несколько, остановимся на одном из них - протоколе RSVP (Resource ReSerVation Protocol, протокол резервирования сетевых ресурсов), который позволяет зарезервировать полосу пропускания IP-канала от источника до назначения перед тем, как пытаться пропускать видео по сети.

Работает протокол RSVP следующим образом (см. Рисунок 1): узел-отправитель до передачи данных, требующих определённого нестандартного качества обслуживания (например, постоянной полосы пропускания для передачи видеоинформации), посылает по сети специальное сообщение о пути (path message), содержащее данные о типе передаваемой информации и требуемой пропускной способности. Оно передаётся между маршрутизаторами по всему пути от узла-отправителя до адреса назначения, при этом определяется последовательность маршрутизаторов, в которых необходимо зарезервировать определённую полосу пропускания. Маршрутизатор, получив такое сообщение, проверяет свои ресурсы с целью определения возможности выделения требуемой пропускной способности. При её отсутствии маршрутизатор запрос отвергает. Если требуемая пропускная способность достижима, то маршрутизатор настраивает алгоритм обработки пакетов таким образом, чтобы указанному потоку всегда предоставлялась требуемая пропускная способность, а затем передаёт сообщение следующему маршрутизатору вдоль пути. В результате, по всему пути от узла-отправителя до адреса назначения резервируется необходимая пропускная способность с целью обеспечения запрашиваемого качества обслуживания, а пакеты, содержащие фрагменты видео, гарантированно доходят от источника до потребителя, качество видеопотока при этом не снижается.

Однако, проблема внедрения протокола RSVP, как и всех протоколов управления трафиком, заключается в том, что их применение при пропуске трафика между двумя сетями или большим их числом практически невозможно.  Существует очень мало примеров, когда владельцы сетей договариваются о сквозной поддержке механизмов управления трафиком – эксплуатация этих механизмов на стыках сетей оказывается затруднительной из-за сложности процесса поиска и устранения возможных проблем. Поэтому применение метода резервирование сетевых ресурсов для обеспечения качества видео возможно только в рамках одной корпоративной или операторской сети. Поэтому область применения этого метода ограничена, как правило, внутренними задачами организаций. Примерами таких задач являются построения корпоративных систем видео-конференц-связи или корпоративного телевидения.

Опережающее умощнение сети

Другой подход к обеспечению качества передачи видео состоит в том, что владелец сети расширяет пропускные способности своих каналов таким образом, чтобы быть уверенным в том, что реальный видеотрафик будет всегда меньше, чем пропускная способность составляющих ее маршрутизаторов и каналов связи. Такой подход, конечно же, несет в себе дополнительные затраты по сравнению с методом резервирования ресурсов, поскольку заставляет владельца сети наращивать ее мощность быстрее. Но, с другой стороны, при таком подходе эксплуатация сетей упрощается, т.к. метод несет в себе меньший риск человеческой ошибки.

Следует заметить, что метод опережающего умощнения сети, фактически, применяется многими интернет-провайдерами – иначе мы бы не могли сегодня круглосуточно смотреть онлайн-вещание видео в Интернете. Хотя, конечно, в основном его применяют только те провайдеры, которые могут себе это позволить: например, расположенные в Москве или в Санкт-Петербурге, где цены на Интернет достаточно низки и есть точки обмена трафиком.

Адаптивное вещание видео

Если бы я писал эту статью три года назад, то после предыдущего параграфа мне бы пришлось поставить точку. Однако, с тех пор появилась еще одна интересная технология, положительно сказывающаяся на качестве вещания видео по IP-сетям. Речь идет о технологии адаптивного потокового вещания (в английской терминологии – adaptive streaming). Эта технология позволяет подстраивать скорость доставки видео под состояние сети – если доступна широкая полоса пропускания, видео будет показано в максимальном качестве, а если пропускная способность сети падает, то начинает показываться менее качественный видеопоток – подбирается поток в таком качестве, в котором он дойдет до пользователя. Фактически, технология адаптивного вещания является противоположностью ранее рассмотренной технологии резервирования сетевых ресурсов: если первая позволяет подстраивать контент так, чтобы его можно было передать через сеть, то вторая подстраивает сеть под задачу доставки контента. 

В технологии адаптивного вещания видеопоток делится на множество небольших сегментов (частей) и кодируется одновременно с несколькими уровня качества. Эти части обычно имеют продолжительность две-четыре секунды. На уровне видеокодека это означает, что каждая часть не зависит от предыдущих или последующих частей. Это позволяет каждой части быть закодированной независимо от других частей, а затем продемонстрированной на экране пользователя.

Сейчас происходит «война форматов» в технологии адаптивного вещания: свои форматы представили каждый из крупных игроков рынка. Adobe продвигает технологию HTTP Dynamic Streaming (HDS), Apple - технологию HTTP Live Streaming (HLS), Microsoft – Smooth Streaming. Все эти технологии, как следует из их названий, предполагают использование протокола HTTP для передачи данных между клиентом и сервером. Однако форматы передаваемых данных у каждой из этих технологий разные. Возможно, в ближайшее время индустрия внедрит единый для всех стандарт MPEG-DASH, который объединяет в себе преимущества всех вышеперечисленных стандартов, но пока его реализации нет ни у одного из вендоров.

Технологию адаптивного вещания видео внедрили на своих сетях практически все операторы сетей доставки контента (CDN). Операторы CDN предоставляют услуги потокового вещания видео, ими можно воспользоваться для показа видео в Интернете. Если же требуется показывать видео в частной сети, то есть возможность лицензировать технологию CDN и построить свою собственную сеть CDN.