---
title: Reservas
url: https://doc2.pstreamer.tv/pt/manual/webui/reserves.html
lang: pt-BR
product: Perfect Streamer
version: 2.0.2.423
---

# Reservas

> **Importante**
>
> **Versão beta 2.1.** O que está descrito aqui existe apenas na versão beta 2.1: ela é instalada a partir do repositório beta e somente com uma licença; a versão estável 2.0.2 e a versão de demonstração não têm isso. A versão beta é fornecida sem garantias, e o suporte é prestado na medida do possível ([Programa de testes beta](../extras/beta.md#extras-beta)).

A reserva Meshwork é uma reserva a quente de saídas multicast entre os nós de um mesmo domínio. Vários nós recebem uma mesma origem e mantêm saídas idênticas para um mesmo endereço multicast e uma mesma porta; para esse endereço transmite no ar apenas um deles — o emissor eleito. Se o emissor falhar ou for parado, outro nó assume o grupo, e os receptores continuam recebendo o fluxo do mesmo endereço sem interrupção e sem repetições.

Além dos grupos multicast, a reserva Meshwork forma grupos OTT: a entrega OTT de um mesmo canal em nós diferentes (Grupos OTT).

O estado e as configurações da reserva deste nó estão reunidos na tela «Reservas» da área Meshwork ([Meshwork](meshwork.md#webui-fleet)). A versão de demonstração não tem reserva: o item de menu não está disponível.

## Grupos de reserva

Um grupo é formado pelas saídas dos nós do domínio que enviam para um mesmo endereço multicast e uma mesma porta e que têm o campo «Reserva Meshwork» ativado (bloco «Reserva Meshwork» do editor da saída). Podem ser membros as saídas UDP, RTP e Pro-MPEG ([UDP, RTP, Pro-MPEG e TCP](io/network.md#webui-io-network)). As saídas MPTS são mostradas no grupo, mas não são reservadas.

O que um grupo precisa:

- a reserva está ativada em cada nó com um membro — campo «Reserva Meshwork» da aba «Configurações» da tela «Reservas», seguido de um reinício do serviço;
- os nós têm o nome do nó e o domínio definidos ([Configurações do servidor](administration.md#webui-server-settings)), e todos estão em um mesmo domínio principal: com nós de outro domínio a reserva não se forma;
- a porta UDP do canal de controle (43975 por padrão) está aberta entre os nós do domínio;
- a saída tem um endereço multicast e uma interface de envio, «Multicast egress interface»;
- os fluxos dos membros têm o mesmo «Tipo de fluxo» e o mesmo indicador de canal embaralhado: por eles os nós comparam as origens.

O canal de controle da reserva é protegido pela chave do domínio Meshwork, por isso ela deve ser a mesma em todos os membros. Nós com chaves diferentes não se aceitam: na tabela de nós isso aparece como «Falha de autenticação» e «Diferente» na coluna «Chave».

**Mesma origem ou não.** Os nós comparam continuamente os fluxos dos seus membros pelas marcas de tempo e pelo conteúdo. O resultado aparece na coluna «Origem»: «Mesma origem», «Mesmo sinal» (as mesmas marcas de tempo, outra codificação), «Por rótulo», «Marcas de tempo próprias», «Não comprovada», «Desembaralhamento difere» ou «Pendente» enquanto há poucos dados. Se a entrada do fluxo coloca ela mesma as marcas de tempo (arquivo, RTMP, RTSP, transcodificador, multiplexador MPTS), elas não podem ser comparadas: defina o mesmo campo «Rótulo de origem da reserva» no editor do fluxo em todos os membros.

## Quem envia

No modo padrão — campo «Só o emissor eleito transmite (reserve-gate)» da aba «Configurações», ativado — em cada grupo só o nó eleito envia, e os outros membros mantêm o fluxo pronto. Se esse campo for desativado, a reserva funciona em modo de observação: os membros são verificados e exibidos, mas todos enviam. O campo é lido na inicialização do serviço; defina-o igual em todos os nós do domínio.

O emissor é eleito por votação dos nós do domínio com a reserva ativada. Após iniciar, um nó passa primeiro por uma quarentena: não vota nem concorre até ouvir os votantes (no máximo 15 segundos). Um grupo passa sozinho para outro membro quando:

- o nó do emissor ou o seu canal de controle para de responder;
- a saída do emissor para de enviar;
- a entrada do emissor silenciou ou passou para uma de reserva, e outro membro tem um fluxo melhor.

Se a origem desaparecer em todos os membros ao mesmo tempo, o grupo não comuta. Um nó parado normalmente cede primeiro os seus grupos. Após comutações frequentes, a comutação automática do grupo é suspensa — o grupo fica «congelado» (alerta de código 72, `reserve-frozen`, [Redundância de fluxos](../extras/alert_codes.md#extras-alert-codes-reserve)).

O emissor também pode ser escolhido manualmente: botão «Mover para…» na linha do grupo. O emissor atual e o novo comutam no mesmo instante da escala de tempo do grupo, sem interrupção e sem repetição; a saída do novo membro deve estar aberta e enviando. O campo «Prioridade de reserva» da saída (0–9, o maior primeiro) define o membro preferido, e «Devolver após (s)», após quantos segundos de prontidão desse membro o grupo volta para ele (0 — nunca: o grupo fica até ser movido).

**Domínio de dois nós.** Quando só dois nós votam, um nó reiniciado toma um grupo do outro não antes de 30 segundos após a sua inicialização, e só se o outro nó realmente tiver sumido do Meshwork. Um terceiro nó com a reserva ativada também vota e elimina essa espera; ele não precisa ter membros.

Cada comutação é gravada no registro de eventos do fluxo e aparece na faixa «Reserva» dos gráficos de estatísticas ([A faixa «Reserva»](streams.md#webui-stream-stats-reserve)).

## Atraso de saída

Para que a comutação seja contínua, as saídas de reserva enviam o fluxo com um atraso fixo em relação à entrada — é a escala de tempo do grupo. Ela é definida pelo campo «Atraso de saída (ms)» da aba «Configurações»: de 500 a 2500, 500 por padrão. Defina o mesmo valor em todos os membros do grupo.

Um valor novo se aplica a uma saída quando ela é aberta de novo: na inicialização ou após uma pausa da saída de alguns segundos e o reinício. Uma saída em funcionamento continua com o atraso anterior, e a tela «Reservas» mostra qual valor será aplicado. Se um membro de reserva ficar atrás do emissor, o próprio emissor desloca a escala de tempo do grupo para mais tarde — no máximo 300 ms além do atraso definido e não além de 2500 ms; quando o atraso relativo passa, o atraso volta em passos de 5 ms a cada 5 segundos.

## Segundo caminho e Pro-MPEG

Um membro com uma saída RTP ou Pro-MPEG também pode enviar um segundo caminho segundo o SMPTE ST 2022-7 ([Requisitos de rede para ST 2022-7](../planning/st2022_7.md#planning-st2022-7)). O emissor do grupo envia os dois caminhos. Defina o segundo caminho igual em todos os membros, incluindo «Path 2 multicast egress interface»: os nós também acompanham o emissor pelo segundo caminho. Se o segundo caminho de um membro diferir, o grupo mostra o problema «O caminho 2 difere entre membros» — a troca para esse membro moverá ou removerá o segundo caminho nos receptores.

Se a entrada do fluxo recebe ela mesma dois caminhos, o atraso de saída deve ser no mínimo a janela de espera do segundo caminho («Path skew (ms)» da entrada) mais 400 ms. Caso contrário, a comutação numa perda real da entrada não será contínua, e o grupo mostra o problema «Atraso de reserva menor que a espera da fusão».

Uma saída Pro-MPEG participa da seleção do emissor só com uma matriz FEC determinada e sem multiplexação nem frase-senha ([saída Pro-MPEG em um grupo de reserva](io/network.md#webui-io-prompeg-reserve)).

## Grupos OTT

Um grupo OTT reúne a entrega OTT (HLS, LL-HLS, DASH) de um mesmo canal em nós diferentes do domínio: fluxos ou pacotes adaptativos com o mesmo nome de grupo. Os membros se encontram e se verificam, e um espectador HLS cujo nó falhou continua assistindo a partir de outro membro, sem sair do player (Troca dos espectadores para outro nó).

**Como ativar.** A reserva Meshwork precisa estar ativada no nó (Grupos de reserva). Depois, em um fluxo (aba «Fluxo» do editor, bloco «Reserva Meshwork») ou na janela de um pacote adaptativo, ative o campo «Reserva OTT» e defina «Nome do grupo de reserva»:

- até 64 caracteres `A-Z a-z 0-9 _ . -`, diferencia maiúsculas de minúsculas; o mesmo nome em todos os nós por onde o canal passa;
- com o campo vazio, o nome do grupo é o nome OTT: «Nome do fluxo no URL» em um fluxo, «Nome OTT» em um pacote. Sem nenhum dos dois nomes, o membro não é anunciado aos outros nós;
- uma alteração é aplicada em até um segundo e não reinicia a entrega OTT do fluxo.

Só pode ser membro um fluxo SPTS com a entrega OTT ativada; em um fluxo MPTS o campo não tem efeito. Um pacote adaptativo é um único membro, e seus degraus são os fluxos do pacote com vídeo. As fontes dos fluxos são comparadas como nos grupos multicast, por isso «Tipo de fluxo» e «Canal embaralhado» precisam coincidir entre os membros; os pacotes adaptativos são pareados pelo nome. Para que os outros nós acessem o servidor OTT deste nó por nome, defina o «Nome do anfitrião» do servidor HTTP ([Servidor HTTP de streaming](administration.md#webui-http-server)): sem ele, os outros nós recebem o endereço do nó, e só por HTTP se o certificado do nó não for emitido para esse endereço.

**O cartão do grupo OTT** na aba «Estado» mostra o nome do grupo, os formatos que ele serve («Serve: …»), o estado, o resultado da comparação da fonte e os problemas. Estados:

- «Com reserva»: um membro em outro nó pode substituir este;
- «Desprotegido»: outros nós têm membros, mas nenhum pode substituir este;
- «Chave pendente»: o nó ainda não tem uma chave de domínio acordada;
- «Não é membro»: a reserva OTT está ativada, mas o fluxo ou pacote não participa: sem nome de grupo, nome inválido, fluxo MPTS ou ainda sem domínio; o motivo está nos problemas;
- «Nome duplicado»: dois fluxos ou pacotes deste nó têm o mesmo nome de grupo, e nenhum deles é anunciado.

Para cada membro, o cartão mostra: «Reserva», que é «Pode substituir» ou «Não oferecido» com a primeira verificação reprovada; «Troca do espectador», ou seja, como um espectador passaria para este membro («Alinhado», «Mesma linha do tempo» ou «Do zero»); «Ao vivo» e «Arquivo». Um membro em um nó de versão anterior à 2.1.0.456 não aceita espectadores: se as demais verificações passarem, a coluna «Reserva» mostra «Sua versão ainda não assume espectadores». Se todos os membros dos outros nós forem assim, o grupo fica sem proteção.

Problemas de um grupo OTT:

| Problema | O que significa |
| --- | --- |
| «Sem nome de grupo» | Nem «Nome do grupo de reserva» nem nome OTT: o membro não é anunciado. |
| «Nome de reserva inválido» | Um nome com caracteres não permitidos ou com mais de 64 caracteres, lido do arquivo de configurações. Enquanto não for corrigido, o fluxo não é membro; o nome OTT não o substitui. |
| «Sem reserva em outro nó» | Há 60 segundos nenhum membro de outro nó pode substituir este: os outros nós não têm esse nome ou os membros não passam nas verificações (detalhes na descrição do problema). O nó gera o alerta de código 70 (`reserve-unprotected`). |
| «Formatos OTT diferentes» | Os membros servem formatos OTT diferentes. |
| «Sem nome de host para o servidor OTT» | O «Nome do anfitrião» do servidor HTTP não está definido: os outros nós recebem o endereço do nó, e só por HTTP se o certificado do nó não for emitido para esse endereço. É uma informação, não um erro. |
| «Nome de host do servidor OTT inválido» | O «Nome do anfitrião» do servidor HTTP não é um nome de host: o nó não informa aos outros nós o endereço do seu servidor OTT. |
| «O relógio de um nó está muito fora» | O relógio do nó de outro membro difere do relógio deste nó em mais de 240 segundos: esse membro não pode substituir este. |
| «Ainda sem chave de visualização» | O nó tem um membro da reserva OTT, mas ainda não tem a chave de visualização do domínio: os espectadores deste nó não passam para outros nós, e ele não aceita espectadores de reserva. Após 2 minutos, se a chave puder vir de outro nó, o nó gera o alerta de código 78 (`reserve-view-key`). |
| «A chave de visualização não chega a este nó» | Os outros nós têm a chave, mas ela não chega a este nó; verifique a comunicação entre os nós do domínio (alerta de código 78). |
| «Um nó não assumiu a chave de visualização» | Um nó com um membro da reserva OTT não confirma a chave vigente há 10 minutos (alerta de código 78). |
| «Chaves de visualização demais» | O nó guarda mais de quatro chaves de visualização (alerta de código 78). |
| «Sobrecarregado para espectadores de reserva» | O nó recusa novos espectadores de reserva: a CPU ou a rede estão no limiar, ou o «Limite de sessões de reserva» foi atingido (Proteção contra sobrecarga). |
| «As escadas de bitrate diferem» | Para parte dos degraus deste membro, o membro de outro nó não tem um degrau com o mesmo codec e um bitrate compatível: nesses degraus não há reserva. Um membro com o qual nenhum degrau corresponde há 60 segundos não é oferecido: a coluna «Reserva» mostra «Nenhum dos seus degraus corresponde aos deste nó». |
| «Um nó não tem endereço https para a reserva» | O nó do membro não informa o endereço HTTPS do seu servidor OTT: ele não é oferecido como reserva a espectadores por HTTPS. Defina nesse nó o «Nome do anfitrião» do servidor HTTP para o qual o seu certificado foi emitido. |
| «Um nó só tem endereços privados para a reserva» | O nó do membro só informa endereços privados: ele não é oferecido como reserva a espectadores com endereços públicos. |

## Troca dos espectadores para outro nó

A partir da versão 2.1.0.458, a playlist master do HLS ao vivo de um membro de um grupo OTT indica até dois outros nós do grupo como variantes de reserva de cada degrau, depois das próprias. Um player que suporta variantes de reserva passa sozinho para o nó de reserva quando o nó do espectador deixa de servir a janela ao vivo; o espectador não sai do player. Se o fluxo do nó parou ou travou e a reserva está no ar, o nó responde de imediato a esse espectador com `404` para a playlist, e o player troca de nó sem esperar pelos seus tempos limite. Os espectadores de um nó que falhou são distribuídos entre as suas reservas.

**Players.** Recebem variantes de reserva os players que sabem usá-las: AVPlayer (Safari, iOS, tvOS), hls.js e players semelhantes no navegador, ExoPlayer e Media3. Os players que não sabem trocar assim (VLC, mpv, Kodi, GStreamer, players baseados em ffmpeg, set-top boxes sem User-Agent) recebem a playlist master sem linhas de reserva e funcionam como antes; quantas playlists master desse tipo foram entregues é mostrado pela linha «Playlists mestres sem reserva» do bloco «Chave de visualização OTT». O que cada player recebe e o que foi testado: [Players e a reserva OTT/DVR](../extras/ott_players.md#extras-ott-players); o que levar em conta no cache e na CDN: [8.1. Reserva OTT/DVR e CDN](../extras/ott_caching.md#extras-ott-cdn-reserve). O aplicativo próprio do operador pode solicitar as reservas com o parâmetro `rsv=1` no URL da playlist master ou recusá-las com o parâmetro `rsv=0`.

Para o hls.js, defina tempos limite curtos para o carregamento da playlist e do segmento — cerca de uma duração-alvo de segmento, 2–3 segundos: assim o player sai rapidamente de um nó travado.

**Qual nó se torna reserva.** Um nó só é indicado como reserva se o seu membro puder substituir o membro deste nó (coluna «Reserva»: «Pode substituir») e se, no momento da requisição:

- serviu a janela ao vivo recentemente e serve HLS;
- o seu relógio difere do relógio deste nó em no máximo 240 segundos;
- os nós têm uma chave de visualização comum (abaixo);
- o nó não está sobrecarregado (Proteção contra sobrecarga);
- ele tem um degrau com o mesmo codec;
- o espectador consegue alcançá-lo da mesma forma: um espectador por HTTPS precisa de um endereço HTTPS do nó de reserva; um espectador com endereço público, de um endereço público. Por isso, defina o «Nome do anfitrião» do servidor HTTP em cada nó ([Servidor HTTP de streaming](administration.md#webui-http-server)).

**Chave de visualização.** O nó de reserva aceita o espectador de outro nó mediante um passe vinculado à sessão do espectador, ao seu nó, ao fluxo e ao horário. Os passes são assinados com a chave de visualização, comum aos nós do domínio com membros da reserva OTT. Não é preciso configurar nada: a chave é criada automaticamente, trocada a cada 7 dias e guardada apenas na memória; o seu estado é mostrado pelo bloco «Chave de visualização OTT» na aba «Estado», e o botão «Trocar a chave de visualização» a troca manualmente. Se a chave não chegar a um nó, o nó gera o alerta de código 78 (`reserve-view-key`).

**Limitações desta versão beta.** Só recebem variantes de reserva os fluxos individuais cujos membros em nós diferentes usam a mesma origem (troca «Mesma linha do tempo»). Os pacotes adaptativos, o LL-HLS e o DASH são reunidos em grupos e exibidos, mas ainda não têm reservas na playlist master e no manifesto; esses espectadores são protegidos apenas pelo redirecionamento na abertura (Redirecionamento dos espectadores). As legendas permanecem no nó original após a troca. A playlist master do arquivo e do catch-up não indica reservas: o espectador recebe o arquivo dos outros nós por redirecionamento.

## Redirecionamento dos espectadores

A partir da versão 2.1.0.459, o nó redireciona o espectador para outro nó do grupo OTT (resposta `302`) já na abertura da playlist master HLS e LL-HLS ou do manifesto DASH. O redirecionamento não exige suporte do player: todos os players o seguem, inclusive o VLC e as set-top boxes, e, para o DASH, é a única proteção da transmissão ao vivo nesta versão beta. Funciona para fluxos e pacotes adaptativos com a «Reserva OTT» ativada.

**Catch-up a partir do arquivo de outros nós.** Se o espectador pede um período passado que não está no arquivo deste nó, o nó o envia ao nó do grupo que guarda a maior parte do período; a profundidade do arquivo pode ser diferente em cada nó. Se nenhum nó guardar o período, o espectador recebe `404` (`reserve: no recording for this period`) — antes, uma playlist vazia. Para o HLS conta o arquivo MPEG-TS; para o LL-HLS e o DASH, o arquivo fMP4.

A troca para o arquivo de outro nó é decidida pelo intervalo do arquivo — da gravação mais antiga à mais recente. Se o início do período solicitado cai no intervalo do arquivo deste nó, o próprio nó atende o espectador, mesmo que naquele momento haja uma lacuna no seu arquivo (por exemplo, enquanto a entrada não funcionava): as lacunas dentro do intervalo não são transferidas para outro nó.

**Novos espectadores de um fluxo que não está funcionando aqui.** O espectador que abre um fluxo que não está funcionando neste nó — parado ou em pausa, em erro, com a entrada caída ou ainda sem imagem — é enviado pelo nó para um nó onde esse fluxo está no ar. Um fluxo que está apenas iniciando não é afetado: assim que aparece um segmento na sua janela ao vivo, os espectadores são atendidos por este nó. Um nó reiniciado com o fluxo em pausa não redireciona novos espectadores até o fluxo funcionar pelo menos uma vez.

**Login primeiro.** Nos fluxos com a «Reserva OTT» ativada, o login do espectador é verificado antes de tudo: com uma senha incorreta a resposta é sempre `403`, mesmo que o fluxo não esteja funcionando. Os demais fluxos respondem como antes.

**Limite de conexões.** O «Máx. de ligações, HTTP/HLS» do login ([Usuário: adicionar e alterar](configure.md#webui-user-editor)) vale em cada nó separadamente: um assinante redirecionado pode abrir o mesmo número de sessões também no outro nó.

O nó é escolhido da mesma forma que a reserva para a troca (Troca dos espectadores para outro nó), mas o player e o nível da troca não são verificados, por isso servem também os pacotes adaptativos e o LL-HLS. A rede do espectador não é levada em conta na escolha do nó para o catch-up: o outro nó deve estar acessível ao espectador da mesma forma — para HTTPS, é preciso um endereço HTTPS.

## Proteção contra sobrecarga

Um nó de reserva aceita um novo espectador de outro nó (espectador de reserva) apenas enquanto tem folga: a carga da CPU do host e da interface de rede abaixo dos limiares de erro desses recursos nas configurações de alertas ([Alertador](administration.md#webui-alerter)), e o número de sessões de reserva abaixo do «Limite de sessões de reserva» na aba «Configurações» (0 — sem limite, aplicado imediatamente). Um limiar 0 desativa a sua verificação. O nó nunca recusa os seus próprios espectadores nem as sessões de reserva já abertas. Ao receber uma recusa, o player passa para a reserva seguinte, e os outros nós deixam por algum tempo de indicar o nó sobrecarregado como reserva.

O bloco «Proteção OTT contra sobrecarga» na aba «Estado» mostra se há folga, as causas da sobrecarga, a folga de rede e de sessões, os limiares, o número de sessões de reserva e de recusas. Enquanto a causa persistir, os grupos OTT do nó têm o problema «Sobrecarregado para espectadores de reserva». Se o nó recusar novos espectadores de reserva por 30 segundos seguidos, ele gera o alerta de código 79 (`reserve-ott-overload`); o alerta é resolvido após 60 segundos sem recusas.

## Tela «Reservas»

A tela mostra os grupos em que este nó tem um membro; os outros nós mostram os seus. Se a reserva estiver desativada no nó, a tela explica como ativá-la e oferece o link «Abrir configurações».

**Aba «Estado».**

- Os cartões «Grupos», «Grupos com problemas», «Erros», «Avisos», «Nós no canal» e «Grupos por estado».
- O bloco «Canal de controle deste nó»: estado do canal, relógios («Sincronizado» ou «Não sincronizado»), impressão digital da chave, nós votantes, quarentena e «Tempos» — tomada, janela e atraso; os contadores «Grupos OTT» e «Relatórios não enviados» (relatórios que não couberam em um datagrama ou foram adiados para a próxima rodada).
- A tabela «Nós»: uma linha para cada nó do canal — «Canal», «Chave», «RTT, ms», «Desvio do relógio, ms», «Perda, %», «Última resposta» e «Versão».
- A lista «Grupos». De cada grupo: o estado, a função deste nó, o emissor e o número da eleição, os membros com prioridade, função, o indicador «Transmite» e o resultado da comparação da origem, o bloco «Saída deste nó» e a lista de problemas. Estados do grupo: «Sozinho» (os outros membros não se reportam), «Formando» (membros encontrados e em verificação), «Divergência» (os membros têm tipo de fluxo ou indicador de canal embaralhado diferentes) e «Conflito» (alguém que não faz parte do grupo envia para ele).

Função deste nó no grupo: «Emissor», «Em reserva», «Concorrendo», «Sozinho», «Não pronto», «Quarentena», «Aguardando a chave do domínio», «Emissor não confirmado», «Afastado», «Liberado», «Passando a função», «Assumindo a função», «Não verificado» ou «Nenhum».

O bloco «Saída deste nó» mostra se a saída está aberta («Aberta: este nó transmite» ou «Fechada: outro membro transmite»), se está alinhada à escala de tempo do grupo, a margem, o atraso, o FEC de grupo de uma saída Pro-MPEG e os contadores de datagramas. Contadores crescentes de datagramas atrasados, estouros e erros de envio são destacados; um membro de reserva atrasado é marcado: a comutação para ele não será contínua.

**Aba «Configurações».** Os campos «Reserva Meshwork», «Só o emissor eleito transmite (reserve-gate)», «Porta UDP do canal de controle» (1024–65535, 43975 por padrão), «Interface do canal de controle» («Todas as interfaces» por padrão), «Atraso de saída (ms)», «Devolver após (s)», «Limite de sessões de reserva» (Proteção contra sobrecarga) e «Interface de testemunha» (para um nó que só vota; ainda não usado nesta versão). A ativação da reserva, o modo, a porta e a interface são lidos na inicialização do serviço: as alterações valem após um reinício.

## Problemas do grupo

| Problema | O que significa |
| --- | --- |
| «Conflito de endereço» | Uma origem que não faz parte do grupo envia para ele (alerta de código 71, `reserve-address-conflict`). |
| «Dois transmissores» | Dois membros enviam para o grupo ao mesmo tempo (alerta de código 67, `reserve-two-senders`). No modo de observação, isso é um aviso: lá todos enviam. |
| «Configurações diferentes» | Os membros têm «Tipo de fluxo» ou indicador de canal embaralhado diferentes. |
| «Conteúdo contradiz as configurações» | O fluxo de um membro não corresponde às suas configurações: por exemplo, há vídeo com o tipo de fluxo «Apenas áudio». Valem as configurações. |
| «Origem não comprovada igual» | A origem de um membro não pode ser comparada por 30 segundos (alerta de código 68, `reserve-source-mismatch`). |
| «Desembaralhamento difere» | As partes abertas dos fluxos coincidem, mas o conteúdo não: um dos nós não desembaralha. |
| «Marcas de tempo próprias, sem rótulo de origem» | A entrada do membro coloca ela mesma as marcas de tempo: defina o mesmo «Rótulo de origem da reserva». |
| «Membro não verificado» | Um nó anuncia um membro, mas os seus relatórios não chegam a este nó. |
| «Duas saídas deste nó» | Duas saídas de um mesmo nó enviam para um mesmo grupo. |
| «Falta a interface de saída multicast» | A saída membro não tem interface de envio definida. |
| «Este nó não vê o grupo» | Este nó não pode observar o grupo; os detalhes estão na descrição do problema. |
| «MPTS listado, não reservado» | Uma saída MPTS é mostrada no grupo, mas não é reservada. |
| «Entrada DVB, ainda não testada» | O fluxo vem de uma entrada DVB. |
| «O caminho 2 difere entre membros» | O segundo caminho de um membro vai para outro endereço ou não está definido. |
| «Atraso de reserva menor que a espera da fusão» | O atraso de saída é menor que a janela de espera do segundo caminho da entrada mais 400 ms. |
| «Membro ProMPEG sem portão: matriz ou packets» | A saída Pro-MPEG não participa da seleção do emissor: «colunas × linhas» não é uma potência de dois, ou o datagrama não leva 7 pacotes TS. Ela envia sempre, ao lado do emissor do grupo, e não assume o grupo. |
| «Membro ProMPEG sem portão: multiplexação ou senha» | O mesmo, numa saída com multiplexação ou frase-senha. |
| «A matriz FEC ProMPEG difere» | A matriz FEC de um membro difere, ou a sua versão não a informa: a troca para ele altera a matriz nos receptores. |

Os alertas de reserva — códigos 66–74, 78 e 79 — estão listados em [Redundância de fluxos](../extras/alert_codes.md#extras-alert-codes-reserve).