img
img18 апреля 2013 в 20:58

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

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

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

Большинство неспециалистов скажут,что технология групповой передачи - мультикаст, - которую применяют операторы 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 (roundtime trip). Размер пакета - это параметр TCP Window size. TCP Window sizeопределяет количество данных, которое может находиться в процессе доставки до получения сервером очередного подтверждения. Допустим, TCPWindow = 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 активно пропагандирует свой подход и размещает большое количество материалов о мультикасте, например, это описание своего подхода к доставке контента. Может быть, и в России уже пора думать о таких технологиях.

Подписка на рассылку

Подпишитесь на рассылку, чтобы одним из первых быть в курсе новых событий