Key Concept
Arq. 5 tiene la mayor complejidad de despliegue de todas las arquitecturas: cross-compile de libwebrtc (~4 GB), binario C++ específico de RPi, y un proxy Node.js con ffmpeg. Se documenta el proceso completo y las estrategias de fallback.
☞ Pre-Flight Checklist
| # | Verificación | Comando | Esperado |
|---|
| 1 |
Cámara CSI presente |
libcamera-hello --list-cameras |
Al menos 1 cámara listada |
| 2 |
VideoCore accesible |
ls /dev/vchiq |
Existe (para H.264 HW encode) |
| 3 |
GPU memory ≥ 128 MB |
vcgencmd get_mem gpu |
gpu=128M o más |
| 4 |
ffmpeg instalado |
ffmpeg -version |
ffmpeg 5.x+ con decoders h264, opus |
| 5 |
node-datachannel instalable |
npm ls node-datachannel |
v0.32+ con prebuild ARM |
| 6 |
RPi-WebRTC binario |
/opt/rpi-webrtc/rws --version |
Ejecutable, no SIGILL |
| 7 |
Puerto 8889 libre |
ss -tlnp | grep 8889 |
Nada escuchando |
| 8 |
RAM suficiente (~100 MB libres) |
free -m |
MemAvailable ≥ 200 MB tras Oasis |
Unidades systemd
rpi-webrtc.service
[Unit]
Description=RPi-WebRTC Streamer
After=network.target
Wants=network.target
[Service]
Type=simple
ExecStart=/opt/rpi-webrtc/rws \
--config /opt/rpi-webrtc/webrtc_streamer.conf
Restart=on-failure
RestartSec=5
User=rpi-webrtc
Group=video
SupplementaryGroups=video
DeviceAllow=/dev/vchiq rw
DeviceAllow=/dev/video* rw
MemoryMax=80M
CPUQuota=30%
[Install]
WantedBy=multi-user.target
Activar y arrancar
sudo systemctl daemon-reload
sudo systemctl enable --now rpi-webrtc
sudo systemctl status rpi-webrtc
Oasis (que contiene media_proxy.js) ya tiene su propia unit. Configurar After=rpi-webrtc.service en la unit de Oasis para asegurar orden de arranque.
Docker (alternativa)
RPi-WebRTC necesita acceso directo a /dev/vchiq (GPU) y /dev/video* (cámara). En Docker requiere --device flags.
services:
rpi-webrtc:
image: rpi-webrtc-local:latest
devices:
- /dev/vchiq:/dev/vchiq
- /dev/video0:/dev/video0
ports:
- "127.0.0.1:8889:8889"
volumes:
- ./webrtc_streamer.conf:/opt/rpi-webrtc/webrtc_streamer.conf:ro
mem_limit: 80m
restart: unless-stopped
La imagen Docker hay que construirla localmente (cross-compile) o en CI. No hay imagen oficial en Docker Hub.
☞ Estrategia de Fallback
RPi-WebRTC tiene riesgo de mantenimiento. El SNH debe poder caer a Arq. 3 (go2rtc) sin re-diseño del frontend.
hardware_detect.js
│
├─ CSI detectada + RPi-WebRTC disponible
│ → Arrancar RPi-WebRTC (:8889)
│ → media_proxy.js consume WebRTC → MJPEG/OGG
│ → GET /video, GET /audio (mismas rutas)
│
├─ CSI detectada + RPi-WebRTC NO disponible
│ → Arrancar go2rtc (:1984) con v4l2
│ → Proxy go2rtc MJPEG → GET /video
│ → Mumble bridge → GET /audio
│ → (= Arq. 3, mismas rutas)
│
└─ USB detectada
→ RPi-WebRTC descartado automáticamente
→ Arrancar go2rtc/µStreamer
→ (= Arq. 3 o Arq. 6)
Las rutas HTTP GET /video y GET /audio son idénticas en todas las arquitecturas. El frontend (EJS templates) no necesita cambiar.
Monitorización
| Métrica | Comando | Umbral alerta |
|---|
| RAM RPi-WebRTC |
systemctl status rpi-webrtc | grep Memory |
> 60 MB |
| CPU total |
top -bn1 | grep rws |
> 25% |
| ffmpeg decode CPU |
top -bn1 | grep ffmpeg |
> 15% |
| Temperatura GPU |
vcgencmd measure_temp |
> 70°C |
| WebRTC peers activos |
GET http://localhost:8889/status (si soportado) |
> 2 simultáneos |
| Logs errores |
journalctl -u rpi-webrtc --since "5 min ago" -p err |
Cualquier error |
Presupuesto de Recursos (RPi 3B, 1 GB)
| Proceso | RAM | CPU | Notas |
|---|
| Linux + Bookworm base | ~150 MB | — | Kernel + systemd + base |
| Docker daemon | ~50 MB | ~2% | Si se usa Docker |
| Oasis (Node.js + SSB) | ~200 MB | ~5–10% | Incluye ssb-server |
| RPi-WebRTC | ~40 MB | ~15–20% | Encode HW + stack |
| media_proxy.js (ffmpeg) | ~40–60 MB | ~10% | Decode H.264→MJPEG |
| node-datachannel | ~8 MB | ~2% | Dentro de Oasis |
| TOTAL | ~490–510 MB | ~35–45% | Quedan ~490 MB libres |
Es la arquitectura que más RAM consume. En 1 GB, queda margen justo. Si Oasis crece, considerar Arq. 6 (~10–20 MB media).
systemd
cross-compile
fallback
hardware_detect.js
cgroups
/dev/vchiq
MemoryMax
Docker