Moderne Art, H.264 von der Raspberry Cam zu streamen

Ich habe den Pi B + und die Pi-Kamera und versuche nun, die effizienteste (niedrige CPU) und Konfiguration mit der geringsten Latenz zu finden, um H.264-codiertes Video von der Kamera auf meinen Heimserver zu streamen.

Ich habe folgendes gelesen:

(Alle Links verwenden gstreamer-1.0 von deb http://vontaene.de/raspbian-updates/ . main.)

In den letzten Jahren wurde in dieser Hinsicht viel getan.

Ursprünglich mussten wir die Ausgabe von raspividin umleiten gst-launch-1.0(siehe Link 1).

Dann ist (Link 2) die offiziellen V4L2 Fahrer geschaffen , die heute Standard ist, und es ermöglicht, die Daten direkt ohne ein Rohr zu erhalten, mit nur gstreamer (siehe insbesondere den Beitrag von towolf »Sa 7. Dezember 2013 03.34 in Verbindung 2):

Absender (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

Empfänger: gst-launch-1.0 -v udpsrc port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false

Wenn ich das richtig verstehe, verwenden beide Wege die GPU, um die H264-Dekodierung durchzuführen, aber letztere ist ein bisschen effizienter, da sie nicht ein weiteres Mal durch den Kernel gehen muss, da es keine Pipe zwischen den beteiligten Prozessen gibt.

Jetzt habe ich einige Fragen dazu.

Ist letzteres immer noch der neueste Weg, um H264 effizient aus der Kamera zu holen? Ich habe darüber gelesen gst-omx, was gstreamer Pipelines so zulässt ... video/x-raw ! omxh264enc ! .... Hat dies etwas anderes zu tun als nur zu verwenden video/x-h264, oder könnte es sogar effizienter sein? Was ist der Unterschied?
Wie finde ich heraus, welches gstreamer-Codierungs-Plugin tatsächlich verwendet wird, wenn ich die video/x-h264 ...Pipeline verwende? Dies scheint nur das Format anzugeben, das ich möchte, im Vergleich zu den anderen Pipeline-Teilen, bei denen ich die (Code-) Komponente explizit benenne (wie h264parseoder fpsdisplaysink).
In dieser Antwort zu Link 1 erwähnt Mikael Lepistö "Ich habe einen unnötigen Filterpass von der Streaming-Seite entfernt" , was bedeutet, dass er das gdppayund ausschneidet gdpdepay. Was machen die? Warum werden sie gebraucht? Kann ich sie wirklich ausziehen?
Er erwähnt auch, dass er durch Angabe von caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96"Parametern für die udpsrcempfangende Seite das Streaming in der Mitte des Streams starten / fortsetzen kann. Was erreichen diese Kappen, warum diese spezifischen Entscheidungen, wo kann ich mehr darüber lesen?
Wenn ich das mache, was in Frage 3 und 4 vorgeschlagen wird (Hinzufügen von caps, Löschen von gdppayund gdpdepay), wird meine Videolatenz viel schlimmer (und es scheint sich zu häufen, die Latenz nimmt mit der Zeit zu und nach ein paar Minuten stoppt das Video)! Warum könnte das so sein? Ich möchte die Latenz erhalten, die ich mit dem ursprünglichen Befehl erhalten habe, habe aber auch die Möglichkeit, mich jederzeit dem Stream anzuschließen.
Ich habe gelesen, dass RTSP + RTP normalerweise eine Kombination aus TCP und UDP verwendet: TCP für Kontrollnachrichten und andere Dinge, die nicht verloren gehen dürfen, und UDP für die eigentliche Videodatenübertragung. Verwende ich in den obigen Setups das tatsächlich oder verwende ich nur UDP? Es ist für mich ein bisschen undurchsichtig, ob GSTREAMER sich darum kümmert oder nicht.

Ich würde mich über jede Antwort auf eine dieser Fragen freuen!

camera streaming-video raspicam

— nh2
quelle

Die Idee, dass die Verwendung einer Pipe |in diesem Zusammenhang zu Problemen führt, ist ein unglaubliches Stück BS. Haben Sie raspivid | cvlcMethoden ausprobiert ? Ich hatte die Kamera nicht sehr lange oder nicht sehr lange zum Spielen, aber es vlcscheint in Ordnung zu sein, damit einen http-Stream zu erzeugen (der unter Linux am anderen Ende angezeigt werden kann ).

— Goldlöckchen

@goldilocks Ich sage nicht, dass die Pipe ein "Problem" ist, nur dass es nicht notwendig ist und etwas Overhead hat, genau wie cat file | grep ...statt grep ... file. Die Pipe fügt dem Kernel eine weitere Kopierschicht hinzu, die insbesondere auf Geräten mit geringer Speicherbandbreite leicht messbar ist. Wenn gstreamer direkt aus der Gerätedatei lesen kann, warum nicht? In Bezug auf Ihren raspivid | cvlcVorschlag: Ich habe diesen verwendet, bevor ich auf die auf gstreamer basierende Lösung umgestiegen bin. Er hat bis zu 3 Sekunden mehr Latenz als gstreamer (ich weiß nicht warum).

— nh2

Ja, es hat definitiv eine gewisse Latenz. WENN die Pipe, ist mein Punkt über "Kontext", dass dies möglicherweise kein Engpass hier sein kann - Netzwerk-E / A wird Größenordnungen langsamer sein, etc. Sie haben Recht, es kann jedoch ein bisschen zur CPU hinzufügen Zeit. Ich würde nur nicht viel wetten; Wenn man das mit voller Auflösung laufen lässt, cvlcbraucht man ~ 45%, aber wenn man nur mit dieser Datenrate durch eine Pipe läuft (wenn man noch einmal bedenkt, dass die Pipe es nicht verlangsamt ), würde sich die Nadel kaum bewegen, denke ich. Wie <5%. Es ist natürlich nicht unerheblich, ob Sie dies so effizient wie möglich tun möchten ...

— Goldlöckchen

... Ich möchte nur nicht, dass jemand, der dies liest, den Eindruck erweckt, dass die Verwendung einer Pipe hier möglicherweise für Latenzprobleme oder andere Probleme verantwortlich ist. Das ist ein roter Hering. Oder ich könnte mich irren;)

— Goldlöckchen

Wenn Sie nach Effizienz streben, können Sie die beobachtete Gesamt-CPU-Auslastung für verschiedene Methoden bei bestimmten Auflösungen / Bildraten berücksichtigen. Der einzige, den ich ausprobiert habe, ist der raspivid | cvlc, und das sind 40-50%. Menschen können besser auf eine Frage antworten, die sie dazu auffordert, sich an einer bestimmten Zahl zu verbessern. Im Moment fragen Sie eine Menge nach dem Warum, ohne zu erklären, warum jedes Warum von Bedeutung ist.

— Goldlöckchen

Antworten:

Die Optionen:

raspivid -t 0 -o - | nc -k -l 1234
raspivid -t 0 -o - | cvlc stream:///dev/stdin --sout "#rtp{sdp=rtsp://:1234/}" :demux=h264
cvlc v4l2:///dev/video0 --v4l2-chroma h264 --sout '#rtp{sdp=rtsp://:8554/}'
raspivid -t 0 -o - | gst-launch-1.0 fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=SERVER_IP port=1234
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
uv4l --driver raspicam
picam --alsadev hw:1,0

Dinge, die man beachten muss

Latenz [ms] (mit und ohne Aufforderung an den Client, mehr fps als der Server zu wollen)
CPU-Leerlauf [%] (gemessen von top -d 10)
CPU 1-Client [%]
RAM [MB] (RES)
gleiche Kodierungseinstellungen
gleiche Eigenschaften
- Audio-
- wieder verbinden
- Betriebssystemunabhängiger Client (vlc, webrtc usw.)

Vergleich:

            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 ?    ?    ?    ?    ?    ?    ?

— revs user1133275
quelle

Warum sind alle Werte in dieser Tabelle " ?"?

— Larsks

@larsks, weil niemand die Daten in diesem Community-Wiki testen und ausfüllen

— möchte

Der einzige moderne Weg, H264 an einen Browser zu streamen, ist UV4L : Keine Latenz, keine Konfiguration, mit optionalem Audio, optionalem Zwei-Wege-Audio / Video. Keine magische GStreamer-Sauce, dennoch kann die Verwendung erweitert werden.

— prinxis
quelle

Da ich auf meinen Server und möglicherweise auf Smartphones streamen möchte, ist das Streamen auf einen Browser nicht erforderlich. Außerdem kann der Browser zusätzliche Einschränkungen festlegen (z. B. kein RTSP, möglicherweise kein TCP, es sei denn, Sie verwenden WebRTC, aber das ist umständlich). Aber UV4L sieht immer noch vielversprechend aus. Könnten Sie einen Link zu einem Ort erstellen, an dem ich nachlesen kann, wie ich ihn verwende / die Daten für das Streamen über das Netzwerk daraus entnehme?

— nh2

Heilige Kuh, ich glaube, ich habe die Beispielseite gefunden ... dieses Ding scheint in der Lage zu sein, alles zu tun ! RTMP, RTSP, HTTPS-Streaming, WebRTC, "Echtzeit-Objekterkennung und Objektverfolgung + Gesichtserkennung" - was zur Hölle? Jeweils mit ein paar einfachen Kommandozeilen-Flags zu uv4l? Meine Gstreamer-Pipeline sieht jetzt ziemlich veraltet aus! Ich kann es kaum erwarten zu testen, wie hoch die Latenz ist!

— nh2

Oh nein, es ist eine geschlossene Quelle :( Das disqualifiziert es für den Hausüberwachungseinsatz, den ich mir vorgestellt hatte :(

— nh2

Es unterstützt WebRTC, 2-Wege-WebRTC. Die Latenz beträgt ~ 200ms Audio / Video, Audio weniger wahrscheinlich

— prinxis

@ nh2, der Link scheint defekt zu sein. Haben Sie einen aktualisierten Speicherort für diese Beispielseite?

— Punit Soni

1.) h264es Streaming über das Netzwerk (nur Beispiel)

auf dem Server:

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

auf Client:

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

2.) MJPEG Streaming über das Netzwerk (nur als Beispiel)

auf dem Server:

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

auf Client:

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

all dies funktioniert sogar auf einem RPi Zero W (als Server konfiguriert)

— Sparkie
quelle

Hey, danke für deine Antwort, was bedeutet sample onlydas?

— nh2

Ich wollte sagen, es ist nur ein Beispiel. Sie können dies an Ihre Bedürfnisse anpassen.

— Sparkie