Lives que continuam quando um Relay falha.
Distribuição multi-relay, recuperação automática e evidência mensurável — sem refresh e sem fallback oculto.
Resilient live distribution.
Como funciona
O Leap está validando se uma Live pode ser distribuída por múltiplos Relays, com recuperação automática e resultados mensuráveis, sem depender de um único distribuidor central.
O Streamer publica pelo OBS
A Live entra por WHIP em um Controlled Ingress — ponto único temporário, assumido como concessão da POC.
O Ingress replica antecipadamente
A mídia chega aos três Controlled Relays antes de qualquer Viewer pedir — a falha de um não interrompe a origem dos demais.
Viewers em round-robin determinístico
Cada Viewer recebe um Relay e o endpoint WHEP anunciado pelo próprio Relay. O control plane decide; o frontend apresenta.
Se um Relay falha, a Live continua
Viewers afetados recebem nova atribuição — que exclui o Relay anterior — e criam outra sessão WebRTC automaticamente. Sem refresh. Breve interrupção, nunca escondida.
Um distribuidor central vs. Resilient Distribution
Comparação conceitual de arquitetura. O Leap ainda não mediu custo nem latência comparativa — nenhuma superioridade é afirmada antes da evidência.
Distribuição central única
- Um distribuidor concentra todas as sessões de Viewers.
- A falha do distribuidor interrompe todos ao mesmo tempo.
- Recuperar exige restaurar o mesmo ponto central.
Resilient Distribution
- Três Controlled Relays recebem a mídia antecipadamente.
- A falha de um Relay afeta apenas os Viewers atribuídos a ele.
- Reassignment automático move os afetados para Relays saudáveis — comprovado com 10 Viewers reais.
Evidência da POC, não promessa
Duas execuções completas do gate em containers: 1 Controlled Ingress, 3 Controlled Relays e 30 Viewers em processos independentes. Falha real por SIGKILL do relay-a (exit code 137).
Números abaixo são evidência observada da POC — não constituem SLO contratual.
O que estamos medindo agora
A fase atual — Viability POC — expande a evidência antes de qualquer compromisso de produto.
Simulcast validado
Três RIDs medidos e troca na mesma sessão abaixo de dois segundos.
Matriz integral executada
10/13 na primeira passagem; duas causais passaram no rerun. Flutuação ainda aberta.
Perda de host validada
Processo e VM descartável foram interrompidos; o Viewer recuperou a mídia por outro Relay.
Playback resiliente validado
Gate OBS real de 5 min: recovery sem refresh após SIGKILL, em até 22 s.
Do POC à infraestrutura gerenciada
Se a tese for comprovada, o produto pretendido é Managed Streaming Infrastructure para plataformas de terceiros. Esta aplicação é a Reference Application: demonstra, testa e documenta a infraestrutura — sem tentar ser, agora, uma plataforma completa para creators.
Assistir
Reference Application · playback WHEP{{ playbackContextLabel }} · live-01 · {{ sourceStatusText }} · {{ playbackModeText }} {{ playbackBadgeText }}
Control Room
Somente leitura Disponível via APIEstado real de OBS, Ingress, Relay e sessões WHEP no cenário A. Os cenários B/C continuam demonstrativos. Fault injection pertence ao test harness — esta interface observa, não opera.
Topologia viva
{{ obsPoint.label }}
Ingress
{{ g.sub }}
Após reassignment, o Relay expirado permanece visível com link interrompido e 0 Viewers — a exclusão do Relay anterior é comportamento validado.
Controlled Relays
Experimentos
Documentação executável e repositório visual de evidências. Cada execução separa fato observado, limitação, hipótese e próximo teste.
{{ run.name }}
{{ run.id }}{{ run.scenario }}
- {{ l }}
Conclusão. {{ run.conclusion }}
{"run_id":"run-002","status":"passed","executions":2,
"failure":{"target":"relay-a","method":"SIGKILL",
"exit_code":137,"at":"t+180s"},
"distribution":{"before":[10,10,10],"after":[0,15,15]},
"metrics_ms":{
"lease_expiry_detection":[4743,4829],
"reassignment_after_expired":[0,0],
"media_recovery_after_expiry":[49,69],
"end_to_end":[4792,4899]},
"assertions":{"no_central_fallback":true,
"previous_relay_excluded":true,
"recovered_viewers":10}}
Matriz rápida executada · mídia × rede
12 células comprimidas com payload sintético dimensionado e 30 Viewers. Resultado: 11/12 passaram. É evidência de transporte e recovery; a matriz de 5 minutos com OBS visual continua pendente.
20 Mbps · 30 ms · 5 ms jit · 0,1%
5 Mbps · 80 ms · 15 ms jit · 0,5%
2,5 Mbps · 150 ms · 40 ms jit · 2%
12→3 Mbps → 800 kbps · rajadas 5% · corte 2 s → 8 Mbps
H.264 1080p60 · 6 Mbps
H.264 720p30 · 2,5 Mbps
~1080p60·6 + 720p60·4 + 360p60·2 Mbps
A diagnóstica best-case × 4G volátil também passou com a falha sobreposta ao estágio severo. Payload sintético não equivale a qualidade visual.
Métricas instrumentadas
A coleta existe nos artefatos do harness; o histórico ainda não é servido por API.
Tecnologia
O caminho da mídia e o plano de controle, explicados na ordem em que os bits viajam.
O Streamer publica a Live pelo OBS. No smoke real: OBS 32.1.2, H.264 720p30 a 2,5 Mbps e Opus 128 kbps. Validado
Ponto único que recebe a Live. Concessão temporária da POC: a Phase 3 do roadmap existe para removê-lo como ponto único de falha. Validado
Cada Relay renova sua lease por heartbeat (2 s / lease de 6 s, configuráveis) e anuncia o próprio endpoint WHEP — devolvido ao Viewer na atribuição. Um Relay não é necessariamente um Viewer. Validado
Distribuídos em round-robin determinístico. Se o Relay ativo falhar, recebem nova atribuição — excluindo o Relay anterior — e criam outra sessão WebRTC automaticamente, sem refresh. Se nenhum Relay estiver saudável, a indisponibilidade é explícita. Validado
Control plane (Go)
- Leases renovadas por heartbeat — saúde nunca é decidida no frontend.
- Atribuição round-robin determinística e recovery que exclui o Relay anterior.
- Falha detectada pela expiração da lease: 4.743–4.829 ms observados.
Fronteira web
- HTTP/OpenAPI para snapshots e operações.
- SSE com snapshot inicial e eventos em tempo real; ao reconectar, novo snapshot.
- O frontend consome contratos e apresenta fatos — nada além disso.
Evidência
Validado · 2 execuções positivasRelatório do gate de recuperação em containers. Cada seção distingue fato observado, limitação, hipótese e próximo teste. Nenhum número aqui é SLO contratual.
Cenário e condições iniciais
Timeline observada
Fato observado
- Distribuição 10/10/10 → 0/15/15 nos sobreviventes.
- 10 Viewers recuperados com recovered: true e previousRelayId: relay-a.
- Recuperação end-to-end: 4.792–4.899 ms desde a solicitação de falha.
- Nenhuma rota escondida por SFU central.
Limitação · hipótese · próximo teste
Limitação. Rede local sem degradação; um único domínio de falha; Viewers sintéticos.
Hipótese. O piso de ~4,8 s é dominado pela lease de 6 s; leases menores e probes ativos devem reduzi-lo.
Próximo teste. Matriz mídia × rede (12 células + diagnóstica) e playback integrada da Reference Application.
Roadmap
Progresso real por fases — sem porcentagens inventadas. Concluído é o que foi validado; o resto é atual ou próximo.
Phase 0 — Recover and Specify
Concluída- ✓ Fonte de verdade e monorepo estabelecidos
- ✓ Contratos HTTP/OpenAPI e SSE definidos
- ✓ Auditoria dos códigos antigos
Phase 1 — Automatic Recovery
Fase atual- ✓ Gate de recuperação em containers (2 execuções positivas)
- ✓ Smoke real com OBS por WHIP
- ● Playback integrada na Reference Application — em andamento
- ● Operator dashboard somente leitura — em andamento
- ○ Matriz mídia × rede (12 células + diagnóstica)
- ○ Múltiplos domínios de falha além do SIGKILL
Phase 2 — Harden Recovery
PróximaHealth scoring, active probes, RTCP/TWCC, histerese de decisão, testes de carga e tempestades de reconexão.
Phase 3 — Resilient Ingest
PlanejadaRemover o Controlled Ingress como ponto único de falha — o compromisso que encerra a maior concessão da POC.
Phase 4 — Evaluate Continuity Strategies
PlanejadaComparar Preserve PeerConnection, Warm/Hot Standby e Replicated Relay State — com evidência, não preferência.
Post-POC
Condicionada à teseManaged Streaming Infrastructure e primeiro piloto externo — apenas se a Viability POC comprovar a tese.
API & Integrações
O frontend não decide saúde, assignment nem política de recovery — essas regras pertencem ao control plane em Go. A API entrega fatos; a interface os apresenta.
WHIP e WHEP são contratos separados de mídia — não se misturam com os endpoints JSON abaixo.
/healthzSaúde do control plane./v1/snapshotEstado corrente: relays e assignments./v1/eventsSSE best-effort — começa com snapshot; ao reconectar, busque o snapshot novamente./v1/relays/{relayId}/heartbeatRenova a lease do Relay./v1/viewers/{viewerId}/assignmentSolicita atribuição de Relay para um Viewer./v1/viewers/{viewerId}/recoverySolicita recovery — a resposta exclui o Relay anterior.Contratos atuais
type Relay = {
id: string
whepEndpoint: string
healthy: boolean
lastSeenAt: string
leaseExpiresAt: string
viewerCount: number
}
type Assignment = {
viewerId: string
relayId: string
whepEndpoint: string
previousRelayId?: string
recovered: boolean
assignedAt: string
}
type Snapshot = {
generatedAt: string
relays: Relay[]
assignments: Assignment[]
}
type ControlEvent = {
sequence: number
type: string
at: string
relayId?: string
viewerId?: string
previousRelayId?: string
}
Em breve
Visão futura
Página editorial, separada da operação. Nada aqui é produto confirmado — os estágios preservam hipóteses sem confundi-las com o que existe hoje.
Expansão de operadores
Controlled Relays
AtualOperados pela equipe do Leap durante a POC. São a base de toda a evidência atual.
Professional Relay Operators
Em breveOrganizações externas admitidas e monitoradas, operando Relays profissionalmente.
Community Relays
Pesquisa futuraRelays operados por participantes externos. Hipótese preservada, sem compromisso de produto.
Viewer Nodes · opt-in
Pesquisa posteriorDispositivo de Viewer que também distribui capacidade — sempre opt-in. Assistir nunca transforma alguém em Relay automaticamente.
Como Professional Relay Operators seriam admitidos — visão, não produto
- Capacidade reservada comprovada antes de receber tráfego.
- Tráfego entregue e verificado pelo control plane.
- Qualidade e disponibilidade como gates de elegibilidade.
- Compensação futura em moeda fiduciária, por política configurável e versionada.
Sem token, stablecoin, staking, airdrop ou carteira — nada disso é produto confirmado.
Funcionalidades de plataforma preservadas
Em breve — fora da Viability POCA visão completa existe — mas nenhum destes itens é funcional hoje, e nenhum domina a proposta atual.
Autenticação e perfis — Em breve. Esta Reference Application não simula login.