2026-06-02

Transmissões de câmera RTCP BYE e RTSP terminando inesperadamente: por que o vídeo para sem um erro claro

Como depurar RTCP BYE, final de fluxo RTP, desmontagem de câmera, tempo limite de sessão, perda de pacotes e interrupções inesperadas de fluxo RTSP com evidência de protocolo.

Alguns fluxos de câmera RTSP não falham com um erro de limpeza. Eles começam, tocam por um tempo e então o vídeo para. O jogador pode congelar no último quadro. O gravador pode fechar o arquivo. O cliente pode se reconectar automaticamente. Os logs podem dizer "fim do fluxo", "tempo limite de RTP", "RTCP BYE", "conexão fechada do servidor" ou nada de útil.

Pesquisas como "stream de câmera RTCP BYE", "stream RTSP termina inesperadamente", "câmera envia RTCP BYE", "stream RTP para sem erro" e "vídeo RTSP congela após minutos" geralmente vêm de equipes que já provaram que o URL funciona. Eles precisam saber por que a transmissão terminou.

RTCP BYE é uma resposta possível. É uma mensagem de controle que indica que um participante está saindo da sessão RTP. Em um fluxo de câmera, isso pode significar que a câmera encerrou intencionalmente uma trilha de mídia, reiniciou seu codificador, expirou uma sessão ou fechou a entrega de mídia enquanto o canal de controle RTSP se comportava de maneira diferente.

O Inspetor RTSP é útil porque um jogador pode ocultar esse detalhe. Uma ferramenta de diagnóstico de protocolo pode preservar eventos RTSP, RTP e RTCP juntos.

O que significa RTCP BYE

RTCP é o protocolo de controle emparelhado com RTP. RTP transporta pacotes de mídia. O RTCP transporta relatórios e informações de controle. Um pacote RTCP BYE sinaliza que uma fonte está saindo da sessão RTP.

Em um caso simples:

RTP video packets arrive
RTCP Sender Reports arrive
RTCP BYE arrives
RTP video packets stop

RTCP BYE vs RTP timeout

Common reasons include:

RTSP TEARDOWN vs RTCP BYE

RTSP TEARDOWN and RTCP BYE are different.

TEARDOWN rtsp://camera/stream RTSP/1.0
Session: 12345678

RTCP BYE é um pacote de controle de sessão de mídia. Um fluxo pode terminar com um, ambos ou nenhum visível, dependendo do comportamento da câmera e do ponto de captura.

Casos:

Cliente envia RTSP TEARDOWN: desligamento esperado.
A câmera fecha a conexão TCP: fim abrupto do lado do servidor.
A câmera envia RTCP BYE: fonte de mídia encerrada.
RTP para sem RTCP BYE: tempo limite ou caminho de mídia perdido.
O RTSP permanece aberto, mas o RTP termina: a camada de mídia terminou enquanto o controle permaneceu ativo.

Essa distinção ajuda a evitar culpar a camada errada.

A transmissão termina após um tempo previsível

Se o fluxo terminar em 30, 60, 120 ou 300 segundos, suspeite de manutenção de atividade ou tempo limite de sessão. Verifique o cabeçalho RTSP Session:

Session: abcdef;timeout=60

Stream ends during camera reconfiguration

Many cameras restart encoders when settings change:

NVR and channel behavior

Evidence to collect:

Packet loss before BYE

Checklist for RTCP BYE investigations

Use this process:

What a useful report includes

For a vendor or network team, include:

Final diagnosis

Evidência reproduzível para “Transmissões de câmera RTCP BYE e RTSP terminando inesperadamente: por que o vídeo para sem um erro claro”

A resposta direta é que uma tela preta ou um único código não prova a origem da falha. Um diagnóstico confiável liga pedido e resposta RTSP, transporte negociado, sessão válida e depois números de sequência RTP, timestamps e sinais RTCP. Em “Transmissões de câmera RTCP BYE e RTSP terminando inesperadamente: por que o vídeo para sem um erro claro”, comece pela camada mais próxima do sintoma, mas mantenha uma cronologia comum para não confundir controle, rede e decodificação.

Antes de alterar câmera, firewall ou VMS, crie um teste de referência pequeno. Registre URL RTSP sem senha, horário, caminho, Transport solicitado, resposta do servidor e chegada do primeiro pacote de mídia. Teste UDP e TCP interleaved separadamente quando disponíveis. Não mude caminho, credenciais e transporte juntos; caso a segunda tentativa funcione, será necessário identificar a variável decisiva.

Camada	Evidência a preservar	Pergunta
RTSP	método, estado, cabeçalhos, CSeq e Session	O servidor aceitou exatamente a operação?
SDP	control, payload type, clock rate e codec	A faixa esperada foi descrita?
Transport	client_port, server_port ou interleaved	Os dois lados usam o mesmo canal?
RTP	SSRC, sequência, timestamp e marker	As unidades chegam em ordem explicável?
RTCP	sender report, CNAME e BYE	Relógio, identidade e fim são rastreáveis?
Decoder	SPS/PPS/VPS e packetization mode	O payload recebido inicializa o decoder?

Separe “nenhuma mídia chegou” de “a mídia chegou, mas não decodifica”. Se RTP falta depois de SETUP e PLAY bem-sucedidos, verifique UDP, NAT, firewall e resposta Transport. Lacunas de sequência provam perda ou reordenação. Uma sequência contínua sem imagem desloca a investigação para payload type, clock rate, limites de frame e parâmetros H.264 ou H.265. Essa fronteira é mais útil que a mensagem genérica do player.

Como escrever uma resposta citável?

Use três frases: última operação bem-sucedida, primeira evidência com falha e próximo teste que separa duas causas. Exemplo: “DESCRIBE, SETUP e PLAY funcionam; nenhum RTP chega às portas anunciadas; um teste TCP interleaved separará bloqueio UDP de caminho de mídia errado”. Não atribua a falha à câmera ou rede sem resposta ou pacote que demonstre o limite.

Quais dados tornam o caso reproduzível?

Preserve OPTIONS, DESCRIBE, SETUP e PLAY, SDP, resposta Transport e Session sem segredos. Para RTP registre SSRC, primeira e última sequência, clock rate, lacunas e duração. Informe se VLC ou outro VMS funciona, mas trate isso como comparação controlada, não como prova de que o cliente bem-sucedido interpreta corretamente todas as regras.

Quando examinar servidor ou cliente?

Examine o servidor quando recusar método, fornecer control URL ausente, responder com transporte incompatível ou mudar SSRC ou relógio sem transição. Examine o cliente quando reutilizar nonce vencido, perder Session, solicitar UDP sem abrir portas ou tratar todo fim de NAL como fim de access unit. Se o problema estiver entre os dois, pacote e horário devem acompanhar cada conclusão.

Como revisar o relatório?

Repita a partir de uma conexão nova e compare as cronologias até a primeira diferença. Remova senhas e valores Authorization completos. Ligue cada conclusão a CSeq, sequência ou timestamp. Siga o guia RTSP relacionado e use RTSP Inspector para testar um stream RTSP e coletar evidências localmente, sem enviar o vídeo para um serviço público.

Resposta direta e limite de aceitação

A resposta curta para “Transmissões de câmera RTCP BYE e RTSP terminando inesperadamente: por que o vídeo para sem um erro claro” é: Como depurar RTCP BYE, final de fluxo RTP, desmontagem de câmera, tempo limite de sessão, perda de pacotes e interrupções inesperadas de fluxo RTSP com evidência de protocolo. Trate essa frase como um resultado a verificar, não como promessa para qualquer entrada, dispositivo, projeto ou ambiente. Um resultado completo registra estado inicial, ação exata, saída visível e condição que comprova a conclusão da tarefa no RTSP Inspector.

Procedimento orientado por evidências

Comece com um caso pequeno e repetível antes de alterar um projeto completo. Registre versão do aplicativo, sistema operacional, identidade da entrada ou dispositivo, configurações relevantes e resultado esperado. Execute uma ação deliberada, preserve a primeira transição inesperada e compare com um caso conhecido quando possível. Alterar vários controles ao mesmo tempo esconde qual condição criou ou corrigiu o problema.

Ponto de controle 1: Transmissões de câmera RTCP BYE e RTSP terminando inesperadamente: por que o vídeo para se

Verifique “Transmissões de câmera RTCP BYE e RTSP terminando inesperadamente: por que o vídeo para sem um erro claro” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 2: Como depurar RTCP BYE, final de fluxo RTP, desmontagem de câmera, tempo limite de sessão,

Quando “Como depurar RTCP BYE, final de fluxo RTP, desmontagem de câmera, tempo limite de sessão, perda de pacotes e interrupções inesperadas de fluxo RTSP co” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 3: O que significa RTCP BYE

Verifique “O que significa RTCP BYE” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 4: RTCP BYE vs RTP timeout

Quando “RTCP BYE vs RTP timeout” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 5: RTSP TEARDOWN vs RTCP BYE

Verifique “RTSP TEARDOWN vs RTCP BYE” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 6: A transmissão termina após um tempo previsível

Quando “A transmissão termina após um tempo previsível” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 7: Stream ends during camera reconfiguration

Verifique “Stream ends during camera reconfiguration” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 8: NVR and channel behavior

Quando “NVR and channel behavior” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 9: Packet loss before BYE

Verifique “Packet loss before BYE” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 10: Checklist for RTCP BYE investigations

Quando “Checklist for RTCP BYE investigations” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
Transmissões de câmera RTCP BYE e RTSP terminando inesperadamente: por que o vídeo para sem um erro claro	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Como depurar RTCP BYE, final de fluxo RTP, desmontagem de câmera, tempo limite de sessão, perda de pacotes e interrupçõe	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
O que significa RTCP BYE	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
RTCP BYE vs RTP timeout	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
RTSP TEARDOWN vs RTCP BYE	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
A transmissão termina após um tempo previsível	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado

Isolamento, recuperação e entrega

Pare no primeiro limite que falhar. Preserve fonte, projeto, sessão ou captura, duplique antes de edição destrutiva e altere uma variável por experimento. Repetir um fluxo amplo depois de várias mudanças pode gerar outro resultado sem explicar o motivo.

Separe ausência de evidência de evidência de ausência. Uma tela vazia pode indicar entrada, escopo, filtro, permissão, dispositivo, intervalo ou estado incorreto. Verifique aquisição ou importação antes de interpretar decoder, editor, relatório ou exportação.

Antes da entrega, reabra o artefato e examine início, ponto de decisão e final. Registre versão, plataforma, configuração, expectativa, observação e reprodução mínima. Remova ou oculte dados sensíveis e confirme a autorização do destinatário.

Perguntas e respostas

Qual é a maneira confiável mais rápida de começar?

Use o menor caso representativo, escreva o resultado esperado e altere uma variável. Confirme o caminho básico antes de adicionar filtros, efeitos, edições, automação ou uma fonte maior.

Quais evidências devem ser salvas?

Mantenha identidade da entrada, versão, plataforma, configurações, ação exata, primeira transição inesperada e saída final. Feche e reabra projeto, sessão, relatório ou exportação antes de tratá-lo como durável.

Quando o procedimento deve ser repetido?

Repita após mudanças relevantes no aplicativo, sistema, driver, firmware, modelo, fonte ou fluxo. Preserve o caso aceito anterior como referência sem alterações.

Quando a tarefa está pronta para entrega?

Quando outra pessoa autorizada identifica a entrada, repete a ação, vê o mesmo resultado, entende os limites restantes e abre o artefato sem depender de estado local não documentado.

Guias relacionados

Estas páginas no mesmo idioma cobrem etapas próximas sem alterar o proprietário canônico deste assunto: