ARQ. 2

☞ Esquema de Arquitectura

 ┌──────────────────────────────────────────────────────────────────┐
 │              RASPBERRY PI 3B  ·  SOLAR NET HUB                  │
 │              BCM2837 · Cortex-A53 · VideoCore IV                │
 │                                                                  │
 │  ┌──────────┐  ribbon  ┌──────────────────┐                     │
 │  │ 🎥 CAM   │─────────▷│ rpicam-vid       │                     │
 │  │ CSI      │  zero-   │ H.264 HW encode  │                     │
 │  └──────────┘  copy    │ (nativo, sin     │                     │
 │                        │  ffmpeg)          │                     │
 │                        └────────┬─────────┘                     │
 │                                 │ RTSP                           │
 │                        ┌────────┴──────────────────────┐        │
 │                        │     MediaMTX       :8554      │        │
 │                        │                               │        │
 │                        │  Auto-conversión:             │        │
 │                        │    RTSP → HLS (:8888)         │        │
 │                        │    RTSP → WebRTC (:8889)      │        │
 │                        │    RTSP → RTMP (:1935)        │        │
 │                        │    Hooks → Node.js            │        │
 │                        └────────┬──────────────────────┘        │
 │                                 │ localhost                      │
 │  ┌──────────────────────────────┴────────────────────────────┐  │
 │  │  OASIS  :3000   (Node.js · SSB · cero JS en browser)     │  │
 │  │                                                           │  │
 │  │   GET /video     ──▷ proxy MediaMTX HLS                  │  │
 │  │   GET /snapshot  ──▷ proxy MediaMTX JPEG                 │  │
 │  │                                                           │  │
 │  │   HTML: <video src="/video.m3u8"> (HLS sin JS en Safari) │  │
 │  │   Alt:  <img src="/snapshot"> + refresh meta              │  │
 │  │                                                           │  │
 │  │   ┌─────────────────────────────────────┐                 │  │
 │  │   │ node-datachannel (P2P DataChannels) │                 │  │
 │  │   │ texto · archivos · señalización     │                 │  │
 │  │   └─────────────────────────────────────┘                 │  │
 │  └───────────────────────────────────────────────────────────┘  │
 └──────────────────────────────────────────────────────────────────┘
          │                │                │
          ▼                ▼                ▼
   ┌────────────┐  ┌─────────────┐  ┌────────────┐
   │ 📺 BROWSER │  │ 📡 PEER     │  │ 🌐 REMOTE │
   │ LAN (no JS)│  │ P2P data   │  │ HLS viewer │
   │ <video>HLS │  │ node-dc    │  │ <video>HLS │
   │ ó snapshot │  │ text/file  │  │ via Tor OK │
   └────────────┘  └─────────────┘  └────────────┘

Key Concepts

¿Qué es MediaMTX?

MediaMTX (antes rtsp-simple-server) es un router de protocolos media en Go. Su superpoder: auto-conversión. Publicas un stream RTSP y automáticamente está disponible como HLS, WebRTC, RTMP, SRT — sin config adicional. ~20 MB binario, 13k ★ en GitHub, muy activo.

¿Por qué es óptima para CSI?

MediaMTX soporta rpiCamera como fuente nativa: accede directamente a rpicam-vid para obtener H.264 del encoder HW del VideoCore sin pasar por V4L2 ni ffmpeg. Zero-copy del GPU al stream RTSP. En RPi 3B, esto significa ~5% CPU vs ~15–20% con ffmpeg.

go2rtc también captura V4L2 directo, pero pasa por la capa V4L2 del kernel (con copia de buffers). MediaMTX con rpicam nativo salta V4L2 completamente.

El problema con USB

MediaMTX no lee V4L2/UVC directo para cámaras USB. Necesita un proceso ffmpeg externo que capture de V4L2, transcodifique a H.264, y publique por RTSP local. Esto anula la ventaja de CPU sobre go2rtc (que sí captura V4L2 directamente).

Veredicto: MediaMTX es óptima para CSI y subóptima para USB. Si necesitas soporte USB, go2rtc (Arq. 3) es más equilibrada.

Audio: la pieza pendiente

MediaMTX no captura audio ALSA directamente (a diferencia de go2rtc). El audio necesita un proceso ffmpeg aparte que capture ALSA y publique por RTSP, o bien usar Mumble (como en Arq. 3) para audio bidireccional independiente.

Para audio bidireccional + Tor: combinar MediaMTX (vídeo) + Mumble (audio) = variante híbrida de Arq. 3 con mejor eficiencia CSI.

Hooks: comunicación con Node.js

MediaMTX ejecuta comandos al conectar/desconectar un lector. Esto permite notificar a Oasis sin polling:

# mediamtx.yml (fragmento hooks) paths: solar-cam: runOnReady: curl http://localhost:3000/hook/stream-ready runOnNotReady: curl http://localhost:3000/hook/stream-stopped runOnRead: curl http://localhost:3000/hook/viewer-connected runOnUnread: curl http://localhost:3000/hook/viewer-disconnected

Componentes

MediaMTX

:8554 (RTSP) · :8888 (HLS) · :8889 (WebRTC)

Lenguaje: Go (binario estático ~20 MB)
Repo: bluenviron/mediamtx
RAM: ~15–30 MB
Entrada: RTSP, RTMP, HLS, WebRTC, SRT, rpicam nativo
Salida: RTSP, RTMP, HLS, WebRTC, SRT, MJPEG snapshots
Auto-conversión: ✔ entre todos los protocolos
Auth: internal / HTTP / JWT
Config: mediamtx.yml

rpicam-vid

—

Herramienta nativa de captura CSI de Raspberry Pi
Accede al encoder H.264 HW del VideoCore IV
Zero-copy: GPU → buffer → RTSP directo
Solo cámaras CSI (OV5647, IMX219, IMX477…)

node-datachannel

P2P

DataChannels WebRTC: texto, archivos
Señalización SDP/ICE vía SSB
Corre dentro de Oasis (Node.js)
No transporta audio ni vídeo

Ficha Rápida

Propiedad	Estado
Cero JS en browser LAN	✔ (HLS/snapshot)
Cámara CSI	✔ Zero-copy HW
Cámara USB	⚠️ Necesita ffmpeg
Audio captura	⚠️ Necesita ffmpeg→RTSP
Audio bidireccional	✘ (no nativo)
Funciona sobre Tor	⚠️ HLS sí; WebRTC no
Auto-conversión	✔ RTSP↔HLS↔WebRTC↔RTMP
HLS para remoto	✔
WebRTC (WHEP)	✔
RTSP output	✔
Hooks a Node.js	✔ on_connect/disconnect
DataChannels P2P	✔ (node-datachannel)
RAM nuevos procesos	~15–30 MB

¿Cuándo Elegir Arq. 2?

✔ SÍ cuando:
· Usas cámara CSI y quieres máxima eficiencia HW
· Necesitas auto-conversión multi-protocolo
· Quieres HLS nativo sin config adicional
· No necesitas audio bidireccional nativo
· El peer remoto usa HLS (Tor-compatible)

✘ NO cuando:
· Usas cámara USB (ffmpeg anula la ventaja)
→ Usa Arq. 3 (go2rtc, V4L2 directo)
· Necesitas audio bidireccional
→ Combinar con Mumble, o usar Arq. 3
· Quieres MJPEG streaming continuo
→ MediaMTX sirve snapshots, no MJPEG stream. Usa go2rtc o Arq. 6

☞ MediaMTX: CSI vs USB

	MediaMTX + CSI	MediaMTX + USB
Fuente	`rpiCamera` nativo (zero-copy)	ffmpeg exec → RTSP local
ffmpeg necesario	❌ No	✔ Sí (decode MJPEG + encode H.264)
CPU	~5% (HW encode directo)	~15–20% (ffmpeg transcoding)
Config	10 líneas YAML	10 líneas YAML + ffmpeg command
Auto-conversión	✔ RTSP→HLS→WebRTC automática	✔ Igual (una vez el RTSP existe)
Docker devices	/dev/video0 + /dev/vchiq	/dev/video0

mediamtx.yml — CSI

# Fuente nativa rpicam (zero-copy) paths: solar-cam: source: rpiCamera rpiCameraWidth: 1280 rpiCameraHeight: 720 rpiCameraFPS: 25 rpiCameraCodec: h264 rpiCameraProfile: baseline rpiCameraLevel: "3.1" rpiCameraBitrate: 1000000

mediamtx.yml — USB

# USB requiere ffmpeg como fuente paths: solar-cam: runOnInit: > ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 -framerate 25 -i /dev/video0 -c:v h264_v4l2m2m -b:v 1M -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH runOnInitRestart: yes

MediaMTX vs. go2rtc — Comparativa Directa

Criterio	MediaMTX	go2rtc
CSI zero-copy	✔ rpicam nativo	⚠️ V4L2 (con copia)
USB directo	✘ Necesita ffmpeg	✔ V4L2 directo
Audio ALSA	✘ Necesita ffmpeg→RTSP	✔ ALSA directo
MJPEG stream	⚠️ Solo snapshots	✔ MJPEG continuo
HLS	✔ Auto-conversión	✔ Nativo
WebRTC (WHEP)	✔	✔
RTSP	✔ (protocolo base)	✔
RTMP	✔	✘
SRT	✔	✘
Auth	✔ internal/HTTP/JWT	Básica (API key)
Hooks	✔ on_connect/disconnect	✘
RAM	~15–30 MB	~20–40 MB
CPU (CSI)	~5%	~5–10%
CPU (USB)	~15–20% (ffmpeg)	~10–20%
Binario	~20 MB	~15 MB
GitHub ★	~13k	~7k

Resumen: MediaMTX gana en CSI (zero-copy) y en protocolos extra (RTMP, SRT, hooks). go2rtc gana en USB, audio ALSA, y MJPEG streaming. Para el SNH, la elección depende de la cámara.

Auto-Conversión de Protocolos

                              MediaMTX
                         ┌─────────────────┐
                         │                 │
   rpicam-vid ──RTSP──▷  │  RTSP :8554     │
                         │    │            │
                         │    ├──▷ HLS    :8888   →  <video src=".m3u8">
                         │    ├──▷ WebRTC :8889   →  peers con JS
                         │    ├──▷ RTMP   :1935   →  re-stream externo
                         │    ├──▷ SRT    :8890   →  low-latency link
                         │    └──▷ API    :9997   →  control / status
                         │                 │
                         └─────────────────┘

  ★ Publicas UNA fuente RTSP → sale en TODOS los formatos ★
  ★ Sin config adicional por protocolo                     ★

Opción	Descripción	Bid.	Tor	Complejidad
ffmpeg→RTSP	ffmpeg captura ALSA, publica RTSP en MediaMTX. Auto-conv a HLS audio.	✘	⚠️	Baja
Mumble	murmurd (ya instalado) + bridge HTTP. Audio bidireccional, Tor-compatible.	✔	✔	Media
Sin audio	Solo vídeo. Válido para vigilancia/monitorización.	✘	N/A	Ninguna

Riesgo	Prob.	Impacto	Mitigación
USB cam descarta ventaja CSI	Media	Medio	hardware_detect.js → redirigir a Arq. 3 (go2rtc) para USB
Sin MJPEG stream continuo	Segura	Medio	Usar snapshots + meta refresh, o proxy ffmpeg RTSP→MJPEG
Audio requiere componente extra	Segura	Bajo	Combinar con Mumble (ya instalado) para audio bidireccional
rpicam API cambia en nuevas distros	Baja	Medio	MediaMTX se actualiza regularmente (~13k ★, releases frecuentes)

☞ Deep-Dive Specs

☞ Esquema de Arquitectura

Key Concepts

Componentes

Ficha Rápida

¿Cuándo Elegir Arq. 2?

☞ MediaMTX: CSI vs USB

MediaMTX vs. go2rtc — Comparativa Directa

Auto-Conversión de Protocolos

Audio: Opciones para Arq. 2

Riesgos & Mitigaciones