Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Containers·Snapshots
TipoDesbloqueadoEtapaVictoria rápidaDificultadSimpleTrabajoCompartir streamParaEquipos de desarrolloParaUsuarios avanzados de productividadServiciosPipePor qué HoodyHTTP nativo
TipoDesbloqueadoEtapaVictoria rápidaDificultadSimpleTrabajoCompartir streamParaEquipos de desarrolloParaUsuarios avanzados de productividadServiciosPipePor qué HoodyHTTP nativo
use-cases / a-microphone-over-http / hero
PIPE · AUDIO · LIVE
Un micrófono sobre HTTP, en dos terminales
Estás depurando en pareja a medianoche y el hotspot del otro lado no aguantará un Zoom. Ambos tenéis una shell. ffmpeg captura el micro, curl lo PUTea a una ruta de pipe, el otro terminal hace curl y reproduce los bytes. Sin SDK, sin signaling, sin reunión.
tú · emisor
mic · alsa default
# captura mic, codifica a opus, PUT a una ruta de pipe$ ffmpeg -f alsa -i default \
-c:a libopus -f ogg - \
| curl -T - https://pipe.containers.hoody.com/api/v1/pipe/voicesubiendo · 1 receptor conectado
pipe/voicebytes en vuelo
ellos · receptor
altavoces · mpv
# GET al pipe, reproduce el stream según llega$ curl https://pipe.containers.hoody.com/api/v1/pipe/voice
| mpv --no-video -reproduciendo · 0:42 desde la conexión
sin signaling, sin SDK, sin Zoom
use-cases / a-microphone-over-http / mechanism
Dos curls, una ruta de pipe, sin signaling
ffmpeg codifica tu micrófono a opus y lo escribe a stdout. curl hace PUT de ese stdin a /api/v1/pipe/voice. Quien haga GET a la misma ruta recibe los bytes a medida que el emisor los produce. El pipe mantiene al receptor hasta cinco minutos para que el emisor se conecte, reenvía Content-Type, y no almacena nada.
Del micro a los altavoces en cuatro líneas4 PASOS · CERO SIGNALING
0101 · CAPTURA
Lee el micro
ffmpeg -f alsa -i default -c:a libopus -f ogg - lee tu micrófono, codifica a opus, escribe a stdout.
0202 · STREAM
Pipea a curl
curl -T - hace PUT del stdin a /api/v1/pipe/voice. El pipe espera hasta cinco minutos a un receptor en la misma ruta.
0303 · CONECTAR
El receptor hace GET a la ruta
Su terminal ejecuta curl https://.../api/v1/pipe/voice. El pipe empareja emisor con receptor y empieza a transmitir.
0404 · REPRODUCIR
Los bytes llegan a los altavoces
Su curl pipea a aplay o mpv. El audio se reproduce según llega, byte por byte. ctrl-C termina la llamada.
El pipe reenvía Content-Type, soporta hasta cinco minutos de hold-time antes de que se conecte un contraparte, y usa HTTPS — nada más exótico que el protocolo que tu shell ya habla.
use-cases / a-microphone-over-http / lofi
Lo-fi a propósito
No hay cancelación de eco, ni jitter buffer, ni DSP sofisticado. Es el tipo de canal de voz por el que un par de SREs depura: minimalista, baja sobrecarga, fiable. Cada capa que una plataforma de reuniones construye es una capa que la pareja de pipes simplemente no tiene.
CAPAS QUE NO EXISTEN0 LÍNEAS DE CÓDIGO
Cosas que no pasan
- Abrir un handshake STUN/TURN
- Ejecutar un servidor de signaling para intercambiar SDPs
- Negociar un codec a través del stack WebRTC
- Aceptar un diálogo de permiso de micrófono
- Hacer clic en Unirse en una app de escritorio
- Hacer fallback a TURN cuando el NAT punching falla
- Esperar en una sala de espera al host
LO QUE REALMENTE HACESDOS TERMINALES
Cosas que sí pasan
- Escribe ffmpeg | curl en la shell del emisor
- Escribe curl | mpv en la shell del receptor
- Habla mientras los bytes fluyen por el pipe
- ctrl-C cuando termines — la ruta vuelve a la nada
use-cases / a-microphone-over-http / angles
Tres lectores, un par de curls
El mismo mecanismo de mic-sobre-HTTP se lee de tres formas distintas según quién esté al otro lado del pipe.
PARA EL DEPURADOR EN PAREJA
La voz que el SRE merece
Llevas tres comandos metido en un incidente de prod. Levantar Zoom tardaría más que el arreglo. ffmpeg | curl en tu lado, curl | mpv en el suyo — puedes hablar mientras tail-eas los logs.
PARA EL DEV VIAJERO
Sobrevive al hotspot
Compartir conexión por móvil se ahoga en una videollamada. Un stream opus de 32 kbps sobre HTTP, no. El otro extremo abre una URL y escucha — ni siquiera necesita un micro para participar.
PARA EL CONSCIENTE DE LA PRIVACIDAD
Sin grabación, sin app, sin cuenta
No se almacena nada en un servidor. No hay app de terceros en ninguna máquina. El pipe es puro streaming — los bytes pasan y desaparecen en el momento en que se pulsa ctrl-C.
use-cases / a-microphone-over-http / punchline
El audio son solo bytes. Los bytes son solo un pipe.
el stream empieza cuando pulsas enterel stream termina cuando pulsas ctrl-C
livepipe.containers.hoody.com/api/v1/pipe/voicemientras cualquier lado esté arriba
ctrl-C
404pipe.containers.hoody.com/api/v1/pipe/voicesin grabación, sin replay
use-cases / a-microphone-over-http / replaces
Lo que esto reemplaza
El elenco de herramientas de voz que cada pareja de ingenieros acumula. Cada una asume una reunión, una cuenta, o un servidor de signaling personalizado. La URL del pipe no asume ninguno de esos.
- Llamada de voz por ZoomBridge agendado, instalación de app, permisos de escritorio
- Slack screen-share con audioAmbos lados en el cliente de escritorio, solo Huddles
- Canal de voz DiscordMembresía de servidor, cuenta, topes de bitrate
- Voz Google MeetFontanería de calendario para un debug de 90 segundos
- WebRTC con signaling personalizadoSTUN/TURN, intercambio de SDP, un servidor que tienes que ejecutar
- SaaS de chat de vozOtro proveedor más, otra licencia de asiento más
use-cases / a-microphone-over-http / cta
La próxima vez que alguien diga 'podemos hacer una llamada rápida', abre un pipe.
use-cases / a-microphone-over-http / related
Lee los otros
