Configuração do player de stream Splayer UDP para protocolo de stream do receptor COFDM Vcan1776-RX

Configuração do UDP Stream player no transmissor e receptor de vídeo sem fio COFDM HDMI

O reprodutor de fluxo UDP é a melhor solução para o codificador de vídeo analógico CVBS de menor latência. O firmware padrão do receptor de vídeo sem fio COFDM Vcan1776-RX suporta reprodutor RTSP. Alguns clientes precisam usar o protocolo UDP.

O endereço IP e o número da porta podem ser configurados na página da web, http://192.168.0.215 (padrão)

1. Depois de atualizar o firmware, a extremidade receptora restaurará os parâmetros padrão de fábrica (frequência central: 320MHz, banda larga sem fio: 6MHz, endereço IP da porta de rede: 192.168.0.215), os clientes precisam modificar a frequência central e a largura de banda através do Ferramenta da placa de configuração de parâmetros, e o transmissor salva consistentemente.

2. O cliente acessa o servidor web receptor através da página web (HTTP://192.168.0.215), e modifica seu próprio endereço IP e a configuração do endereço IP do PC Windows conectado ao receptor:

Nota: Entre eles, o IP local é o próprio IP do receptor, e o IP remoto é o IP final do PC com Windows de acoplamento. O cliente pode configurá-lo de acordo com sua situação real. Observe que a modificação só terá efeito após reiniciar o receptor.

Baixe o reprodutor UDP Jogador

3. Baixe o reprodutor UDP Jogador.
   • Splayer_v4.2_2020.6.6
   • https://drive.google.com/file/d/1ihzUhfnx2Wo3zLO8UAs1aUQeLswonJD-/view?usp=sharing
   • Splayer_v4.3_2022.10.22
   • https://drive.google.com/file/d/1PQc-LZ55qGnjeMsjkHYSloHfY3NEUsGH/view?usp=drive_link
   • Splayer_v4.3.1_2024.4.16
   • https://drive.google.com/file/d/1uv7GqP8P4r6qGOWJ5gYn0b8bZ4ptL8H6/view?usp=drive_link
   • Splayer_QT_V1.0 para Win10 ou Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Splayer_QT_V1.1.1 para Win10 ou Win11
   • https://drive.google.com/file/d/1YMr2xxurGnbIBjFihc7f77afrdbOcc6l/view?usp=drive_link
   • Splayer_QT_V2.0
   • https://drive.google.com/file/d/1sASbARCL1lXAIsVKqkmEObRGPREbaSES/view?usp=drive_link
4. Abra o player Splayer no PC com Windows, clique no botão de configuração no canto inferior direito, e a página de configuração aparecerá:

Nota:

1. Pode-se ver que o número da porta da porta está definido como 1234, que é codificado pelo programa de streaming UDP do receptor e não pode ser modificado;
2. Na coluna Decodificar, configurar de acordo com as propriedades atuais do stream de vídeo, como a configuração de fluxo de vídeo de baixa latência H264 acima;

4. Depois de configurar e clicar no “Confirmar” botão para salvar os parâmetros, clique no botão play no canto inferior esquerdo. Depois que o PC com Windows receber o fluxo push UDP, ele irá decodificar e reproduzir imediatamente.

A configuração do reprodutor de stream UDP acima é adequada para o modelo abaixo.

Como ele suporta o player Linux VLC? Reproduzindo fluxo de baixo atraso no Linux?

Questão: Agora o fluxo UDP não funciona com o player VLC. Preciso reproduzir esse stream UDP no Linux e tento entender os detalhes desse stream. Qualquer script ou chaves ou outras coisas?

Quero fazer meu próprio player no Linux e quero entender os detalhes desse stream de vídeo UDP do demodulador.

Se for um fluxo de vídeo UDP normal, então questione por que ele não funciona com o estúdio VLC ou OBS.

Responda: Para o modelo Vcan1726-RX, Temos dois firmware para opcional, O primeiro firmware para o player RTSP suporta o player VLC, mas alguns clientes mencionaram que tem uma longa latência, então fizemos o segundo firmware, Transmissão UDP no Splayer, que suporta menor latência.

Este fluxo de áudio e vídeo UDP é nosso formato personalizado, então o VLC não consegue explicar. Se o seu cliente quiser abrir seu próprio player (no Linux), atualmente existem duas opções:

1. Atualize para o acesso de fluxo RTSP padrão (primeiro firmware para reprodutor RTSP)
2. Fornecemos a biblioteca e rotinas DEMUX correspondentes (precisamos entender o ambiente Linux do cliente para compilar um arquivo de biblioteca adequado)
3. Isto é o “Biblioteca e rotinas DEMUX” escrito por nossos engenheiros no Ubuntu 14.04 64sistema de bits

O segundo tipo é muito difícil para clientes comuns, e não conhecemos as capacidades de desenvolvimento do player do seu cliente.

Porque alguns clientes enfrentam o problema de baixa latência no player VLC do sistema operacional Windows, não importa como testamos aqui, não encontramos esse problema. Naquela hora, você usou o Windows para testar. Talvez se fosse mudado para Linux, não haveria problema de streaming RTSP. Por favor, tente testar a amostra Vcan1726 com a primeira versão do firmware no Linux. Talvez isso não seja um problema no sistema operacional Linux.

Questão: Você pode construir uma imagem docker para este aplicativo? Qual porta é usada para o fluxo de entrada, e outra porta para o fluxo de saída com algum codec amplamente utilizado (h264)?

O que são Splayer e UDP Stream Player?

SPlayer é um reprodutor de mídia que suporta vários formatos de vídeo, incluindo streaming UDP.

O streaming UDP é um método de envio de dados de vídeo pela Internet usando o User Datagram Protocol (UDP), que é um protocolo rápido e simples que não garante a entrega ou a ordem dos pacotes.

O streaming UDP pode ser usado para transmissão de vídeo ao vivo ou transmissão de vídeo de baixa latência, mas também pode sofrer perda ou corrupção de pacotes.

De acordo com os resultados da pesquisa na web, SPlayer pode reproduzir streams UDP usando as seguintes etapas:

• Abra o SPlayer e clique no botão “Abrir URL” botão no canto superior direito.
• Insira a URL do fluxo UDP no formato udp://@ip: porta, onde ip é o endereço IP do servidor e port é o número da porta do stream. Por exemplo, UDP://@224.0.0.1:1234.
• Clique no “Está bem” botão e espere o stream carregar.

Como o Splayer funciona bem para Win10?

Questão: Não podemos iniciar o Splayer 4.2 e 4.3 no Windows 10. Você poderia nos fornecer a versão correta do Splayer para Windows 10 e 11?

4.2 começa e fecha no momento. 4.3 começa com a mensagem de erro.

Nome do aplicativo com falha: Splayer.exe, versão: 1.0.0.1, carimbo de data/hora: 0x646d83e2
Nome do módulo com falha: dvb_demux.dll, versão: 1.0.0.1, carimbo de data/hora: 0x5fe5bdbf
Código de exceção: 0xc0000005
Compensação de falha: 0x0001484a
ID do processo com falha: 0x3888
Falha na hora de início do aplicativo: 0x01da1164b89c78eb
Falha no caminho do aplicativo: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\Splayer.exe
Caminho do módulo com falha: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\dvb_demux.dll
ID do relatório: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Nome completo do pacote com falha:
ID do aplicativo relativo ao pacote com falha:

Responda: Por favor, tente usar nosso Splayer_qt_v1.0.zip (103.5Mb).

Comentários: A nova versão do SPlayer funciona bem no local do problema com o Win 10! Obrigado!

Questão: Descobrimos que o atraso de tempo aumentava durante a reprodução do vídeo do programa Reciver by Splayer (Fluxo UDP).

Se falar em detalhes – O receptor se conecta com um cabo Ethernet diretamente ao PC. O PC e o receptor estão na mesma rede local. Quando iniciamos o Splayer o atraso é normal e a contagem precisa nos mostra 330 mseg, que é um pouco mais do que um da saída HDMI onde observamos cerca de 270 mseg. Isso é bom. Mas se esperarmos alguns minutos sem quaisquer alterações no local de trabalho, observamos um aumento contínuo no atraso de tempo que atinge 1-1,5 sec que não é aceitável na aplicação do cliente.
Ontem eu mesmo testei no Win 10, e Win11 em PCs diferentes com desligamento complexo Win Brandmauer com Splayer qt (última versão sua), e Splayer 4.3 (versão antiga). Repito esse problema sempre em qualquer configuração.
Por favor me ajude a resolver esse problema. Precisamos de um atraso constante no tempo de jogo do Splayer, que não pode ser superior a 350 mseg.

Responda: Tal problema não deveria ocorrer, porque o player não tem cache no modo de baixa latência, e o atraso depende completamente da capacidade de decodificação do PC. Engenheiros irão configurar o ambiente e testá-lo na próxima segunda-feira.

Outro ponto é pedir aos clientes que verifiquem a configuração da taxa de atualização do monitor do seu laptop. Por exemplo, se a câmera inserir 1080p60, então a taxa de atualização do monitor do laptop do cliente também deve ser de 60 Hz. De outra forma, a exibição será muito lenta, o que também causará congestionamento de dados e introduzirá atrasos.

O jogador Slayer tem um grande atraso, ou a decodificação é lenta ou a exibição é lenta, tudo é causado pelo PC.

Codificação de câmera HDMI Decodificação de receptor HDMI, saída para o display, e teste de atraso de reprodução do computador do player Splayer

Não encontramos o problema que você mencionou.

Pode-se ver que a tela atual do player Splayer e a saída HDMI do receptor são consistentes, e o atraso entre eles é muito baixo.

Você poderia perguntar ao cliente, qual é a resolução e taxa de quadros da entrada da câmera? Supondo que a câmera do cliente seja 1080p60, você também pode executar as duas etapas a seguir para solucionar o problema:

1. Deixe o cliente mudar a câmera para uma taxa de quadros mais baixa para teste, como 1080p50/30;
2. Você pode definir os parâmetros do segmento de codificação para permitir a codificação down-frame. Por exemplo, envie o comando ATSO0,30_ através da porta de parâmetro, e a codificação produz 1080p30 para teste.

Nota:

1. O Splayer foi desenvolvido especificamente para nosso protocolo de streaming proprietário/personalizado e atualmente não suporta análise ou reprodução de protocolos MPEG-TS padrão.
2. Atualmente, o Splayer está disponível apenas no Windows. As versões Linux e Android ainda não foram desenvolvidas e não são suportadas neste estágio.
3. além do que, além do mais, não é o protocolo mpeg-ts que faz com que o atraso aumente. Mesmo se for mudado para nosso protocolo personalizado, o atraso não será reduzido (nosso protocolo personalizado realiza principalmente verificações CRC em todos os pacotes de dados, enquanto o protocolo mpeg-ts não, qual é a maior diferença entre os protocolos). O maior impacto na latência é o processamento de decodificação de vídeo e exibição no player. Nosso próprio player Splayer será otimizado para cenários de aplicação de transmissão de imagens.
4. Mesmo que o cliente obtenha nossa biblioteca demux e extraia os streams de áudio e vídeo, ele ainda precisa fazer a decodificação do vídeo e exibi-lo sozinho. Este cliente comum não tem essa capacidade. A maioria dos clientes usará apenas players de código aberto (como baseado em gstreamer), e o atraso de vídeo desses players de código aberto não será bom. Se você quiser um bom atraso de vídeo, você basicamente tem que desenvolver seu próprio player.
5. Se o cliente insistir na biblioteca demux e disser que tem a capacidade de lidar com a decodificação e reprodução de vídeo subsequente, Eu também posso cooperar com você (mas fornecemos apenas a biblioteca e rotinas demux no Linux/Android, e não fornecem decodificação subsequente e suporte relacionado à exibição)
6. Nosso protocolo personalizado aprimora principalmente a verificação CRC para lidar melhor com erros de transmissão, o que ajuda a evitar problemas inesperados de decodificação de vídeo ou até travamentos do player causados ​​por pacotes de dados corrompidos. O protocolo de desmultiplicação em si não introduz latência significativa, seja nosso protocolo personalizado ou o protocolo MPEG-TS padrão. Os principais fatores que afetam a latência são, na verdade, os estágios de decodificação e renderização posteriores. Em geral:
   • Como o streaming UDP e a decodificação/renderização do player são processos assíncronos, a maioria dos players introduz uma certa quantidade de buffer antes de iniciar a reprodução. Quanto maior o buffer, quanto maior a latência.
     Por exemplo, O reprodutor de mídia VLC normalmente usa buffer relativamente grande, e o tamanho do buffer pode até aumentar dinamicamente durante a reprodução. Em contraste, O Splayer mantém o buffer de reprodução intencionalmente muito pequeno para minimizar a latência.
   • A decodificação de vídeo e a renderização de quadros também são processos assíncronos. Se a renderização não conseguir acompanhar o tempo, quadros de vídeo decodificados podem se acumular na fila de renderização, que introduz latência adicional semelhante ao buffer de pré-decodificação. O Splayer também é otimizado nesta área para reduzir o acúmulo de quadros e manter a reprodução de baixa latência.
7. Nosso protocolo personalizado também inclui diversas otimizações adicionais, é por isso que decidimos adotá-lo em vez de continuar com o protocolo padrão MPEG-TS (que usamos originalmente no início):
   • Comparado com o protocolo MPEG-TS padrão, nosso protocolo personalizado reduz a sobrecarga de protocolo redundante e melhora a utilização da largura de banda sem fio. Isto é particularmente importante para links sem fio com largura de banda restrita, como sistemas de transmissão de vídeo COFDM..
   • Nosso protocolo personalizado oferece maior flexibilidade para multiplexar diferentes tipos de dados. Além de vídeo e áudio, ele pode encapsular convenientemente dados de porta serial e outros fluxos de dados definidos pelo usuário, tornando-o mais flexível e fácil de estender do que o MPEG-TS padrão.
   • Nosso protocolo personalizado suporta criptografia e descriptografia AES integradas diretamente na camada de protocolo. Isto é especialmente útil para links sem fio que não suportam criptografia AES nativamente., como conexões Wi-Fi padrão.
   • além do que, além do mais, nosso protocolo personalizado foi projetado especificamente para cenários de transmissão de baixa latência e alta confiabilidade, permitindo uma otimização mais rigorosa em todo o pipeline de transmissão e reprodução em comparação com um protocolo padrão de uso geral.

Relativo

1. Você deseja obter os dados UART da placa codificadora HDMI CVBS Video UART DATA?
2. SDK do player UDP de baixa latência para Windows x64

Q: O sistema suporta multicast? Posso enviar um fluxo para vários IPs??

UMA: sim. O sistema suporta multicast UDP, permitindo que um fluxo seja entregue a vários receptores simultaneamente sem duplicar o fluxo por IP.Para usar multicast, colocou oIP remoto no lado do remetente para um endereço multicast, por exemplo224.0.0.23. Todos os receptores ingressam no mesmo grupo multicast usando o mesmo endereço. Do lado do receptor, configurar o mesmo IP multicast:

• Jogador: definir IP do grupo como224.0.0.23
• VLC: abrirudp://@224.0.0.23:8090

Multicast permite streaming um-para-muitos na mesma rede. O IP real do dispositivo não é crítico; em vez de, a entrega depende do suporte multicast da rede e dos dispositivos que ingressam no mesmo grupo.Nota: As condições da rede podem afetar o desempenho. Ambientes com VPNs, máquinas virtuais, vários adaptadores de rede, ou switches sem suporte IGMP podem afetar a recepção multicast.

Multicast

Unicast

Q: Se houver várias placas multicast do codificador na mesma rede, devemos mudar a porta em cada placa para evitar conflito?

UMA: Não necessariamente. Existem duas maneiras válidas de garantir que vários fluxos de codificadores não entrem em conflito na mesma rede:

1. Use diferentes endereços IP multicast UDP para cada fluxo do codificador.
2. Use números de porta UDP diferentes para cada fluxo do codificador.

O streaming UDP se distingue pela combinação de endereço de IP (unicast ou multicast) e número da porta. Juntos, eles definem uma identidade de fluxo UDP exclusiva na rede.

Na placa do codificador, a Configurações de fluxo UDP incluir:

• IP remoto: Define o endereço IP de destino (se um endereço multicast for usado, o fluxo se torna um fluxo multicast UDP).
• Porto Tx: Define o número da porta de transmissão.

A combinação de IP remoto + Porto Tx determina um fluxo UDP exclusivo.

Para evitar conflitos quando múltiplas placas multicast do codificador são implantadas na mesma rede, você pode atribuir diferentes endereços IP multicast, diferentes portas UDP, ou use ambos dependendo dos requisitos de design da rede.

Q: Como obtenho endereços IP multicast para meu sistema?

UMA: Endereços IP multicast não são atribuídos automaticamente; eles são selecionados na faixa multicast padrão 224.0.0.0 para 239.255.255.255. Na prática, esses endereços devem ser planejados e alocados pelo administrador da rede para garantir que não haja conflitos com serviços ou dispositivos multicast existentes na rede.

Q: A placa codificadora precisa produzir vídeo através de interfaces HDMI e AV, mas ambos os fluxos usam o mesmo endereço UDP. Como podemos jogar ou alternar entre eles?

UMA: Quando os fluxos HDMI e AV são transmitidos pelo mesmo endereço UDP, eles são normalmente não separados por portas de rede, mas por identificadores de fluxo interno, semelhante a um MPEG-TS (Transport Stream) estrutura.

Como funciona

• As entradas HDMI e AV são multiplexado em um único fluxo UDP
• Cada fonte de vídeo recebe um ID de fluxo exclusivo (por exemplo., PID / ID do serviço)
• O receptor realiza demultiplexação com base nesses IDs, em vez de separar por IP ou porta
• Isso permite que vários canais de vídeo coexistam em um fluxo UDP

Como o Splayer lida com isso

Com nosso Jogador 2.0 Leitor UDP, o sistema suporta esta arquitetura nativamente:

• Decodificação simultânea de vários fluxos de vídeo de um único endereço UDP
• Separação de fluxo baseada em IDs internos (Mapeamento MPEG-TS PID/serviço)
• Troca em tempo real entre fontes HDMI e AV sem alterar as configurações de rede
• Reprodução multicanal flexível usando uma única fonte de entrada UDP

Esse design simplifica a implantação, mantendo uma configuração UDP, enquanto ainda habilita manipulação de vídeo com múltiplas entradas e comutação contínua.

Você pode baixar Jogador 2.0 Leitor UDP Aqui: Jogador 2.0 Baixar reprodutor UDP