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

16

Я получил 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 или нет.

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

NH2
источник
Идея о том, что использование канала |создает какую-либо проблему в этом контексте, является невероятной частью BS. Вы пробовали какие-либо raspivid | cvlcметоды? У меня не было камеры очень долго или много времени, чтобы поиграть с ней, но использование ее для создания потока http (видимого на linux на другом конце с / vlc), похоже, работает нормально.
Златовласка
@goldilocks Я не говорю, что труба - это «проблема», просто она не нужна и имеет некоторые накладные расходы, как и cat file | grep ...вместо grep ... file. Канал добавляет еще один уровень копирования в ядро ​​и из него, что легко измерить, особенно на устройствах с низкой пропускной способностью памяти. Если gstreamer может читать файлы устройства напрямую, почему бы не использовать это? Что касается вашего raspivid | cvlcпредложения: я использовал это до того, как переключился на решение на основе gstreamer, у него задержка на 3 секунды больше, чем у gstreamer (я не знаю почему).
nh2
Да, это определенно имеет некоторую задержку. WRT труба, моя точка зрения на «контекст» заключается в том, что это не может быть узким местом здесь - сетевой ввод-вывод будет на несколько порядков медленнее и т. Д. Вы правы, хотя, это может немного добавить к ЦП время. Просто я бы поставил немного; выполнение этого с полным разрешением, cvlcиспользует ~ 45%, но простое прохождение через канал с такой скоростью передачи данных (опять же, учитывая, что канал не замедляет его ) едва ли переместит стрелку, я думаю. Нравится <5%. Это не совсем незначительно, если вы хотите сделать это максимально эффективно, конечно ...
Златовласка
... Я просто не хочу, чтобы кто-то еще читал это, чтобы создать впечатление, что использование канала может быть причиной проблем с задержкой или других проблем. Это красная сельдь. Или я могу ошибаться;)
Златовласка
Если вам нужна эффективность, вы можете включить общее наблюдаемое использование ЦП для различных методов с определенным разрешением / частотой кадров. Единственное, что я попробовал, этоraspivid | cvlc тот, и это 40-50%. Люди могут лучше ответить на вопрос, который заставляет их улучшать конкретную фигуру. Прямо сейчас вы спрашиваете много о причинах, не объясняя, почему каждый из них важен.
Златовласка

Ответы:

8

Варианты:

  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 ?    ?    ?    ?    ?    ?    ?
user1133275
источник
1
Почему все значения в этой таблице " ?"?
Жаворонки
@larsks, потому что никто не заботится о том, чтобы проверить и заполнить данные в этой «вики сообщества»
user1133275
6

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

prinxis
источник
Поскольку я хочу транслировать на свой сервер и, возможно, на смартфоны, потоковая передача в браузер не является обязательной. Кроме того, браузер может наложить дополнительные ограничения на него (например, без RTSP, потенциально без TCP, если вы не используете WebRTC, но это довольно сложно). Но UV4L все еще выглядит многообещающе. Не могли бы вы дать ссылку на место, где я могу прочитать о том, как его использовать / извлечь из него данные для потоковой передачи по сети?
2
Святая корова, я думаю, что нашел пример страницы ... эта вещь, кажется, в состоянии сделать все ! RTMP, RTSP, потоковое HTTPS, WebRTC, «Обнаружение объектов в реальном времени и отслеживание объектов + обнаружение лиц» - что за черт ?? Каждый с некоторыми простыми флагами командной строки для uv4l? Мой конвейер gstreamer выглядит довольно устаревшим! Не могу дождаться, чтобы проверить, какова задержка!
nh2
1
О нет, это закрытый источник :( Это дисквалифицирует его для использования в качестве домашнего наблюдения, которое я имел в виду :(
nh2
он поддерживает WebRTC, двухсторонний WebRTC. задержка составляет ~ 200 мс аудио / видео, аудио менее вероятно
prinxis
@ nh2, ссылка, кажется, не работает, у вас есть обновленное местоположение для этой страницы примера?
Punit Soni
1

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 (настроен как сервер)

Sparkie
источник
Эй, спасибо за ответ, что это sample onlyзначит?
nh2
Я хотел сказать «это только пример». Вы можете адаптировать это к вашим потребностям.
sparkie