Сучасний спосіб передавати 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 »Понеділок 07.12.2013 15:34 за посиланням 2):

Відправник (Pi): 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

Якщо я правильно розумію, обидва способи використовують графічний процесор для декодування 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)
• Клієнт CPU 1 [%]
• ОЗУ [МБ] (ВДЕ)
• ті ж налаштування кодування
• однакові особливості
  • аудіо
  • знову підключитись
  • Незалежний клієнт ОС (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 (налаштовано як сервер)