Смотрим Raspberry Pi: часть 3

Теперь, когда мы немного прояснили с форматами, организуем передачу видеопотока с машины cam, где стоит Rpi, на ноут bingo. Будем смотреть различные варианты транспортных протоколов.

NetCat

Поиграем со знаменитой хакерской программой netcat, которая обеспечит TCP транспорт для медиаданных нашей камеры на Rpi.

Вначале запускаем на ноуте:

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

Как откомпилировать ffmpeg под Убунту подробно написано здесь.

Далее, запускаем на Rpi:

Здесь поток с видеокамеры через netcat отправляется на порт 5555 ноута bingo и плеер на bingo показывает кино. Отлично.

По умолчанию netcat использует TCP. Попробуем поменять транспорт на UDP ключом -u:

Опс… картинка разваливается. Не нравится кодеку H264 протокол с негарантированной доставкой пакетов.

С вариантом TCP транспорта все работает, и формально можно заключить что задачу использования Rpi как клиента мы решили: принимающая сторона (сервер) принимает поток H264 через netcat и плеером смотрит фильм. Однако у этого метода есть существенный недостаток: сервер ничего не знает о параметрах кодека (а их может быть множество). Поэтому о параметрах нужно договариваться заранее, если клиент и сервер полностью под нашим контролем, или использовать один из способов передачи этих параметров. Один из таких способов — протокол SDP, описывающий медиаданные. Следующий шаг — использование SDP совместно с RTP.

RTP внутри ноута

RTP работает через UDP, но за счет вставки отметок времени поддерживает поток выровненным на принимающей стороне. Сразу скажу, что трансляция RTP с Rpi на ноут bingo у меня не пошла. Картинка не плеере не появлялась и было много сообщений об ошибках на принимающей стороне. Сразу возникло подозрение на avconv/ffmpeg из пакетов который стоит на Rpi — на ноуте-то я собрал его из исходников, а на Rpi — нет. Остановила необходимость разбираться с кросс-компилятором.

А пока запускаем RTP локально на ноуте, смотреть будем с его собственной камерой:

Пояснения к ключам команды:

• -r 25 частота фреймов;
• -s 320×240 размер картинки;
• — f video4linux2 входной формат видео (raw формат);
• -i /dev/video0 камера ноута, откуда идет поток;
• -vcodec h264 камера ноута дает raw формат, поэтому кодируем его со сжатием в h264;
• -f rtp выходной формат RTP;
• -an звук не нужен;
• rtp://bingo:1234 направляем поток RTP на этот адрес:порт (порт произвольный, адрес ноута).

После запуска ffmpeg выдаст нам данные RTP, которые как раз и нужны принимающей стороне:

Сохраняем их в файле laptop.sdp и запускаем плеер с этими параметрами:

Все нужное для работы плеер берет из SDP файла. Появляется картинка — все работает, трафик RTP крутится локально на ноуте. Здесь мы впервые использовали ffmpeg для перекодирования данных из raw формата в h264. RTP — удобный формат для передачи h264, поскольку слайсы h264 один к одному ложатся в пакеты RTP которые имеют отметку времени.

Raspivid -> ffmpeg -> RTP

Вернемся к Rpi и попробуем запустить RTP с этой машины. Для того, чтобы отбросить любые сомнения, компилим ffmpeg под ARM архитектуру для Rpi. Самую краткую и понятную процедуру кросс-компиляции, включая предварительно установку кросс-компилятора и toolchains я нашел здесь. Все работает, только во время конечной сборки появляется ошибка о том, что не найдена библиотека libx264, несмотря на то что она уже скомпилирована и ключи компилятора (сама библиотека и путь к ней) проставлены правильно. Я вылечил это дополнительной опцией -ldl

Копируем полученные файлы на Rpi и включаем камеру через RTP:

Ffmpeg запускается из локального каталога pi/bin, перед этим я удалил все пакеты, связанные с ним. Замечу, что raspivid уже отдает поток в формате h264, поэтому никакого кодирования не требуется: ffmpeg использует простое копирование данных (кодек copy) и только пакует h264 в RTP пакеты. Следует заметить, что в данном режиме загрузка процессора ffmpeg’ом всего около 3%.

Сформированные данные RTP:

Сохраняем их в файле rpi.sdp на ноуте bingo и запускаем плеер:

Все работает. Точно так же принять поток можно и плеером VLC:

После всего проделанного, можно сделать следующий вывод: никогда не используйте ffmpeg из пакетов, всегда собирайте последнюю версию!