Transmissão
O motor de lives do UDM: uma tela preta subindo do servidor para um destino RTMPS lido da configuração, com o áudio vindo de uma faixa única já mixada — a mesma que qualquer cliente da plataforma consumiria. Sem composição, sem vozes, sem escolha de destino.
Para onde a transmissão vai não aparece nesta tela, e nunca vai aparecer: a chave da live viaja dentro da URL, e o serviço não a devolve em lugar nenhum.
Estado
Perguntando ao serviço…
Os dois botões declaram o estado desejado, não uma transição: finalizar o que já está fora do ar responde a mesma coisa e não recusa. Iniciar com uma transmissão no ar recusa — é uma por vez neste marco. E iniciar sem a faixa de áudio no ar também recusa: uma live que nunca teria som é pior do que uma que não subiu.
Áudio
Perguntando ao serviço…
Estes dois não dependem da live: funcionam com ou sem transmissão no ar, e nunca a derrubam. É por a faixa ser um fluxo contínuo que ligar e desligar o som não reinicia o emissor — o que muda é o valor das amostras, nunca a existência delas.
De onde vem o som
O motor consome uma faixa única, endereçada por configuração, e não sabe quem a produz. Hoje quem produz é o barramento de mistura deste mesmo serviço — uma rota HTTP que qualquer cliente poderia consumir. Amanhã pode ser a captura de uma página num navegador headless, ou uma central de áudio do lado do servidor: a substituição é trocar a URL.
Quando o emissor cai sozinho
Tratar queda está fora de escopo — não há reconexão. O que existe é honestidade: o processo que morre sozinho derruba o estado, e esta tela passa a dizer fora do ar sem ninguém clicar em nada. Estado que mente não é estado.