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

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

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-кадров (можно использовать и видео, но возникают вопросы с альфа-каналом)

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

На каникулах удалось соорудить tv.devimpress.com – видео-архив выступлений специалистов в области ИТ, который, по сути, является проапгрейженой частью видеороликов с TulaVideo.net (изменен дизайн, обновлен псевдо-потоковый транслятор, подправлена система управления, использована более приятная шкурка проигрывателя). Выглядит это примерно так:

Просто и безо всяких наворотов доставить HD-видео. Ссылки ведут на плейлист, который содержит ссылку на видео. Конечно, HTTP не самый хороший протокол для доставки медиа-контента, но тут уж с полноценным VoD-сервисом мне бодаться будет тяжело.

Выглядит все так:

Итак, под проект мне выделили интересную железку PBI DCH-4000P-42S , которая забирает видео-потоки со спутника (в DVB, соответственно), перепаковывает их в RTP и отдает в сеть. Простая, но аккуратная и полезная железка, которая заработала после пары вразумлений меня тех поддержкой методом тыканья в инструкцию. Ну что поделать, не люблю читать вдумчиво, когда процедуру можно отрисовать.
Подробнее »»

Сейчас все силы и чаяния брошены на работу с ТулаВидео – региональным медиа-сайтом. В принципе, это сумма того, чем пришлось заниматься почти все лето.

Подробнее »»

После краха с отработанной методикой сжатия h.264-кодеком, которая давала для Flash-а весьма недурственный результат, захотелось понять, почему iPhone, а, точнее, Appl-овский декодер столь привердлив, нежели VLC и прочие. После серии экспериментов удалось исключить пару параметров, которые не давали заметного выигрыша по сжатию, но весьма раздражали iPhon-овский медиа-проигрыватель.
Подробнее »»

В общем случае, пережатие DVD дисков – процедура банальная и решаемая большим количеством платного и не очень ПО. Но в моем частном случае задача стояла в автоматизации процесса таким образом, чтобы оператор совершал минимальное число телодвижений. В результате к системе перекодирования из предыдущей записи был создан аналогичный интерфейс для преобразования видео с DVD.

Собственно, перекодирование осуществляется двумя командами (если у нас двупроходное перекодирование, разумеется):

Для получения сведения о треках можно воспользоваться утилиткой lsdvd. Видео и аудио битрейты подбираются в зависимости от желаемых размеров файла.

Знающие люди рекомендуют использовать коде Xvid для DVD-видео как дающий наилучшее качество при прочих равных характеристиках. Но ничто не мешает потом при помощи ffmpeg привести к любому нужному формату, в том числе и H.264/AAC, используемый в Flash-вещании.

За последнее время накопилось достаточно работ, которые подошли к определенной вехе и вполне достойны, чтобы быть представлены в портфеле проектов.
Подробнее »»