Precisamos de dispositivos, para receber informações sobre vídeos de câmeras Full HD com SDI (Interface de dados seriais) na linha e codificar informações no padrão H.265. Os dados comprimidos devem ser transmitidos em DVB-T (Transmissão de vídeo digital terrestre) ou padrão DVB-S. A saída analógica do módulo projetado pode aceitar sinais I e Q, bem como sinais modulados.
Índice
Q: O seu codificador de vídeo SDI suporta entrada TSI? / Saída?
UMA: Nossa placa de codificação existente para placa de modulação transmite dados através da porta de rede. Em vez da interface TSI que você mencionou. Isso não afeta o uso do transmissor para o receptor. Esta é uma interface interna do transmissor.
Q: As placas decodificadoras do seu codificador suportam 525 i50 para 1080 P60 no formato de vídeo?
UMA: Agora nossas placas codificadoras de vídeo SDI suportam HD: 720p @ 23,98 Hz/24 Hz/25 Hz/29,97 Hz/30 Hz/ 50 Hz, 59,94 Hz/60 Hz e 1080p @ 23,98 Hz/24 Hz/25 Hz/29,97 Hz/30 Hz/50 Hz/59,94 Hz/60 Hz. Não suporta 525 formato de vídeo i50, está tudo bem?
Q: A potência de saída do seu codificador SDI COFDM DVB-T H265 SDI RF suporta 0 ~ 10dBm？
UMA: Seu ponto de frequência de saída de 400Mhz a 2800Mhz necessário é muito amplo.
É difícil alcançar uma saída de 0~10dBm sob um ponto de frequência tão amplo, e adicionar um amplificador de potência na placa aumentará o consumo de energia e o calor (você também mencionou que não há necessidade de ventilador para dissipação de calor).
Você está disposto a concordar com nossos atuais -3 para saída de -10dBm e então adicione seu próprio PA (amplificador de potência)?
Q: Qual é a dimensão do seu codificador COFDM DVB-T H265 SDI?
Você tem um pedido de dimensão especial? Nosso tamanho existente é 70x45mm.
UMA: Nossas placas codificadoras e decodificadoras de vídeo existentes podem atender às necessidades do seu projeto.
A maior preocupação do meu engenheiro é que sua empresa, como membro da indústria de transmissão e televisão, tem requisitos relativamente altos de qualidade de imagem e vídeo.
Nossa placa de codificação de vídeo realizará compactação com perdas para baixa latência. Você pode pegar um conjunto de amostras existentes para testar e confirmar a qualidade da imagem? Se você acha que nossas amostras podem atender aos requisitos da sua empresa, redesenharemos e desenharemos o quadro de acordo com as necessidades da sua empresa.
Q: Você poderia fornecer mais informações sobre VBR?
Aplicando vídeo ao TX, o parâmetro VBR mudará com o tempo e não é um valor estático. Você poderia fornecer mais informações sobre isso?
UMA: VBR é a taxa de bits de codificação de vídeo no transmissor. Como a imagem do vídeo muda dinamicamente, VBR é obviamente variável, mas flutua em torno da taxa de bits de codificação definida pelo sistema de transmissão: 7.81*0.8= 6,248 Mbps.
Q: Apesar de ter armazenamento flash no meu receptor, REC OFF e No Storage são exibidos na tela. Por que isso está acontecendo?
Você disse na descrição: key2: Botão de alternância para gravação de vídeo, Pressione curta para mudar seu status. O receptor verificará automaticamente o dispositivo de armazenamento (cartão micro SD ou disco USB, Cartão SD Priority) depois de ligar e começar a gravar o vídeo quando o dispositivo de armazenamento for inserido. Basta pressionar o botão para parar ou gravar novamente.
UMA: O sistema receptor não consegue detectar a unidade flash USB. A unidade flash USB precisa ser formatada em um formato que nosso sistema possa reconhecer.
Q: Ambos B1 e B2 são zero. Isto indica que existe uma 0 % Taxa de erro de mordida!!! Qual intervalo desses parâmetros é aceitável?
UMA: A ocorrência de uma taxa de erro de bit pode causar problemas na imagem do vídeo. Quando a taxa de erro de bit é muito pequena, isso não afetará o efeito da imagem de vídeo.
Q: Posso personalizar o conteúdo da tela do programador?
UMA: O conteúdo de exibição do painel de configuração (programador) não está aberto aos clientes para modificação.
Q: Por que o canal S2 não está programado? Parece que o segundo sintonizador não está funcionando no momento.
UMA: S2 refere-se à antena receptora 2, que pode funcionar normalmente. Frequência e largura de banda são iguais s1 e s2.
Q: Por que a latência que calculei é enorme? Está por aí 470 Senhora.
Na sua descrição chegando: Os recursos normais padrão do nosso módulo receptor podem ser emparelhados com nosso módulo transmissor H.265. A latência de vídeo HD desde a entrada do transmissor até a exibição na tela HDMI do receptor é de cerca de 200ms a 250ms.
UMA: O atraso que testamos foi em torno de 250ms. Como você testou? A forma de atraso que testamos, por favor verifique o Link do vídeo do Youtube.
Q: Quanta latência seu transmissor codificador SDI e módulo receptor decodificador tem?
Lembro que você disse que otimizou o protocolo para melhor latência. Como não uso sua latência rápida H.264 (130 Senhora) quanta latência devemos ter na minha configuração?
UMA: Você confirmou que precisava oferecer suporte ao H265, mas não o modo de baixa latência H264. Para alcançar o modo de baixa latência, o receptor deve ser alterado para outro hardware de receptor, e o firmware correspondente deve ser gravado antes do envio.
Q: Posso usar seu receptor COFDM para obter o canal de TV DVB-T normal?
Você disse que mudou o protocolo de vídeo para melhor latência no TX. Posso usar seu RX como um DVB-T comercial? como posso receber o canal DVB-T normal?
UMA: Se você realmente deseja usá-lo como um receptor DVB-T normal, temos que atualizar outro firmware. (remova a criptografia no codificador e a descriptografia no decodificador).
Q: Como posso usar a função do menu OSD no receptor COFDM?
Na sua descrição chegando:
O módulo receptor também inclui a funcionalidade de gravação DVR com um cartão Micro SD ou disco USB. O módulo receptor também permite streaming de vídeo via USB para decodificadores de dispositivos Android remotos, como smartphones ou Android PAD. Isso permite que vários visualizadores remotos monitorem o mesmo vídeo
simultaneamente. O módulo receptor também suporta caracteres de exibição na tela de exibição de vídeo com o vídeo junto no modo OSD.
UMA: Vejo Documentação on-line do OSD.
Q: Como posso ativar a criptografia AES? Onde devo inserir a chave?
UMA: O painel de configuração pode editar e alterar a senha.
Q: Indique a pergunta da imagem do texto do arco:
UMA: Esta função opcional é exigida por outros produtos (a função de porta de rede é usada para conectar-se a um link sem fio bidirecional). Por favor, ignore-o em sua aplicação.
Q: Qual é o atraso dos dados UART na transmissão unidirecional?
Para dados UART de TX para RX, são os dados processados por meio do processo de codificação ou transmitidos em tempo real? Preciso de transferência de dados em tempo real.
UMA: Os dados e o vídeo são enviados juntos via pacote cofdm sem fio. Portanto, o atraso é o mesmo do vídeo.
Q: Para transmissor. É possível alterar GI e FEC e outro parâmetro conforme sua tabela na descrição?
UMA: sim.
Q: Qual é a potência exata neste ponto de 1350 para 1450 MHz? Preciso dessas informações para projetar um PA.
A saída máxima da banda de frequência 1350~1450 é em torno de -10±2dBm. Recomenda-se projetar o PA com base na entrada de -15dBm. Nosso transmissor pode ser ajustado até -15dBm.
Q: Seu programador tem a função de redefinir a restauração de fábrica?
Se eu alterar algum parâmetro de qualquer lado, como frequência GI ou FEC ou largura de banda de vídeo, como posso redefinir todos os parâmetros no modo de redefinição de fábrica? sou novo nesse fórum, e preciso alterar alguns parâmetros para alcançar meu desejo. Mas tenho medo de alterar as informações padrão.
UMA: Nosso TX / O programador RX não possui um recurso de redefinição de fábrica.
Q: O seu codificador de entrada de vídeo SDI suporta 1080i25/1080i30??
Suporta 1080i50 e 1080i60, não suporta 1080i25 ou 1080i30.
Q: Você pode me oferecer alguns arquivos técnicos para a reparação da parte de alimentação do Placa codificadora de vídeo Vcan1731 SDI?
UMA: Verifique os arquivos no link abaixo.
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-1.pdf
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-2.pdf
- https://ivcan.com/wp-content/uploads/vcan1731_A01_power.pdf
Nossa ideia de manutenção é primeiro descartar se há um curto-circuito e onde o curto-circuito está. Por exemplo, desconecte o cordão magnético ou resistor de 0 ohm entre o IC de potência e o circuito subsequente, e, em seguida, use um multímetro para medir se o IC de energia está quebrado ou se o circuito subsequente está em curto-circuito. Se o IC de alimentação estiver quebrado, substitua o IC de energia; se o circuito subsequente estiver em curto-circuito, você tem que verificar o circuito subsequente.
Q: A placa do codificador pode receber e encaminhar dados UART por meio de comunicação UDP? (IP:Porta)?
UMA: sim, A transmissão de dados UART é suportada sob nosso protocolo personalizado padrão, com algumas considerações importantes:
1. Protocolo personalizado (Firmware padrão)
Nosso firmware de envio padrão usa um protocolo multiplexado personalizado que suporta Transmissão transparente UART (passagem serial).
- Os dados UART são multiplexados junto com fluxos de áudio/vídeo.
- Assim sendo, o lado receptor deve usar o correspondente biblioteca demux de protocolo personalizado para separar dados UART do fluxo de mídia.
- Quando usado junto com nossa placa decodificadora, A transmissão transparente UART funciona corretamente e pode ser encaminhada/recebida conforme esperado.
Nota para jogadores de PC
Nosso atual software de player para PC apenas desmuxa e processa:
- Dados de vídeo
- Dados de áudio
Atualmente, isso acontece não processar ou gerar dados seriais UART.
2. Protocolo MPEG-TS padrão
Se a placa do codificador estiver piscando com o firmware/protocolo MPEG-TS padrão:
- Apenas fluxos de áudio e vídeo são suportados.
- A transmissão de dados UART/serial é não suportado no modo MPEG-TS.
Leve isso em consideração ao selecionar a solução de firmware/protocolo.
| Tipo de protocolo | Áudio / Vídeo | Transmissão Transparente UART |
|---|---|---|
| Protocolo personalizado (Padrão) | suportado | suportado |
| MPEG-TS padrão | suportado | Não suportado |
Q: Você tem firmware que suporta H.264 bruto ou RTP em vez de MPEG-TS para streaming UDP??
UMA: Nosso firmware UDP não transmite fluxos elementares H.264 brutos. O streaming UDP é suportado em dois formatos, dependendo da versão do firmware:
- UMA formato proprietário personalizado, ou
- o padrão MPEG-TS (Fluxo de transporte MPEG) formato
Eles correspondem a diferentes compilações de firmware (normalmente distinguido por um sufixo como versões “T” ou não “T”).
Q: Você oferece suporte ao RTP como um protocolo de streaming independente??
UMA: Não fornecemos um “modo de streaming RTP bruto” separado. No entanto, O RTP já é usado internamente no streaming RTSP. No modo RTSP, áudio e vídeo são transmitidos por pacotes RTP como parte da pilha RTSP/RTP/RTCP. Assim sendo, O RTP é suportado indiretamente através do RTSP, e não como um formato de streaming UDP independente..
Q: O sistema pode gerar H.264 bruto sobre UDP??
UMA: Não. A transmissão de fluxo elementar bruto H.264 não é suportada por UDP. Isso se deve ao tamanho do pacote e às restrições da rede. Um único quadro I pode ser muito grande e não pode ser transmitido de forma confiável em um único pacote IP.
Para transmissão estável, fluxos de vídeo devem ser encapsulados usando um formato de transporte como:
- MPEG-TS, ou
- RTP (via RTSP)
Q: Como é o quadro-chave (VAI P) intervalo configurado?
UMA: O intervalo do quadro-chave é controlado pelo Parâmetro GOP na interface web (página de configurações de vídeo).
- Se o GOP estiver definido como 0 (modo padrão/automático), o sistema alinha automaticamente o intervalo do quadro I com a taxa de quadros de entrada.
- Exemplo: Se a entrada for 1080p60, então o intervalo do quadro I será 60 quadros (1 segundo Partido Republicano).
Isso garante um comportamento de codificação adaptativo com base nas características da fonte de entrada.
Q: Por que o H.264 bruto não pode ser transmitido diretamente por IP/UDP?
UMA: Porque os quadros H.264 (especialmente quadros I) pode ser muito grande e exceder a unidade máxima de transmissão (Homem) de pacotes de rede. Sem encapsulamento, entrega confiável não pode ser garantida. Assim sendo, o vídeo deve ser empacotado usando formatos de streaming padronizados, como MPEG-TS ou RTP, para segmentação adequada, tempo, e remontagem.
Q: A latência do meu sistema é de aproximadamente 230 ms no total. O decodificador e a exibição levam aproximadamente 45 ms, deixando ~185 ms para câmera e codificador. Espero que a câmera contribua com ~60 ms (4 quadros em 60 fps), então o codificador parece ter ~120 ms. Existe uma maneira de reduzir a latência do codificador? Eu entendo que o MPEG-TS afeta principalmente a decodificação, não codificando.
UMA: Orientação sobre detalhamento e otimização de latência
Para otimizar com precisão a latência do sistema, é importante primeiro validar cada estágio de forma independente antes de assumir gargalos.
1. Verifique primeiro a latência da câmera (Etapa Crítica)
Antes de otimizar a codificação, você deve confirmar a contribuição real da câmera.
Um método de medição prático:
- Conecte a saída HDMI da câmera diretamente a um monitor
- Aponte a câmera para um cronômetro de alta precisão exibido em um monitor de PC separado
- Capture a cena ao vivo e a saída HDMI simultaneamente
- Compare os carimbos de data/hora dos quadros para calcular a latência completa da câmera
Notas:
- Use um cronômetro de alta precisão (intervalo de tick menor melhora a precisão)
- O processamento do ISP da câmera costuma ser um contribuidor importante
- Em nossa experiência:
- 1080câmeras p normalmente apresentam latência de aproximadamente 100 ms
- Alguns modelos podem exceder isso devido a pipelines de ISP mais pesados
2. A configuração da câmera tem um grande impacto
Se a latência da câmera for alta, a otimização deve começar aí:
- Resolução mais baixa (por exemplo., 720p versus 1080p) → reduz o atraso do ISP e do pipeline
- Maior taxa de quadros (por exemplo., 60 fps versus 30 fps) → reduz a latência do buffer de quadros
- Pipeline de processamento de imagem mais simples → reduz a carga do ISP
Essas alterações geralmente reduzem a latência de forma mais eficaz do que o ajuste do codificador.
3. A latência do codificador provavelmente está superestimada
UMA 120 O atraso de codificação ms geralmente é improvável para codificadores de hardware típicos.
Com base em medições internas:
- Um codificador de hardware + decodificador + transmissão + exibir pipeline pela Ethernet normalmente resulta em:
- ~80–100 ms de latência total de ponta a ponta
Isto implica:
- A latência somente do codificador é significativamente menor do que 120 Senhora
- A codificação geralmente não é o contribuidor dominante em um sistema configurado corretamente
4. O método de transmissão é importante (Especialmente sem fio)
Verifique se o sistema usa:
- Ethernet com fio
- Transmissão sem fio
Se sem fio for usado:
- Largura de banda baixa (<20 Mbps) pode introduzir atraso significativo
- A transmissão grande de quadros I pode causar atrasos no buffer e no enfileiramento
- Isso pode aumentar visivelmente a latência de ponta a ponta, mesmo se a codificação for eficiente
5. Esclarecimento de sobrecarga de protocolo e MPEG-TS
Seu entendimento geralmente está correto:
- MPEG-TS não adiciona latência significativamente na fase de codificação
- A maior parte da sobrecarga do protocolo está relacionada ao comportamento de empacotamento e decodificação, não se codificando
- As operações Mux/demux são principalmente operações de memória e têm atraso insignificante em sistemas típicos
6. Abordagem de depuração recomendada
Para localizar com precisão fontes de latência:
- Adicione carimbos de data/hora internos em cada estágio do pipeline:
- Tempo de captura da câmera
- Entrada/saída do codificador
- Envio/recebimento de rede
- Saída do decodificador
- Atualização de exibição
- Certifique-se de que o registro seja leve e não afete o desempenho
- Monitore a profundidade do buffer em tempo real para detectar o acúmulo de filas
Resumo nossa resposta
- O atraso do ISP da câmera costuma ser um grande contribuidor oculto (~100 ms em 1080p é comum)
- A latência do codificador geralmente é muito menor do que o suposto
- A transmissão e o buffer sem fio podem aumentar significativamente o atraso
- A medição sistemática do carimbo de data/hora é a maneira mais confiável de identificar o verdadeiro gargalo
Faça uma pergunta
Sua mensagem foi enviada