Alterações no fluxo de configuração do RTS - ApsaraVideo Live: Central de Documentação do Alibaba Cloud

O console do Alibaba Cloud Real-Time Streaming (RTS) foi atualizado para simplificar a configuração. Saiba como migrar as configurações legadas para a nova versão e comece a usar a nova interface.

Visão geral das alterações

O console do RTS passou por uma atualização completa para facilitar a ativação, a configuração e os testes de ingestão e reprodução de streams do RTS. Os conceitos de RTS 1,0 e 2,0 foram removidos para reduzir a curva de aprendizado e eliminar a necessidade de gerenciar diferenças entre versões.

Comparação das alterações

Versão legada

Na versão legada, o RTS 1.0 oferecia latência de ponta a ponta de 500 ms a 1.000 ms, exigia integração do SDK apenas no lado da reprodução e era compatível com transmissões ao vivo padrão. O RTS 2.0 proporcionava latência de ponta a ponta de 200 ms a 400 ms e requeria a integração do RTS SDK tanto para ingestão quanto para reprodução, implementando um pipeline WebRTC completo. Um botão de RTS Playback estava disponível na parte inferior da página.

Na antiga página de configuração de RTS Ingest, os recursos de Low-latency Ingest (RTS 1.0) e Real-time Ingest (RTS 2.0) eram comparados lado a lado. O botão de RTS Ingest ficava ativado e definido como Low-latency Ingest (RTS 1.0), com um aviso indicando a necessidade de um certificado HTTPS.

As configurações eram separadas nas versões 1,0 e 2,0. Cada versão correspondia a protocolos e latências diferentes.
Os navegadores não suportavam B-frames de vídeo ou áudio AAC durante a reprodução do RTS. Era necessário ativar ou desativar a transcodificação automática H5 na configuração do RTS do domínio de streaming.
Os domínios de ingestão e de streaming precisavam ser configurados separadamente. Configurações inconsistentes frequentemente causavam indisponibilidade do serviço.
Não era possível gerar diretamente uma URL de streaming no console para testar o serviço.

Nova versão

Ao selecionar a opção de half-second latency na nova página de configuração, um alerta indica que ela não é compatível com transmissões ao vivo padrão e que não é possível usar recursos de nuvem como transcodificação ou gravação.

A distinção entre versões foi removida. Em vez disso, selecione uma opção com base nos seus protocolos de ingestão e reprodução:
- Apenas ingestão e reprodução ARTC: latência de ponta a ponta de 200 ms a 400 ms.
- Ingestão RTMP/ARTC + reprodução HLS/FLV/RTMP/ARTC: latência de ponta a ponta de 400 ms a 800 ms.
Após ativar o Real-Time Streaming (RTS) e selecionar a latência abaixo de um segundo, o sistema ativa automaticamente a transcodificação automática H5 para remover B-frames e transcodificar o áudio para Opus. Nenhuma configuração extra é necessária.

Nota
A transcodificação automática H5 é acionada apenas durante a reprodução no navegador e não pode ser desativada manualmente. Caso precise desativar esse recurso, envie um ticket.

Se esse recurso estivesse desativado na versão legada, ele permanecerá desativado. Para ativá-lo, desligue e ligue novamente o botão do Real-Time Streaming (RTS). Essa ação ativa o recurso por padrão.
Os domínios de ingestão e de streaming são configurados em conjunto para garantir consistência e evitar indisponibilidade do serviço.

Nota
Se as configurações dos domínios de ingestão e de streaming estivessem inconsistentes na versão legada, a nova interface exibirá um erro de configuração. Clique em Reconfigure para ajustar as definições.
Agora é possível gerar uma URL de streaming no console para testar a ingestão e a reprodução de streams do RTS.

Nota
Para testes rápidos, o console do ApsaraVideo Live utiliza um domínio de sinalização proxy. No entanto, ao usar o Web RTS SDK para ingestão e reprodução de streams do RTS, você também deve configurar um certificado SSL e configurar um cabeçalho HTTP, como o cabeçalho de resposta Access-Control-Allow-Origin (por exemplo, *), para o seu domínio.

Tratamento de configurações anômalas

Na configuração legada do RTS, definições inconsistentes entre os domínios de ingestão e de streaming frequentemente causavam falhas na ingestão ou na reprodução de streams.

Caso	Domínio de streaming	Domínio de ingestão	Impacto
Caso 1	Não ativado	2.0	A ingestão de stream RTMP não é suportada, causando problemas de reprodução.
Caso 2	1.0	Não ativado	A ingestão de stream ARTC não é suportada, causando problemas de reprodução.
Caso 3	2.0	Não ativado	A ingestão de stream ARTC não é suportada, causando problemas de reprodução.
Caso 4	1.0	2.0	A ingestão de stream RTMP não é suportada, causando problemas de reprodução.
Caso 5	2.0	1.0	Ocorrem problemas de reprodução.

Acesse o console do Real-Time Streaming e clique em Reconfigure para corrigir as definições. Se o problema persistir, envie um ticket.

Latência abaixo de um segundo

Recursos: Latência de ponta a ponta de 400 a 800 ms. Compatível com transmissões ao vivo padrão e outros protocolos de ingestão e reprodução.
Protocolos suportados: ARTC (baseado em WebRTC) para ingestão e reprodução. Compatibilidade futura com transmissões ao vivo padrão: suporta ingestão RTMP, origin pull e reprodução RTMP/FLV/HLS.
Ferramentas de ingestão e reprodução: Compatível com a maioria das ferramentas comuns. Recomendado: SDK de Ingestão do Alibaba Cloud Live e SDK de Player do Alibaba Cloud Live.
Outras observações: Se o stream contiver B-frames ou áudio não Opus, o sistema remove automaticamente os B-frames e transcodifica o áudio para Opus para reprodução H5, incorrendo em taxas de transcodificação ao vivo.

Reprodução com Alibaba Cloud Web SDK: O WebRTC nativo não suporta B-frames e utiliza áudio Opus. O sistema aciona a transcodificação automaticamente com base no conteúdo ingerido:
- Se o stream contiver B-frames e áudio codificado em AAC, a transcodificação de vídeo remove os B-frames e a transcodificação de áudio converte AAC para Opus. Você será cobrado pelas taxas padrão de transcodificação de vídeo com base na resolução de origem.
- Caso o stream não contenha B-frames, mas utilize áudio AAC, a transcodificação de áudio converte AAC para Opus. A cobrança refere-se à transcodificação apenas de áudio.
- Se você também configurar um modelo de transcodificação ao vivo, a remoção de B-frames e a transcodificação para Opus serão aplicadas adicionalmente ao modelo. A cobrança incidirá sobre as operações combinadas de transcodificação.
Reprodução com Alibaba Cloud Native SDK: O SDK suporta nativamente B-frames e AAC, portanto nenhuma transcodificação automática é acionada e não há taxas adicionais.

Latência de meio segundo

Recursos: Latência de ponta a ponta de 200 a 400 ms. Ideal para cenários que exigem a menor latência possível.
Protocolos suportados: Apenas ARTC (baseado em WebRTC). Incompatível com transmissões ao vivo padrão: não suporta ingestão RTMP, origin pull ou reprodução RTMP/FLV/HLS.
Ferramentas de ingestão e reprodução: Para ingestão, use o OBS com o protocolo WHIP ou o SDK de Ingestão do Alibaba Cloud Live. Para reprodução, é obrigatório usar o SDK de Player do Alibaba Cloud.
Outras observações: O domínio de streaming não pode utilizar recursos de nuvem como transcodificação ou gravação. Utilize uma configuração de restreaming para enviar o stream a outro domínio de streaming e acessar esses recursos.
- Clique em Configure Stream Relay e selecione um domínio de ingestão para receber o stream RTMP retransmitido. O domínio deve estar associado a um domínio de streaming e ter os recursos de modo de latência ultrabaixa de meio segundo e recuperação de desastres de stream duplo desativados. Por exemplo, se push.example.com estiver associado a pull.example.com, você poderá puxar o stream de pull.example.com usando protocolos padrão e utilizar transcodificação e gravação.