Hi,
ich beobachte den Thread seit einiger Zeit. Während ich auf den step-up Wandler warte um meine cam mobil zu machen, habe ich etwas gelesen und ein paar Experimente gemacht. Mein Ziel war es die besten settings bezüglich der Latenz des Encodings der Kamera heraus zu bekommen. Damit lässt sich bei den späteren Optimierungen das erste Glied schon mal abhaken. Ich wollte euch gerne meine Erkenntnisse mitteilen.
Versuchsaufbau:
raspberry pi A+ als transmitter, TP-Link TL-WN722N direkt am USB-Port, raspi WW-Cam
Arch for Arm als OS
der raspi fungiert als AP
ein Aromebook (chromebook mit Arch) mit Haswell Celeron und dem onboard Chip AR9462 ist der receiver
zum bequemen editieren der raspi-scripte ist ssh eingerichtet
die ausgabe von raspivid wird mittels netcat weitergereicht, Beispielscript:
default.sh
Code:
#!/bin/bash
/opt/vc/bin/raspivid -t 0 -n -fps 30 -b 4000000 -w 1280 -h 720 -o - | nc -k -l 5001 &
-l listen-mode, netcat wartet auf port 5001 auf eingehende Verbindungen
-k Wiederaufnahme, unterbrochene Verbindungen können fortgesetzt werden (funktioniert nur mit openbsd-netcat)
bei allen Versuchen wurde folgender Befehl zum empfangen verwendet
listen.sh
Code:
#!/bin/bash
mplayer -fps 200 -demuxer h264es ffmpeg://tcp://192.168.12.1:5001
mit der cam wurde Kronometer gefilmt, eine Stoppuhr für KDE. Mit SimpleScreenRecorder wurde der Desktop mit 1-fps aufgenommen.
Durchführung:
unter
http://picamera.readthedocs.org/en/latest/fov.html findet man eine Auflistung und kurze Erläuterung der von der Kamera unterstützten Hardwaremodi. Das interessanteste daran, nutzt man eine Auflösung die nicht von der Kamera unterstützt wird, so nutzt die Kamera die native Auflösung die der gewünschten am nächsten kommt und der Encoder startet eine zweite Runde um das Bild entsprechend zu skalieren. Im Umkehrschluss bedeutet das, halten wir uns an die vorgegebenen Modi, sparen wir einen Encoderdurchlauf.
Niedrigere Frameraten haben keinen Einfluss auf die Geschwindigkeit des Encoders, höhere Frameraten bedeuten der Puffer wird schneller gelesen.
Für mich bedeutet das, ich halte mich an die nativen Modi und benutze die für diesen Modus höchstmögliche Framerate. Da ich mindestens HD-ready(1080x720) bei 30fps nutzen möchte, kommen die Modi 1,4 und 5 in Frage.
Ein paar kurze Tests, '-ex sports' für kurze shutterzeiten damit die millisekunden nicht so verschwommen sind. Ich habe den Stream gestartet und etwa 20 sekunden vorlaufen lassen, bevor ich den Timer und das Desktoprecording angemacht habe. Dann etwa 30s aufgenommen und angeschaut um einen Eindruck zu bekommen, dabei alle paar Sekunden pausiert und kurz überschlagen.
1. Mode 1 1920x1080 30fps
mode1.sh
Code:
#!/bin/bash
/opt/vc/bin/raspivid -t 0 -n -fps 30 -w 1920 -h 1080 -b 4000000 -ex sports -o - |\
nc -k -l 5001 &
ergab ~170ms Latenz, schwankend zwischen 140ms und 200ms
2. Mode 4 1296x972 42fps
Code:
... -fps 42 -w 1296 -h 972...
ergab ~140ms, schwankend zwischen ~110ms und ~170ms
3. Mode 5 1296x730 49fps
Code:
... -fps 49 -w 1296 -h 730...
ergab ~110ms, schon stabiler zwischen ~95ms und ~120ms. Hier gehts weiter.
Hier
https://raw.githubusercontent.com/raspberrypi/userland/master/host_applications/linux/apps/raspicam/RaspiCamDocs.odt gibts die aktuelle Version des raspicam Handbuchs, mal schauen was uns raspivid so bietet um die Latenz weiter zu verringern.
mit '-b 0 --qp (10-40)' bekommt man variable Bitraten, 10 für höchste, 40 für niedrigste (wirklich allermieseste) Qualität. Ein kompletter Reinfall, Latenz zwischen ~200ms(40) und ~2s(10).
mit '--profile (baseline, main, high)' setzt man das Profil des h264 Encoders, hier gibt es spürbare Latenzunterschiede.
mit '-b xxxx' setzt man die bitrate, es kommt hier vor allem auf die zur Verfügung stehende Bandbreite des Wifi-Links an und kann je nach Noise sehr unterschiedlich ausfallen, ich hab > 30 APs in Reichweite... . In meinem Fall hatte ich die besten ergebnisse mit 3000000 bps, eine weitere Verringerung brachte keine Verbesserung, bei mehr als 4000000 nahmen die Schwankungen zu. In meinem Fall liegt der Sweet-Spot also zwischen 3- und 4000000. Ich bin damit erstmal zufrieden.
Vorläufiges Ergebnis:
mode5-gut.sh
Code:
#!/bin/bash
/opt/vc/bin/raspivid -t 0 -n -fps 49 -w 1296 -h 730 -b 3000000 -g 49 -ex sports --profile baseline -o - |\
nc -k -l 5001 &
mittel < 100ms, zwischen ~80ms und 120ms
Dingdong, mein Spannungswandler ist da, das trifft sich ja gut. Ich muss jetzt löten.
Verbesserungspotential,
- '--qp xx' mit fester bitrate
- raspivid nutzt mmal, evtl. ist v4l2 als treiber schneller
- shootout 'gstreamer vs mplayer vs ???' beim abspielen
Todo:
-wifibroadcast compilieren und die Ergebnisse im Ernstfall verifizieren
Ich hoffe ich konnte euch damit etwas helfen die besten Einstellungen für latenzfreies HD-Vergnügen zu finden.
Grüße
cbl
