Современный способ потоковой передачи H.264 от Raspberry Cam

Я получил Pi B + и камеру Pi и сейчас пытаюсь найти наиболее эффективную (с низким ЦП) и самую низкую задержку конфигурацию для потоковой передачи видео в формате H.264 с камеры на мой домашний сервер.

Я прочитал следующее:

1. http://pi.gbaman.info/?p=150

2. http://blog.tkjelectronics.dk/2013/06/how-to-stream-video-and-audio-from-a-raspberry-pi-with-no-latency/comment-page-1/#comments

3. http://www.raspberrypi.org/forums/viewtopic.php?p=464522

(Все ссылки используют gstreamer-1.0 от deb http://vontaene.de/raspbian-updates/ . main.)

За последние годы в этом направлении было сделано много.

Первоначально мы должны были перенаправить вывод raspividв gst-launch-1.0(см. Ссылку 1).

Затем (ссылка 2) был создан официальный драйвер V4L2, который теперь является стандартным, и он позволяет напрямую получать данные без канала, используя только gstreamer (см. Особенно сообщение от towolf ». Sat 07 декабря 2013 г. 15:34 в ссылке 2):

Отправитель (Пи): gst-launch-1.0 -e v4l2src do-timestamp=true ! video/x-h264,width=640,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=1 ! gdppay ! udpsink host=192.168.178.20 port=5000

Приемник: gst-launch-1.0 -v udpsrc port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false

Если я правильно понимаю, оба способа используют GPU для декодирования H264, но последний является немного более эффективным, так как ему не нужно проходить через ядро ​​в другой раз, так как нет никакого канала между вовлеченными процессами.

Теперь у меня есть несколько вопросов по этому поводу.

1. Является ли последний все еще самый последний способ эффективно получить H264 от камеры? Я читал о том gst-omx, что позволяет gstreamer конвейеров, как ... video/x-raw ! omxh264enc ! .... Делает ли это что-то отличное от простого использования video/x-h264, или это может быть даже более эффективным? Какая разница?

2. Как узнать, какой плагин кодирования gstreamer на самом деле используется при использовании video/x-h264 ...конвейера? Кажется, это просто указывает нужный мне формат по сравнению с другими частями конвейера, где я явно называю компонент (код) (например, h264parseили fpsdisplaysink).

3. В этом ответе на ссылку 1 Микаэль Леписто упоминает «Я удалил один ненужный проход фильтра с потоковой стороны» , что означает, что он вырезал gdppayи gdpdepay. Что они делают? Зачем они нужны? Могу ли я действительно их снять?

4. Он также упоминает, что, указав caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96"параметры для udpsrcпринимающей стороны, он может запустить / возобновить потоковую передачу в середине потока. Чего добиваются эти заглавные буквы, почему эти конкретные выборы, где я могу прочитать о них больше?

5. Когда я делаю то, что предложено в вопросах 3 и 4 (добавление caps, удаление gdppayи gdpdepay), тогда моя задержка видео становится намного хуже (и, кажется, накапливается, задержка увеличивается со временем, и через несколько минут видео останавливается)! Почему это может быть? Я хотел бы получить задержку, полученную с помощью оригинальной команды, но также иметь возможность присоединения к потоку в любое время.

6. Я читал, что RTSP + RTP обычно используют комбинацию TCP и UDP: TCP для управляющих сообщений и других вещей, которые не должны быть потеряны, и UDP для реальной передачи видеоданных. В приведенных выше настройках, я на самом деле использую это, или я просто использую только UDP? Мне немного непонятно, заботится ли об этом gstreamer или нет.

Буду признателен за любой ответ хотя бы на один из этих вопросов!

Варианты:

1. raspivid -t 0 -o - | nc -k -l 1234

2. raspivid -t 0 -o - | cvlc stream:///dev/stdin --sout "#rtp{sdp=rtsp://:1234/}" :demux=h264

3. cvlc v4l2:///dev/video0 --v4l2-chroma h264 --sout '#rtp{sdp=rtsp://:8554/}'

4. raspivid -t 0 -o - | gst-launch-1.0 fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=SERVER_IP port=1234

5. gst-launch-1.0 -e v4l2src do-timestamp=true ! video/x-h264,width=640,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=1 ! gdppay ! udpsink host=SERVER_IP port=1234

6. uv4l --driver raspicam

7. picam --alsadev hw:1,0

Что нужно учитывать

• задержка [мс] (с запросом клиента и без него требовать больше кадров в секунду, чем с сервера)
• Процессор простаивает [%] (измеряется top -d 10)
• Клиент ЦП 1 [%]
• RAM [МБ] (RES)
• одинаковые настройки кодировки
• те же функции
  • аудио
  • переподключение
  • ОС-независимый клиент (vlc, webrtc и т. Д.)

Сравнение:

            1    2    3    4    5    6    7
latency     2000 5000 ?    ?    ?    ?    1300
CPU         ?    1.4  ?    ?    ?    ?    ?
CPU 1       ?    1.8  ?    ?    ?    ?    ?
RAM         ?    14   ?    ?    ?    ?    ?
encoding    ?    ?    ?    ?    ?    ?    ?
audio       n    ?    ?    ?    ?    y    ?
reconnect   y    y    ?    ?    ?    y    ?
any OS      n    y    ?    ?    ?    y    ?
latency fps ?    ?    ?    ?    ?    ?    ?

Только современный способ потока H264 в браузер с UV4L : нет задержки, ни конфигурации, с дополнительным аудио, опционально двухсторонняя аудио / видео. Никакого волшебного соуса GStreamer, но можно расширить его использование.

1.) Поток h264es через сеть (только для примера)

на сервере:

raspivid -v -a 524 -a 4 -a "rpi-0 %Y-%m-%d %X" -fps 15 -n -md 2 -ih -t 0 -l -o tcp://0.0.0.0:5001

на клиенте:

mplayer -nostop-xscreensaver -nolirc -fps 15 -vo xv -vf rotate=2,screenshot -xy 1200 -demuxer h264es ffmpeg://tcp://<rpi-ip-address>:5001

2.) Поток mjpeg через сеть (только для примера)

на сервере:

/usr/local/bin/mjpg_streamer -o output_http.so -w ./www -i input_raspicam.so -x 1920 -y 1440 -fps 3

на клиенте:

mplayer -nostop-xscreensaver -nolirc -fps 15 -vo xv -vf rotate=2,screenshot -xy 1200 -demuxer lavf http://<rpi-ip-address>:8080/?action=stream

все это даже работает на RPi Zero W (настроен как сервер)