--- title: FAQ url: https://doc2.pstreamer.tv/pt/manual/faq/index.html lang: pt-BR product: Perfect Streamer version: 2.0.2.362 --- # 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](../planning/index.md#planning-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 é comum: 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](../webui/configure.md#webui-user-editor)). 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. As exceções são três — os 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 forma 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](../streamer/analyzer.md#streamer-analyzer)). ## Recomendações para a configuração da rede para multicast A seção se refere às entradas de rede UDP / RTP e Pro-MPEG. 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](../planning/index.md#planning-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. Quanto buffer foi realmente concedido, o nó mostra numa entrada em funcionamento em dois lugares: nas estatísticas do fluxo, o bloco «Conexão de entrada» traz a linha «Buffer do socket (concedido)» ([Estatísticas do fluxo](../webui/streams.md#webui-stream-stats)), e no editor da entrada ([Editor de entrada e saída](../webui/streams.md#webui-stream-io)) 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/`: ```bash cat > /etc/sysctl.d/99-pss-net.conf <