Телеспутник
Телемультимедиа

Интернет-журнал по широкополосным сетям и мультимедийным технологиям

О мультикасте как технологии передачи видео в интернете


О. Жернакова

.

Большинство неспециалистов скажут, что технология групповой передачи - мультикаст, - которую применяют операторы IPTV для организации телевещания в своей сети, совершенно не годится для интернета. Маршрутизатор должен догадаться, куда достаточно отправить только одну копию пакетов, а куда ничего отправлять не нужно. Если "ума" у маршрутизатора не хватает, он начнет вещание во всех направлениях, и это, конечно, недопустимо. Поэтому обычно передача видео в интернете подразумевает установку связи точка-точка между получателем информации и вещательным сервером (то есть использование технологий юникаст). Если сто человек захотят смотреть одно и то же, например какой-то телеканал, транслирующийся в интернете, каждый из ста установит отдельное соединение с сервером и получит "свой" поток. Даже если все эти сто получателей находятся неподалеку - например в сети одного провайдера ШПД, все равно через сеть в их направлении идет сто одинаковых персональных пакетов. Юникаст плох как для сети (перегружает каналы связи), так и для вещательного сервера, которому нужно отправлять множество одинаковых потоков.

Одна из компаний, которые занимаются доставкой видео - Octoshape - заявляет, что адаптивное потоковое видео через HTTP (транспортный протокол TCP) и юникаст - это тупиковые пути для передачи видео в интернете, так как с их помощью невозможно обеспечить массовое распространение видеохорошего качества за разумные деньги. Как и внутри операторской сети, в общем интернете нужно использовать UDP и мультикаст.

От пиринга к мультикасту

Компания Octoshape была основана в 2003 году в Дании и с самого начала занималась различными технологиями оптимизации передачи видео в интернете, в частности участвовала в соответствующем проекте Европейского вещательного союза. Изначально с целью снижения нагрузки на вещательный сервер рассматривалcя пиринг (когда сами пользователи передают друг другу кусочки информации, как это сделано в технологии Bit Torrent). Однако исследования показывают, что в этом случае трудно реализовать вещание в реальном времени (live) и обеспечить его качество. Все равно придется устанавливать достаточное количество поддерживающих серверов. Поэтому со временем была предложена другая технология - для передачи данных используются только специальные серверы, но, как и в пиринге, клиент подключается сразу к нескольким, получает от них отдельные кусочки информации и складывает их. Такое сложение, конечно, подразумевает использование специального клиентского приложения. И тем самым ограничивает число конечных пользователей. Но, по мнению Octoshape, выигрыш в качестве и эффективности получается настолько заметным, что и операторы ШПД, и контент- провайдеры оказываются заинтересованными в таком решении.

Свою технологию передачи компания называет мультикастом и настаивает на том, что это именно действующий мультикаст в открытом интернете. Мы встретились со специалистами компании Octoshape во время выставки IBC в Амстердаме и исходно были настроены довольно скептически. Однако доводы компании кажутся интересными, а проблемы, которые они отмечают в "мейнстриме" интернет-видео, несомненно, заслуживают того, чтобы над ними задуматься. Более того, компания реализовала несколько проектов ОТТ на базе своей "мультикастовой" технологии.

Тезис первый: HTTP плох для передачи видео. Нужно использовать приложения на базе UDP

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

Обычно считается, что у http-вещания есть три не очень серьезных недостатка.

  • Во-первых, постоянный обмен служебной информацией требует дополнительной полосы пропускания. По данным компании SPB TV ее доля около 10%.
  • Во-вторых, вещание в http больше отстает от реального времени. Это заметно для спортивных трансляций.
  • В-третьих, если речь идет об адаптивном потоковом http, то увеличиваются затраты на оборудование - кодеры и серверы, хранящие видео с разным вариантом битрейта.
Однако, по мнению специалистов Octoshape, у HTTP есть другая проблема - принципиальная невозможность достижения высокой скорости передачи. Предел обусловлен двумя параметрами: потерями пакетов, которые периодически случаются, и временем, проходящим от запроса потерянного пакета до его повторного получения от сервера. По мнению специалистов компании, в случае интернет-вещания на максимальное расстояние (на весь мир) верхний предел скорости находится около 600 kbps - то есть о качестве, сравнимом с телевизионным, говорить не приходится.

Интернет-протоколы с подтверждением получения пакета в первом приближении работают так: после получения каждого пакета клиент сообщает серверу, что все хорошо и можно слать следующий. Время, проходящее от запроса до получения ответа, называется RTT (round time trip). Размер пакета - это параметр TCP Window size. TCP Window size определяет количество данных, которое может находиться в процессе доставки до получения сервером очередного подтверждения. Допустим, TCP Window = 64KB, а время, которое нужно для доставки пакетов от сервера = 50ms. Тогда RTT=100ms, а максимально возможная скорость доставки = 640KB в секунду, то есть приблизительно 5Mbps. TCP Window size определяется сервером и постоянно меняется. Сервер его увеличивает, пока что-нибудь не потеряется. Тогда сервер предполагает, что где-то перегрузился канал, переходит сразу же на маленькие пакеты, и все начинается с начала. Потери пакетов происходят по разным причинам, но ответ сервера всегда одинаков - уменьшить передачу. В результате занимаемая сигналом полоса все время колеблется. Поскольку одновременно в канале идет несколько сигналов, использующих TCP, то эти колебания случайным образом накладываются и периодически мешают друг другу.

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

Тезис второй: из одной точки нельзя организовать передачу видео с заданным качеством, поэтому нужно одновременно использовать несколько источников

Пропускная способность каналов в интернете постоянно меняется. Если видео клиенту отдает один конкретный сервер, то с этим практически ничего поделать нельзя. Метания и подключения к другому "запасному" серверу спасут при падении конкретного канала связи, но и новый канал будет подвержен флуктуациям. Обычно задача решается просто - выбирается заведомо низкая скорость передачи, чтобы клиент наверняка все получил и увидел, пусть и в плохом качестве. По мнению представителей Octoshape, вопрос можно решить подключением сразу к нескольким вещательным серверам. Доступ к одному ухудшится, к другому - улучшится, а в среднем получится относительно стабильный суммарный канал. Octoshape предлагает использовать 20 вещательных серверов для одной видеотрансляции. Клиентское приложение в реальном времени выбирает из них 4 источника в зависимости от текущего состояния сети - задержек, потери пакетов и пр. Соответственно, если требуется передать поток 1Mbps, каждому серверу нужно отдавать по 250 kbps. Ну а для того, чтобы учесть объективные ограничения - у одного пользователя канал хороший, у другого помедленнее, - серверы выдают потоки разного качества. То есть видео предварительно обработано и подготовлено в нескольких (трех) вариантах битрейтов, как это обычно и делается. Естественно, от всех четырех серверов клиент получает пакеты-кусочки одного видеофайла конкретного качества. В решении Octoshape серверы объединены в некоторую облачную структуру. При этом эти 20 серверов, обслуживающих отдачу видео, могут находиться достаточно далеко и быть частью других облачных решений. Так как от каждого вещательного сервера требуется только часть данных, а протокол UDP позволяет не ждать подтверждения получения, эта удаленность не создает особых проблем. В отличие от традиционных решений, качество не оказывается прямо пропорционально расстоянию, и нет необходимости использовать CDN-серверы, находящиеся как можно ближе к клиенту. Несколько серверов позволяют организовать и быстрое начало трансляции - в момент включения поток могут отдавать большее количество источников, и в результате буфер, необходимый для старта показа, соберется быстрее.

Тезис третий: для экономии полосы пропускания нужно использовать мультикаст

В настоящее время существует технология мультикаста в сети интернет, когда сервер знает, какой группе адресов он должен послать одинаковую информацию, а "умные" маршрутизаторы по дороге получают специальные указания и пересылают общие пакеты в единственном экземпляре, если они идут по одному и тому же маршруту. Соответствующие маршрутизаторы разрабатывают и Juniper, и Cisco. Однако пока такими "умными" являются не все устройства в сети. Если сеть интернет кардинально "поумнеет", у мультикаста будет большое будущее, и, возможно, интернет станет основной средой передачи телевидения.

У нас пока не получится.

Как комментирует Вячеслав Калашников, написавший очень интересный материал о мультикасте в интернете, "для доставки mcast вам могут использоваться VPN туннели, терминируемые на вашем оборудовании, а в некоторых случаях, если оператор контента договорится с провайдером, то терминируемые оборудованием провайдера. Так же между оператором контента и провайдером может быть линк, это позволяет не использовать VPN совсем. В общем же случае передача mcast через интернет без туннелей сегодня невозможна".

octoshape.com По информации Octoshape, в некоторых регионах мира мультикаст в интернете возможен. Octoshape запускал тестовые трансляции до конечного абонента в США (интернет-вещание CNN), но увидеть, как это работает, у нас не получилось - в России услуга недоступна. В интернете нашлись возмущенные отзывы пользователей из США, которые не хотели устанавливать дополнительный плеер для просмотра CNN, но вот отзывы довольных контентовладельцев нам не встретились.. В прочих странах мира Octoshape предлагает доставку видео на вещательный сервер оператора, и в этом не отличается от других компаний, занимающихся доставкой телесигнала для его последующей раздачи в IPTV. Но это означает, что контент-провайдеры опять не смогли выйти к конечному пользователю напрямую и по-прежнему зависят от операторов. Превращение операторов ШПД в "трубу" откладывается, а обычные бизнес-схемы платного ТВ пока ничто не может заменить.

Octoshape активно пропагандирует свой подход и размещает большое количество материалов о мультикасте, например, это описание своего подхода к доставке контента. Может быть, и в России уже пора думать о таких технологиях.

Рубрика:  Технологии
Материалы по теме:   VPN   OTT

Самые популярные статьи:






    Комментарии

    Оставить комментарий

    * Адрес электронной почты используется только для связи с Вами и не будет отображаться на сайте или использоваться при рассылке.

    Нажмите мышкой на синий квадрат:


    Последние новости

    Последние обзоры


     Все права защищены © ООО «Телеспутник», 2006-2014. Любое использование материалов допускается только с согласия редакции.