Дал интервью ресурсу OpenQuality.ru

Индустрию спасут массовые расстрелы (28.01.2011)
Ночные кошмары и риски, спагетти-код и баги-кровопийцы, “время-качество-деньги” и взаимодействие с заказчиком, идеальный код и программистский коммунизм, “тяп-ляпы” и “кризис перепроектирования” – вот далеко не полный перечень вопросов, затронутых в беседе.

Этот блог снова в деле, на новом хостинге, с новыми перспективами. Пришлось пожертвовать проектом TV.DevImpress, ну да не жалко, все равно не востребован. Накопилось много интересных наблюдений и фрагментов кода, буду потихоньку наверстывать упущенное.

Как известно, существуют множество способов вещания в сети:

1. потоковое вещание по протоколам RTSP/RTP
Ну, тут как бы все понятно — сигнализация о событиях (пауза, промотать, установить позицию и т.п.) передается по RTSP (TCP), собственно медиа-данные идут по RTP (UDP), соответственно, для них критично прийти вовремя, иначе их отбросят. Все бы хорошо — поток адаптируется под канал, не вовремя поступившие данные отбрасываются, задержки из-за стохастичности среды передачи минимизируются. Минус данного подхода — RTP не очень хорошо дружит с трансляцией адресов (NAT), что встречается сейчас на каждом шагу.

2. псевдо-потоковое вещание
Здесь подход очень прост — медиа-данные отдаются прямым потоком поверх HTTP, благо инфраструктура в большинстве случаев позволяет, а собственно процесс передачи контролируется параметрами запроса. По этому принципу работают многочисленные модули для FLV- и MP4-трансляций, например, мною часто используемый H264 Streaming module. Плюсы этого подхода — отсутствие преград в виде NAT-а, отсутствие необходимости дополнительных серверов для вещания (все решает только модуль к вэб-серверу), традиционный протокол и куча наработанных решений. Минусы — то, что поток передается поверх TCP, требующего подтверждение доставки каждого пакета, поэтому влияние ширины канала и качества прохождения пакета много больше, а реакция на пиковые нагрузки и задержки — много значительнее.

Разумеется, все вышесказанное привело к тому, что начались попытки создать третье решение, которое было бы как псевдопотоковый вариант, но без его недостатков. В частности, в блоге Алекса Зембелли предлагается решение с кодовым названием Smooth Streaming. Этот концепт прост, весьма интересен и представляет комбинацию обоих подходов: весь видеофрагмент бьется на мелкие части по 2 секунды. Части кодируются и хранятся в нескольких инвариантах с разным битрейтом, а потом, используя традиционный HTTP-протокол для доставки, передаются клиенту в зависимости от канала между последним и сервером. За счет этого и достигается та самая адаптивность, которой так не хватало обычной последовательной передаче данных. Конечно же, там не все так просто, но в двух словах именно так и есть.

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

Нашел пару интересных ресурсов

• Русскоязычный форум по потоковым серверам
• Как записать RTMP-поток при помощи Red5

А тем временем ждем с нетерпением открытие спецификации RTMP и появлению кучи хороших OS потоковых сервисов…