18
Дек

Каким бы хорошим не был Wowza Media Server, но у него есть одно очень неприятное (но вполне справедливое) неудобство — версия для разработчика ограничена 10 одновременными подключениями, а финансирование некоторых проектов не позволяет приобретать полноценную версию. Поэтому с самого момента работы с RTMP мною рассматривались различные варианты использования открытых разработок. Увы, более-менее рабочим решением до недавнего момента был Red5 — медиа-сервер, сделанный на платформе J2EE, который оставлял впечатление тяжелого и неповоротливого монстра, а остальное и вовсе не выдерживало никакой критики.
Подробнее →

06
Май

Адаптивное псевдо-потоковое вещание

Написал Максим Крентовский в Новости

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

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

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

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

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

Интересный момент произошел в развитии направления обработки и преобразования видео. Возникла задача по наложению не статической картинки водяных знаков, а полноценного видеоролика (например, титров или рекламы или динамического лого).

На входе у нас есть:

  • начальный видеоролик
  • последовательность кадров титров для наложения в виде серии PNG-кадров (можно использовать и видео, но возникают вопросы с альфа-каналом)

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

Следующая страница →