Paramètres du lecteur de flux Splayer UDP pour le protocole de flux du récepteur COFDM Vcan1776-RX

Paramétrage du lecteur UDP Stream sur l'émetteur et le récepteur vidéo sans fil HDMI COFDM

Le lecteur de flux UDP est la meilleure solution pour l'encodeur vidéo analogique CVBS à la latence la plus faible. Le micrologiciel par défaut du récepteur vidéo sans fil COFDM Vcan1776-RX prend en charge le lecteur RTSP. Certains clients doivent utiliser le protocole UDP.

L'adresse IP et le numéro de port peuvent être configurés sur la page Web, http://192.168.0.215 (défaut)

1. Après la mise à jour du firmware, l'extrémité de réception restaurera les paramètres d'usine par défaut (fréquence centrale: 320MHz, bande passante sans fil: 6MHz, adresse IP du port réseau: 192.168.0.215), les clients doivent modifier la fréquence centrale et la bande passante via le Outil de carte de configuration des paramètres, et l'émetteur enregistre constamment.

2. Le client accède au serveur Web du récepteur via la page Web (HTTP://192.168.0.215), et modifie sa propre adresse IP et le réglage de l'adresse IP du PC Windows connecté au récepteur:

Remarque: Parmi eux, l'adresse IP locale est la propre adresse IP du destinataire, et l'adresse IP distante est l'adresse IP de fin du PC Windows d'accueil. Le client peut le configurer en fonction de sa situation réelle. Notez que la modification ne prendra effet qu'après redémarrage du récepteur.

Télécharger le lecteur UDP Pulvérisateur

3. Télécharger le lecteur UDP Pulvérisateur.
   • Pulvérisateur_v4.2_2020.6.6
   • https://drive.google.com/file/d/1ihzUhfnx2Wo3zLO8UAs1aUQeLswonJD-/view?usp=sharing
   • Pulvérisateur_v4.3_2022.10.22
   • https://drive.google.com/file/d/1PQc-LZ55qGnjeMsjkHYSloHfY3NEUsGH/view?usp=drive_link
   • Joueur_v4.3.1_2024.4.16
   • https://drive.google.com/file/d/1uv7GqP8P4r6qGOWJ5gYn0b8bZ4ptL8H6/view?usp=drive_link
   • Splayer_QT_V1.0 pour Win10 ou Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Splayer_QT_V1.1.1 pour 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. Ouvrez le lecteur Sprayer sur le PC Windows, cliquez sur le bouton de réglage dans le coin inférieur droit, et la page de configuration apparaîtra:

Remarque:

1. On peut voir que le numéro de port du port est défini sur 1234, qui est codé en dur par le programme de streaming UDP du récepteur et ne peut pas être modifié;
2. Dans la colonne Décoder, configurer en fonction des propriétés actuelles du flux vidéo, comme la configuration de flux vidéo à faible latence H264 comme ci-dessus;

4. Après avoir défini et cliqué sur le “Confirmer” bouton pour enregistrer les paramètres, cliquez sur le bouton de lecture dans le coin inférieur gauche. Une fois que le PC Windows a reçu le flux push UDP, il va décoder et jouer immédiatement.

Le paramètre de lecteur de flux UDP ci-dessus convient au modèle ci-dessous.

Comment prend-il en charge le lecteur Linux VLC? Lecture d'un flux à faible délai sous Linux?

Question: Désormais, le flux UDP ne joue plus avec le lecteur VLC. J'ai besoin de lire ce flux UDP sous Linux et j'essaie de comprendre les détails de ce flux. Tout script, clé ou autre chose?

Je souhaite créer mon propre lecteur sous Linux et je souhaite comprendre les détails de ce flux vidéo UDP issu du démodulateur.

S'il s'agit d'un flux vidéo UDP standard, alors demandez-vous pourquoi il ne joue pas avec VLC ou OBS studio.

Répondre: Pour le modèle Vcan1726-RX, Nous avons deux firmware en option, Le premier firmware du lecteur RTSP prend en charge le lecteur VLC, mais certains clients ont mentionné une longue latence, nous avons donc réalisé le deuxième firmware, Diffusion UDP sur le Splayer, qui prend en charge une latence plus faible.

Ce flux audio et vidéo UDP est notre format personnalisé, donc VLC ne peut pas l'expliquer. Si votre client souhaite ouvrir son propre lecteur (sous Linux), il y a actuellement deux options:

1. Mise à jour de l'accès au flux RTSP par défaut (premier firmware pour lecteur RTSP)
2. Nous fournissons la bibliothèque et les routines DEMUX correspondantes (nous devons comprendre l'environnement Linux du client afin de compiler un fichier de bibliothèque approprié)
3. C'est le “Bibliothèque et routines DEMUX” écrit par nos ingénieurs sous Ubuntu 14.04 64système de bits

Le deuxième type est trop difficile pour les clients ordinaires, et nous ne connaissons pas les capacités de développement du propre lecteur de votre client.

Parce que certains clients rencontrent le problème de faible latence sur le lecteur VLC du système d'exploitation Windows, peu importe comment nous avons testé ici, nous n'avons pas trouvé ce problème. À ce moment-là, vous avez utilisé Windows pour tester. Peut-être que s'il était remplacé par Linux, il n'y aurait pas de problème de streaming RTSP. Veuillez essayer de tester l'exemple Vcan1726 avec la première version du firmware sous Linux. Ce n'est peut-être pas un problème sous Linux.

Question: Pouvez-vous créer une image Docker pour cette application? Quel port est utilisé pour le flux entrant, et un autre port pour le flux sortant avec un codec largement utilisé (h264)?

Que sont Splayer et UDP Stream Player?

SPlayer est un lecteur multimédia prenant en charge différents formats vidéo, y compris le streaming UDP.

Le streaming UDP est une méthode d'envoi de données vidéo sur Internet à l'aide du protocole de datagramme utilisateur. (UDP), qui est un protocole simple et rapide qui ne garantit ni la livraison ni la commande des paquets.

Le streaming UDP peut être utilisé pour la diffusion vidéo en direct ou la transmission vidéo à faible latence, mais il peut également souffrir de perte ou de corruption de paquets.

D'après les résultats de la recherche sur le Web, SPlayer peut lire des flux UDP en suivant les étapes suivantes:

• Ouvrez SPlayer et cliquez sur le “Ouvrir le lien” bouton dans le coin supérieur droit.
• Saisissez l'URL du flux UDP au format udp://@ip: Port, où ip est l'adresse IP du serveur et port est le numéro de port du flux. Par exemple, UDP://@224.0.0.1:1234.
• Clique sur le “D'accord” bouton et attendez que le flux se charge.

Comment le Splayer fonctionne-t-il bien pour Win10?

Question: Nous ne pouvons pas démarrer Splayer 4.2 et 4.3 sous Windows 10. Pourriez-vous nous fournir la bonne version de Splayer pour Windows 10 et 11?

4.2 démarre et ferme en ce moment. 4.3 commence par le message d'erreur.

Nom de l'application défaillante: Splayer.exe, version: 1.0.0.1, horodatage: 0x646d83e2
Nom du module défaillant: dvb_demux.dll, version: 1.0.0.1, horodatage: 0x5fe5bdbf
Code d'exception: 0xc0000005
Compensation de défaut: 0x0001484a
ID du processus défaillant: 0x3888
Heure de démarrage de l'application défaillante: 0x01da1164b89c78eb
Chemin d'application défaillant: C:\UtilisateursadminTéléchargementsSplayer_v4.3_2022.10.22Splayer.exe
Chemin du module défaillant: C:\UtilisateursadminTéléchargementsSplayer_v4.3_2022.10.22dvb_demux.dll
Identifiant du rapport: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Nom complet du package défaillant:
ID d'application relatif au package défaillant:

Répondre: Veuillez essayer d'utiliser notre Spalayer_qt_v1.0.zip (103.5Mb).

Retour d'information: La nouvelle version de SPlayer fonctionne bien sur le site problématique avec Win 10! Merci!

Question: Nous avons constaté que le délai augmentait lors de la lecture de la vidéo du programme Reciver by Splayer (Flux UDP).

Si je parle en détail – Le récepteur se connecte avec un câble Ethernet directement au PC. Le PC et le récepteur sont dans le même réseau local. Lorsque nous démarrons le Splayer, le délai est normal et le décompte précis nous le montre 330 msec, ce qui est un peu plus d'un de la sortie HDMI où nous avons observé environ 270 msec. C'est bon. Mais si nous attendons quelques minutes sans aucun changement sur le lieu de travail, nous observons une augmentation continue du délai qui atteint 1-1,5 sec ce qui n'est pas acceptable dans l'application client.
Hier, je l'ai testé moi-même sur Win 10, et Win11 sur différents PC avec désactivation complexe Win Brandmauer avec Splayer qt (dernière version de toi), et Joueur 4.3 (ancienne version). Je répète ce problème à chaque fois dans n'importe quelle configuration.
S'il vous plaît, aidez-moi à résoudre ce problème. Nous avons besoin d'un délai constant entre le temps de jeu de Splayer et qui ne peut pas dépasser 350 msec.

Répondre: Un tel problème ne devrait pas se produire, car le lecteur n'a pas de cache en mode faible latence, et le délai dépend entièrement de la capacité de décodage du PC. Les ingénieurs configureront l'environnement et le testeront lundi prochain.

Un autre point est de demander aux clients de vérifier le réglage du taux de rafraîchissement de leur écran d'ordinateur portable.. Par exemple, si la caméra entre en 1080p60, alors le taux de rafraîchissement du moniteur d'ordinateur portable du client doit également être de 60 Hz. Autrement, l'affichage sera trop lent, ce qui entraînera également une congestion des données et introduira des retards.

Le joueur Slayer a un gros retard, soit le décodage est lent, soit l'affichage est lent, tout est causé par le PC.

Encodage de caméra HDMI Décodage de récepteur HDMI, sortie sur l'écran, et test de retard de lecture sur ordinateur du lecteur Splayer

Nous ne trouvons pas le problème que vous avez mentionné.

On peut voir que l'écran actuel du lecteur Splayer et la sortie HDMI du récepteur sont cohérents, et le délai entre eux est très faible.

Pourriez-vous s'il vous plaît demander au client, quelle est la résolution et la fréquence d'images de l'entrée de la caméra? En supposant que la caméra du client soit en 1080p60, vous pouvez également suivre les deux étapes suivantes pour résoudre davantage le problème:

1. Laissez le client changer la caméra pour une fréquence d'images inférieure à des fins de test, comme 1080p50/30;
2. Vous pouvez définir les paramètres du segment d'encodage pour le laisser encoder vers le bas.. Par exemple, envoyer la commande ATSO0,30_ via le port paramètre, et l'encodage produit 1080p30 pour les tests.

Remarque:

1. Splayer est spécifiquement développé pour notre protocole de streaming propriétaire/personnalisé et ne prend actuellement pas en charge l'analyse ou la lecture des protocoles MPEG-TS standard..
2. Splayer est actuellement disponible uniquement sur Windows. Les versions Linux et Android n'ont pas encore été développées et ne sont pas supportées à ce stade.
3. en outre, ce n'est pas le protocole mpeg-ts qui fait augmenter le délai. Même s'il est basculé sur notre protocole personnalisé, le délai ne sera pas réduit (notre protocole personnalisé effectue principalement des contrôles CRC sur tous les paquets de données, alors que le protocole mpeg-ts ne le fait pas, quelle est la plus grande différence entre les protocoles). Le plus grand impact sur la latence est le traitement du décodage vidéo et de l'affichage dans le lecteur.. Notre propre lecteur Splayer sera optimisé pour les scénarios d'application de transmission d'images.
4. Même si le client obtient notre bibliothèque de démultiplication et extrait les flux audio et vidéo, il doit encore faire le décodage et l'affichage vidéo par lui-même. Ce client ordinaire n'a pas cette capacité. La plupart des clients n'utiliseront que des lecteurs open source (comme basé sur gstreamer), et le délai vidéo de ces lecteurs open source ne sera pas bon. Si vous voulez un bon delay vidéo, vous devez essentiellement développer votre propre lecteur.
5. Si le client insiste sur la bibliothèque de démultiplexage et déclare qu'il a la possibilité de gérer le décodage et la lecture vidéo ultérieurs, Je peux aussi coopérer avec vous (mais nous fournissons uniquement la bibliothèque et les routines demux sous Linux/android, et ne fournissent pas de support ultérieur lié au décodage et à l'affichage)
6. Notre protocole personnalisé améliore principalement la vérification CRC pour mieux gérer les erreurs de transmission, ce qui permet d'éviter des problèmes de décodage vidéo inattendus ou même des pannes de lecteur causées par des paquets de données corrompus. Le protocole de démultiplexage lui-même n'introduit pas de latence significative, qu'il s'agisse de notre protocole personnalisé ou du protocole standard MPEG-TS. Les principaux facteurs affectant la latence sont en fait les étapes de décodage et de rendu qui suivent.. En général:
   • Étant donné que le streaming UDP et le décodage/rendu du lecteur sont des processus asynchrones, la plupart des lecteurs introduisent une certaine quantité de mise en mémoire tampon avant de commencer la lecture. Plus le tampon est grand, plus la latence est élevée.
     Par exemple, Le lecteur multimédia VLC utilise généralement une mémoire tampon relativement importante, et sa taille de tampon peut même augmenter dynamiquement pendant la lecture. En revanche, Splayer maintient intentionnellement le tampon de lecture très petit pour minimiser la latence.
   • Le décodage vidéo et le rendu des images sont également des processus asynchrones. Si le rendu ne peut pas suivre dans le temps, les images vidéo décodées peuvent s'accumuler dans la file d'attente de rendu, qui introduit une latence supplémentaire similaire à la mise en mémoire tampon de pré-décodage. Splayer est également optimisé dans ce domaine pour réduire l'accumulation d'images et maintenir une lecture à faible latence..
7. Notre protocole personnalisé comprend également plusieurs optimisations supplémentaires, c'est pourquoi nous avons finalement décidé de l'adopter au lieu de continuer avec le protocole standard MPEG-TS (que nous avons utilisé au début):
   • Par rapport au protocole standard MPEG-TS, notre protocole personnalisé réduit la surcharge du protocole redondant et améliore l'utilisation de la bande passante sans fil. Ceci est particulièrement important pour les liaisons sans fil à bande passante limitée telles que les systèmes de transmission vidéo COFDM..
   • Notre protocole personnalisé offre une plus grande flexibilité pour multiplexer différents types de données. En plus de la vidéo et de l'audio, il peut facilement encapsuler les données du port série et d'autres flux de données définis par l'utilisateur, le rendant plus flexible et plus facile à étendre que le MPEG-TS standard.
   • Notre protocole personnalisé prend en charge le cryptage et le déchiffrement AES intégrés directement au sein de la couche de protocole.. Ceci est particulièrement utile pour les liaisons sans fil qui ne prennent pas en charge le cryptage AES de manière native., telles que les connexions Wi-Fi standard.
   • en outre, notre protocole personnalisé est conçu spécifiquement pour les scénarios de transmission à faible latence et haute fiabilité, permettant une optimisation plus stricte sur l'ensemble du pipeline de transmission et de lecture par rapport à un protocole standard à usage général.

Relatif

1. Voulez-vous obtenir les données UART de la carte d'encodeur vidéo HDMI CVBS UART DATA?
2. SDK du lecteur UDP à faible latence pour Windows x64

Q: Le système prend-il en charge la multidiffusion? Puis-je diffuser un flux vers plusieurs adresses IP?

UNE: Oui. Le système prend en charge la multidiffusion UDP, permettant à un flux d'être transmis simultanément à plusieurs récepteurs sans dupliquer le flux par IP.Pour utiliser la multidiffusion, met leIP distante du côté de l'expéditeur vers une adresse multicast, par exemple224.0.0.23. Tous les récepteurs rejoignent le même groupe de multidiffusion en utilisant la même adresse. Du côté du récepteur, configurer la même IP multicast:

• Pulvérisateur: définir l'adresse IP du groupe sur224.0.0.23
• VLC: ouvrirudp://@224.0.0.23:8090

La multidiffusion permet le streaming un à plusieurs au sein du même réseau. L'adresse IP réelle de l'appareil n'est pas critique; Au lieu, la livraison dépend de la prise en charge de la multidiffusion réseau et des appareils rejoignant le même groupe.Remarque: Les conditions du réseau peuvent affecter les performances. Environnements avec VPN, machines virtuelles, plusieurs cartes réseau, ou les commutateurs sans prise en charge IGMP peuvent avoir un impact sur la réception multicast.

Multidiffusion

Monodiffusion

Q: S'il y a plusieurs cartes multicast d'encodeur dans le même réseau, devrions-nous changer le port sur chaque carte pour éviter les conflits?

UNE: Pas nécessairement. Il existe deux manières valables de garantir que plusieurs flux d'encodeurs n'entrent pas en conflit sur le même réseau.:

1. Utiliser différentes adresses IP de multidiffusion UDP pour chaque flux d'encodeur.
2. Utiliser différents numéros de port UDP pour chaque flux d'encodeur.

Le streaming UDP se distingue par la combinaison de adresse IP (monodiffusion ou multidiffusion) et numéro de port. Ensemble, ils définissent une identité de flux UDP unique sur le réseau.

Sur la carte encodeur, la Paramètres du flux UDP comprendre:

• IP distante: Définit l'adresse IP de destination (si une adresse multicast est utilisée, le flux devient un flux multicast UDP).
• Port d'émission: Définit le numéro du port de transmission.

La combinaison de IP distante + Port d'émission détermine un flux UDP unique.

Pour éviter les conflits lorsque plusieurs cartes de multidiffusion d'encodeurs sont déployées dans le même réseau, vous pouvez soit attribuer différentes adresses IP multicast, différents ports UDP, ou utilisez les deux en fonction des exigences de conception du réseau.

Q: Comment puis-je obtenir des adresses IP multicast pour mon système?

UNE: Les adresses IP de multidiffusion ne sont pas automatiquement attribuées; ils sont sélectionnés dans la gamme multicast standard 224.0.0.0 à 239.255.255.255. En pratique, ces adresses doivent être planifiées et attribuées par l'administrateur réseau pour garantir qu'il n'y a pas de conflits avec les services ou appareils de multidiffusion existants sur le réseau.

Q: The encoder board needs to output video over both HDMI and AV interfaces, but both streams use the same UDP address. How can we play or switch between them?

UNE: When HDMI and AV streams are transmitted over the same UDP address, they are typically not separated by network ports, mais par internal stream identifiers, similar to an MPEG-TS (Transport Stream) structure.

Comment ça marche

• Both HDMI and AV inputs are multiplexed into a single UDP stream
• Each video source is assigned a unique stream ID (par ex., PID / service ID)
• The receiver performs demultiplexing based on these IDs, rather than separating by IP or port
• This allows multiple video channels to coexist in one UDP stream

How Splayer handles this

Avec notre Pulvérisateur 2.0 Lecteur UDP, the system supports this architecture natively:

• Simultaneous decoding of multiple video streams from a single UDP address
• Stream separation based on internal IDs (MPEG-TS PID/service mapping)
• Real-time switching between HDMI and AV sources without changing network settings
• Flexible multi-channel playback using a single UDP input source

This design simplifies deployment by keeping one UDP configuration, while still enabling multi-input video handling and seamless switching.

You can download Pulvérisateur 2.0 Lecteur UDP ici: Pulvérisateur 2.0 UDP Player Download