FAQ¶
Respostas às perguntas que surgem com mais frequência durante a operação: a compatibilidade do SRT com software de terceiros e a recepção de multicast em taxas de bits elevadas.
SRT: autorização por login e senha em software de terceiros¶
Entre dois nós Perfect Streamer, a autorização SRT é configurada de forma nativa, pelos campos da entrada e da saída (SRT). O funcionamento com outros softwares não é garantido: o parâmetro stream ID não é padronizado e cada software o implementa de maneira diferente.
O mecanismo de compatibilidade é o mesmo: o lado receptor toma o stream ID do cliente que se conecta e busca por ele uma conta na lista de logins locais (Usuário: adicionar e alterar). O que deve coincidir é o campo «Usuário» — integralmente com o valor do stream ID. Por exemplo, com a URL
srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890
no campo «Usuário» é inserido
!#::u=1234567890,password=1234567890
A sintaxe do stream ID não tem importância para o Perfect Streamer: a cadeia não é decomposta em partes, e sim comparada integralmente. A exceção são três caracteres que o próprio nó interpreta:
|— separador: a parte da cadeia anterior ao primeiro caractere desse tipo é considerada o login, e o restante, a senha da conta;*— o stream ID não está definido; o cliente é autorizado por endereço, ou seja, por uma conta com o indicador «Conta por endereço IP»;@no início da cadeia é reservado para a autorização de serviço entre os nós de um domínio Meshwork.
O Perfect Streamer não limita o comprimento do stream ID — a limitação vem da biblioteca SRT e é de 512 bytes, incluindo o zero final. Não convém transmitir valores com mais de cerca de 500 caracteres: uma cadeia longa demais ou interrompe a conexão, ou é enviada vazia, sem nenhuma mensagem de erro.
Cada software gera o stream ID à sua maneira; por isso, se a recepção pela URL não funcionar, habilite na saída SRT a configuração avançada Trace. No registro do fluxo que aceita a conexão aparecerão o endereço do cliente, o stream ID recebido e o motivo da recusa — essa linha mostra o que a outra parte enviou de fato. Em seguida o stream ID pode ser corrigido: por exemplo, removendo do início da cadeia os caracteres supérfluos que impedem a transmissão do valor.
Recomendações para o trabalho com multicast UDP¶
Objetivo. Receber de forma estável multicast UDP com uma taxa de bits total de várias centenas de Mbps (1 Gbps ou mais) em um único servidor.
Problema. Na recepção em placas de rede com interface RJ-45, à medida que o tráfego ultrapassa algumas centenas de megabits, começam perdas crescentes de pacotes de multicast. O ajuste fino da placa não ajuda — as versões atuais dos sistemas operacionais já utilizam os valores ótimos. As placas baseadas em chips melhores também não eliminam o problema, sobretudo acima de 500 Mbps. O bonding de duas placas tampouco ajuda: um mesmo grupo multicast chega sempre a um único canal físico e a uma única fila de recepção, de modo que se agrega a banda total, e não a margem de um fluxo individual.
Solução. Pela experiência de operação, para a recepção e a transmissão de multicast UDP devem ser usadas placas de rede de 10 gigabits com interface SFP+. Basta uma placa econômica do nível da Intel X520-DA1/2 (Intel 82599ES) — em nossos testes ela elimina as perdas de pacotes com tráfego de multicast acima de 1 Gbps. Além disso, a carga da CPU diminui de forma perceptível: o processamento das interrupções e das filas de recepção sai mais barato nessas placas.
Leve em conta no diagnóstico: o contador de erros de recepção recv-err nas estatísticas da entrada conta apenas os erros de leitura do socket e a perda de sincronismo no limite do pacote TS. As perdas causadas pelo estouro do buffer de recepção do kernel não chegam à aplicação e não entram nesse contador — elas são vistas com o comando netstat -su (linha RcvbufErrors) e pelos erros de continuidade no analisador de fluxo (Analisador).
Recomendações para a configuração da rede para multicast¶
A seção se refere às entradas de rede UDP / RTP e Pro-MPEG COP3/RTP+FEC (SMPTE 2022-1/2). Esses parâmetros não afetam a recepção SRT: a biblioteca SRT define ela mesma o tamanho do buffer, e a latência e a margem para retransmissão são configuradas na própria entrada (SRT).
O tamanho do buffer de recepção do socket é definido pela configuração avançada da entrada Socket buffer (bytes). Por padrão ela é igual a zero — o nó não solicita nada e o socket recebe o tamanho de buffer definido no sistema pelo parâmetro net.core.rmem_default. O valor informado é uma solicitação, não um resultado. Assim que ele é definido explicitamente, passa a valer o limite superior net.core.rmem_max, e o kernel corta a solicitação até esse limite, informando sucesso em qualquer caso. Por isso o limite superior é elevado antes de definir o tamanho do buffer na entrada.
O nó mostra em dois lugares quanto buffer foi realmente concedido a uma entrada em funcionamento: nas estatísticas do fluxo, o bloco «Conexão de entrada» traz a linha «Buffer do socket (concedido)» (Estatísticas do fluxo), e no editor da entrada (Editor de entrada e saída) o tamanho concedido é exibido sob o próprio campo, com um aviso ao lado se a solicitação não coube sob o limite superior. Nos dois lugares é mostrado o volume útil que coube ao socket, e não o que está digitado no campo: sob o campo — em bytes, para comparar diretamente com ele; nas estatísticas — arredondado. A ausência da linha significa que não há socket: a entrada está parada. Nunca significa um buffer igual a zero.
O valor nas estatísticas é atualizado junto com os demais indicadores, ao passo que sob o campo ele é lido uma única vez, ao abrir a janela do fluxo. Por isso, depois de salvar um novo tamanho, a linha sob o campo desaparece: salvar reabre o socket, e o número anterior já não se refere a ele. Para ver o que foi concedido ao novo socket, fecha-se e abre-se novamente a janela do fluxo — ou consultam-se as estatísticas, onde o valor é ao vivo.
Os parâmetros são definidos em um arquivo separado em /etc/sysctl.d/:
cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF
Aplicar:
sudo sysctl --system
O valor rmem_max é apenas um limite superior; não se reserva memória por ele. O valor rmem_default se aplica a todos os sockets UDP do sistema; se esse tamanho global for indesejável, deixe-o inalterado e defina Socket buffer (bytes) apenas nas entradas que realmente precisem dele. O zero e um número indicado explicitamente não são equivalentes nem mesmo com a mesma grandeza: o kernel duplica o tamanho solicitado, ao passo que toma o tamanho padrão como está, e em ambos os casos metade do que é concedido vai para a contabilidade interna dos pacotes. Por isso, em um sistema com o mesmo rmem_default, uma entrada com um número indicado explicitamente recebe o dobro de espaço útil de uma entrada com zero.
Como referência para o cálculo, use a taxa de bits do fluxo multiplicada pela pausa admissível no atendimento do socket. Por exemplo, 8 MB cobrem cerca de 64 ms a 1 Gbps. A referência define o volume útil, ou seja, o número do campo da entrada; o limite superior net.core.rmem_max deve então ser o dobro do maior desses números. O par de valores recomendado acima cumpre essa condição.
SRT: recepção em software de terceiros com stream ID próprio¶
Exemplo de URL SRT para recepção em um software de terceiros que, ao trabalhar com SRT, transmite o próprio stream ID:
srt://Stream_IP:port?streamid=client1
Aqui, client1 é o login da conta na aba «Acessos locais» (Usuário: adicionar e alterar). Ao adicionar a conta, basta indicar apenas o login. Se esse software transmitir o próprio stream ID e o login não estiver indicado na URL, o fluxo não é recebido: o Perfect Streamer não encontra a conta e não entrega o fluxo.
Da mesma forma, o stream ID é definido no formato de login e senha: o campo «Usuário» da conta é igual a !#::u=1234567890,password=1234567890, e no software de terceiros é informada a URL:
srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890
O stream ID também pode ser definido no formato de endereço IP; para isso, na conta é ativado o indicador «Conta por endereço IP» e no campo de endereço é inserido:
192.168.1.1— um IP único;192.168.1.1-192.168.1.254— uma faixa de IP.
Em ambos os casos, a URL para recepção por IP no software de terceiros tem este formato: srt://Stream_IP:port?streamid=*
O fluxo fica vinculado ao endereço IP do cliente: a recepção por essa URL é possível somente a partir do endereço IP indicado (ou da faixa indicada).
