Nowoczesny sposób przesyłania strumieniowego H.264 z kamery Raspberry Cam

Mam Pi B + i kamerę Pi i teraz próbuję znaleźć najbardziej wydajną konfigurację (niski procesor) i najniższe opóźnienie, aby przesyłać strumieniowo wideo zakodowane w H.264 z kamery na mój domowy serwer.

Przeczytałem następujące:

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

(Wszystkie linki używają gstreamer-1.0 z deb http://vontaene.de/raspbian-updates/ . main.)

W ostatnich latach wiele zrobiono w tym zakresie.

Początkowo musieliśmy przesyłać dane wyjściowe raspividdo gst-launch-1.0(patrz link 1).

Następnie (link 2) został utworzony oficjalny sterownik V4L2, który jest teraz standardem i pozwala na bezpośrednie uzyskiwanie danych bez potoku, przy użyciu tylko gstreamer (patrz zwłaszcza post przez towolf »Sat Dec 07, 2013 3:34 pm w linku 2):

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

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

Jeśli dobrze rozumiem, oba sposoby wykorzystują GPU do dekodowania H264, ale ten ostatni jest nieco bardziej wydajny, ponieważ nie musi przechodzić przez jądro innym razem, ponieważ nie ma potoku między zaangażowanymi procesami.

Teraz mam kilka pytań na ten temat.

1. Czy ten ostatni jest wciąż najnowszym sposobem na efektywne pobieranie H264 z aparatu? Czytałem o tym gst-omx, co pozwala na takie rurociągi gstreamer ... video/x-raw ! omxh264enc ! .... Czy to robi coś innego niż tylko używanie video/x-h264, czy może nawet jest bardziej wydajne? Co za różnica?

2. Jak dowiedzieć się, jaka wtyczka kodująca gstreamer jest faktycznie używana, gdy korzystam z video/x-h264 ...potoku? Wydaje się, że to tylko określenie pożądanego formatu w porównaniu z innymi częściami potoku, w których wyraźnie nazywam składnik (kod) (jak h264parselub fpsdisplaysink).

3. W tej odpowiedzi do linku 1 Mikael Lepistö wspomina: „Usunąłem jedno niepotrzebne hasło filtru ze strony przesyłania strumieniowego” , co oznacza, że ​​wyciął gdppayi gdpdepay. Co oni robią? Dlaczego są potrzebne? Czy naprawdę mogę je zdjąć?

4. Wspomina również, że określając caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96"parametry po udpsrcstronie odbierającej, może rozpocząć / wznowić transmisję strumieniową w środku strumienia. Co osiągają te ograniczenia, dlaczego te konkretne wybory, gdzie mogę przeczytać o nich więcej?

5. Kiedy robię to, co sugeruję w pytaniach 3 i 4 (dodawanie caps, upuszczanie gdppayi gdpdepay), wtedy moje opóźnienie wideo staje się znacznie gorsze (i wydaje się, że się kumuluje, opóźnienie wzrasta z czasem, a po kilku minutach wideo zatrzymuje się)! Dlaczego tak może być? Chciałbym uzyskać opóźnienie uzyskane dzięki oryginalnemu poleceniu, ale mam również możliwość dołączenia do strumienia w dowolnym momencie.

6. Czytałem, że RTSP + RTP zwykle używają kombinacji TCP i UDP: TCP do komunikatów kontrolnych i innych rzeczy, których nie można zgubić, oraz UDP do rzeczywistej transmisji danych wideo. Czy w powyższych konfiguracjach faktycznie tego używam, czy tylko używam tylko UDP? Nie jest dla mnie jasne, czy gstreamer się tym zajmuje, czy nie.

Byłbym wdzięczny za odpowiedź na choćby jedno z tych pytań!

Opcje:

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

Rzeczy do rozważenia

• opóźnienie [ms] (zi bez pytania klienta, aby chciał więcej fps niż serwer)
• Bezczynność procesora [%] (mierzona przez top -d 10)
• Klient CPU 1 [%]
• RAM [MB] (RES)
• te same ustawienia kodowania
• te same funkcje
  • audio
  • na nowo połączyć
  • Klient niezależny od systemu operacyjnego (vlc, webrtc itp.)

Porównanie:

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

Tylko nowoczesny sposób, aby strumień H264 do przeglądarki jest z UV4L : brak opóźnienia, brak konfiguracji z opcjonalnym dźwiękiem, opcjonalnie dwukierunkowe audio / wideo. Bez magicznego sosu GStreamer, ale można rozszerzyć jego użycie.

1.) Przesyłanie strumieniowe h264es przez sieć (tylko próbka)

na serwerze:

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

na kliencie:

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

2.) Streaming mjpeg w sieci (tylko próbka)

na serwerze:

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

na kliencie:

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

wszystko to działa nawet na RPi Zero W (skonfigurowanym jako serwer)