Готовность к большим потокам

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

Итак, устройство есть, подключенный непосредственно ноутбук показывает благополучную трансляцию пяти каналов. Втыкаю его прямиком в сервер. Теперь осталось всего-то ничего — пробросить потоки в контейнер OpenVZ, включить там перекодирование в формат H.264/AAC при помощи VLC и полученный RTP-поток устремить на Wowza Pro, который благополучно завернет видео в RTMP и разбросает по клиентским Flash-проигрывателям. Вроде как несложно.

Началось все с пробрасывания потока внутрь контейнера. Как всегда, я поверхностно прочитал инструкции и потому сразу же зарубил вариант с виртуальными интерфейсами veth, а зря. Помыкавшись, оказалось, что мультикаст — штука своеобразная и маршрутизировать ее без дополнительных костылей вроде специальных демонов, что неприятно. Но и с демонами тоже не все хорошо — один просто работать отказался, другой сослался на то, что veth-интерфейс какой-то странноватый и он не будет с ним работать. То есть фиг. В конце концов, в опциях сетевых интерфейсов есть параметр mc_forward но он… только для чтения. А банальная задача в лоб при помощи route маршрута так же не дала никаких результатов.

На следующий день появилась простая до ужаса идея (что очень жутко непростительно поздно для человека, который считает, что имеет представление, как работают сети и протокол TCP/IP в частности), суть которой заключается в следующем: объединяем физический интерфейс с конвертера и виртуальный интерфейс бриджом, причем назначаем представлению виртуального интерфейса внутри контейнера (он видится как обычный eth0) адрес шлюза для DVB-железяки. Делаю, попутно снимая со всех интерфейсов флаг rp_filter, который по умолчанию включен — на него матерились все, кто настраивал мультикаст под Линуксом, ну а мне не страшно — в то же сети только одна доверенная железка. Проверил результат tcpdump-ом — поток идет, причем вполне нехлипкий, за сутки набегает несколько сот гигабайт.

Теперь VLC. С ним мне подкинули поросенка разработчики Debian. В стабильном выпуске была версия 8.6а, в тестируемом и нестабильном — 8.6h, на сайте — 9.4. Причем восьмые версии не хотели даже играть в сторону Wowza и обычные статические файлы, а RTP-потоков не видели в упор. Помогла сборка из исходников последней версии — статические файлы начало проигрывать, Wowza дает поток, все хорошо, но… RTP-потоки опять не видятся. Пишу сосредоточенный пост в ЖЖ, дают один толковый совет, но, увы, соответствующий только одному варианту решения проблемы.

На следующий день прописываю внутри контейнера маршрутизацию мультикастовой подсети на интерфейс, с которого и идет вещание. Может быть это, а может другое стечение обстоятельств (например, упущенный rp_filter=1), но потоки вдруг начинают читаться — VLC вдруг опознает потоки и даже пытается что-то перекодировать, но получается плохо — вместо картинки непонятное шевеление, звук отсутствует. Что виновато — большие потери исходных пакетов (когда их больше 5% — смотреть невозможно независимо от кодека), гонки по таймингу (когда VLC не успевает отрабатывать данные и грохает их раньше, переходя к более свежим) или нюансы работы VLC в условиях нестабильного дистрибутива в рамках контейнера — пока выяснить не удалось, поскольку железка в спешно порядке потребовалась для демонстрации IP TV (это еще одна очень интересная тема, которую буду поднимать в блоге). Как вернут — продолжу изыскания.