Crystal TV – IPTV-OTT решение с собственной технологией доставки
Как и многие представленные на российском рынке OTT-платформы, решение Crystal TV охватывает весь диапазон задач организации видео-сервиса через интернет, от захвата видео-сигнала в систему до его демонстрации конечному абоненту на персональных мобильных устройствах и телевизионных приставках.
Платформа позволяет разворачивать полностью «софтовые» головные станции на базе серверной платформы Intel x64 под управлением ОС Linux или Windows Server. Клиентское ПО есть не только для популярных Android и iOS, но и для уже умирающих или умерших Pocket PC, Symbian и т.п. Также есть клиенты для настольных систем: Windows и iOS, присутствует веб-интерфейс для доставки контента при помощи встроенных браузера и плеера.
Crystal TV обеспечивает авторизацию пользователей, биллинг (или интеграцию со сторонним биллингом), геофильтрацию по IP-адресу, VOD (со встроенным распределенным хранилищем), мониторинг и другие функции. В отличие от большинства конкурентов, платформа использует собственный протокол доставки видеоданных. Пока платформа не внедрена у крупных российских операторов, но собственный сервис Crystal TV уже превосходит по объему переданного трафика многих игроков рынка: в день сервис раздает порядка 30 – 40 терабайт данных.
ТММ: На кого ориентировано ваше решение?
М.Ф.: Наше решение – это в первую очередь платформа для построения ОТТ/IPTV-сервисов в операторских сетях. Проблема многих операторов в том, что сеть не настолько хорошо отлажена, чтобы работать с мультикастом. В этом случае канал просто не выдерживает того количества телеканалов, которое оператор пытается передавать. В теории, конечно, все должно работать, но на практике большое количество абонентов ситуацию сбивают: на сетевом уровне не все нормально отрабатывает, и достаточно одному абоненту подписаться на непопулярный канал, чтобы пакеты шли и всем остальным абонентам.
Для решения этой проблемы операторы используют гибрид юникаста с мультикастом, когда самые популярные каналы, которые смотрит большинство, транслируются с помощью мультикаста, а каналы, которые смотрит один абонент на дом, доставляются по юникасту, не забивая тем самым канал до всех остальных абонентов. Но вместо этого можно использовать наше решение.
ТММ: Почему вы пошли по пути разработки собственного протокола доставки, а не пошли по пути, который выбрали ваши конкуренты? Чем вас не устроил TCP?
М.Ф.: 99% OTT-решений, представленных на рынке, действительно строятся на основе индустриальных протоколов доставки видео. Самый распространенный среди них – HLS; также широко представлен Adobe Flash. До недавнего времени третьим лидером был Microsoft Silverlight, но в последних версиях своих продуктов Microsoft постепенно убирает его поддержку, т.е. можно констатировать смерть технологии, таким образом, лидирующих решения остается два. Глобально обе эти технологии (как и другие, менее популярные) построены практически идентично: они работают на уровне сетевого протокола TCP. У него множество плюсов, в частности, он легко масштабируется, позволяя доставлять данные до конечных пользователей в первозданном виде через неуправляемые сети. Но есть и огромный минус – поведение протокола в мобильных и радиосетях (к ним относится, в том числе, и Wi-Fi). TCP просто не предназначен, чтобы в этих условиях обеспечить гарантированный битрейд передачи. Чтобы обойти эту проблему, был разработан адаптивный битрейд, но и он не решает всех проблем.
Каждый пакет, отправленный посредством TCP, требует обязательного подтверждения клиента о доставке. Обязательный обратный канал имеет много слабых мест, которые как раз и проявляются в радиоподвижных сетях, особенно при большом удалении устройства от базовой станции. Радиопередатчик базовой станции на порядок мощнее, чем передатчик на мобильном устройстве, соответственно, при увеличении расстояния между ними возникают ситуации, когда базовая станция еще в состоянии передавать необходимое количество данных, а клиент уже просто не может подтвердить их получение, хотя он их отлично принимает. Сервер, не получая подтверждения, повторяет отправку тех же пакетов, хотя вполне мог бы обеспечить стриминг.
Еще один пример – большое количество устройств, подключенных к одной базовой станции. При обмене данных станция по кругу опрашивает подключенные устройства, отводя на каждое из них определенный сегмент времени. При увеличении количества подключенных к базовой станции клиентов промежуток времени на каждое из устройств становится меньше. Если в этих условиях удаленный сервер передает одному из клиентов большие пакеты данных, вполне возможна ситуация, когда весь пакет за отведенный на устройство временной слот не передать, т.е. приходится ждать следующего круга опроса, чтобы его завершить, а потом еще одного – чтобы передать обратно подтверждение о доставке. Все это приводит к серьезному падению скорости. По нашим замерам в «тепличных» условиях (при отсутствии интерференции с другими сетями – фактически, базовая станция в чистом поле — и при подключении только одного клиента) больше 4 – 5 Мбит/с передать по радиосети не получается. Не удивительно, что Wi-Fi не позволяет смотреть качественное HD (1080). Для SD такого потока более чем достаточно, для сильно сжатого 720p, в принципе, тоже. Но HD (сохранив при этом качество) в такой поток уже не сжать.
И здесь мы переходим к тому, что TCP в ближайшие годы, по крайней мере, в рамках задачи доставки видео, себя изживет.
ТММ: И каким же вы видите решение проблемы?
М.Ф.: Использование другого транспортного сетевого протокола UDP (а точнее, надстройки поверх него – Reliable UDP) позволяет решить проблемы, возникающие на уровне TCP.
Обычный UDP используется в мультикаст-сетях: сервер осуществляет рассылку без какого-либо контроля получения пакетов. Соответственно, если клиент пакеты не получает, у него на экране возникают помехи. В качественных широкополосных сетях это не проблема, поскольку потери пренебрежимо малы. В радиосетях ситуация совсем иная. Потери, безусловно, здесь есть, т.е. необходимо искать какое-то более сложное решение, имеющее все преимущества UDP (т.е. не требующее такой тотальной досылки, как в TCP), но позволяющее фиксировать потери пакетов. Таким образом, мы создали собственную реализацию Reliable UDP (Reliable UDP – не стандартизован в отрасли, т.е. допустимы различные реализации протокола, — Прим. ред.) – решение, строящееся «поверх» UDP.
Надо отметить, что мы не одни смотрим в этом направлении, сейчас уже многие компании этим занимаются. В частности, в этом направлении смотрят крупные CDN-щики. В качестве референса могу упомянуть, что около 2 месяцев назад Akamai приобрел стартап Octoshape. Они занимаются примерно тем же, хоть и не так глубоко с точки зрения охвата всей технологической цепочки трансляции видео. Их специализация — именно транспорт посредством UDP.
Я думаю, в течение года – двух UDP станет очень горячей темой. CDN-щики и другие игроки рынка уже постепенно понимают: те лимиты, которые несет с собой TCP, к сожалению, никуда не денутся, и с этим надо что-то делать. К слову, небезызвестный Skype также работает на базе UDP.
ТММ: Чем отличается именно ваша реализация RUDP?
М.Ф.: Мы выбрали специфическую модель работы транспорта. И «Reliable» прослойка поверх UDP тоже хитрая, там очень много эвристики. Встроенные в наш транспортный протокол эвристические механизмы позволяют анализировать поток, выявляя пакеты, почти не влияющие на качество итогового видео, и оптимизировать передачу с учетом результатов анализа. При необходимости выполняется повторная отправка только потерянных важных пакетов (в отличие от TCP, который переотправляет все). В сетях операторов фиксированной связи по сравнению с обычным HLS через TCP наш способ доставки дает прирост передаваемого трафика до 25%, при этом в мобильных и радиосетях объем передаваемого трафика возрастает до 2-3 раз. На данный момент выпущено уже третье поколение нашего RUDP. Т.е. за 5 лет разработки мы делаем уже третий качественный скачок. И по нашему опыту каждый скачок добавляет нашему сервису (Crystal.TV, а также сервисам партнеров на той же платформе, — Прим. ред.) порядка 10 – 15 % доставляемого трафика. Т.е. мы на сетевом уровне чуть-чуть меняем наш протокол доставки, а статистика трафика вдруг увеличивается на 10%. Это говорит о том, что ровно в тех же условиях сетевой протокол работает лучше, и мы можем доставлять больше трафика. На мой взгляд, это и есть показатель качества видеосервиса – количество данных, которые ты можешь клиенту доставить в непростых (реальных) сетевых условиях. В «лабораторной» сети всегда все хорошо, а в реальной жизни постоянно что-то происходит, то на серверном уровне, то на сетевом, то на последней миле.
ТММ: Вы упомянули, что ваше решение охватывает больший круг задач по трансляции видео, нежели у того же Octoshape. Что это дает пользователям (зрителям)?
М.Ф.: Схема работы упомянутого выше Octoshape такова: на клиентском устройстве устанавливается тонкий прокси-клиент, который получает RUDP-поток и ретранслирует его уже в TCP стандартному компоненту, присутствующему в каждой ОС (в каждой ОС он свой), по одному из индустриальных протоколов. У нас все клиенты «родные», т.е. мы можем строить приложения более гибкие и быстрые, и с более широким функционалом (по сравнению со стандартными компонентами ОС). Таким образом, наличие «нативных» клиентов позволяет нам предложить пользователям более широкий функционал. Кроме того, проксирование через тонкий клиент увеличивает время открытия видеопотока, что чувствительно ухудшает пользовательский опыт в случае частого переключения телеканалов.
ТММ: В каком направлении вы собираетесь развиваться?
М.Ф.: Мы продолжим усовершенствование транспортного протокола. Помимо этого, наши текущие разработки направлены как на расширение функционала платформы, так и на реализацию клиентских приложений для новых операционных систем. В списке новой функциональности можно отметить функцию сохранения VoD или PVR контента на пользовательское устройство для его просмотра в режиме offline. В части разработок для новых ОС самым значительным проектом является поддержка ОС Tizen, но которой базируются все современные smart TV устройства производимые компанией Samsung.
