Comment envoyer MPEGTS flux UDP
Je suis l'élaboration d'une vidéo en temps réel-système de streaming qui est composé essentiellement par un serveur et plusieurs clients.
Pour l'instant, nous allons ignorer la façon dont les paquets sont transmis entre le serveur et les clients, concentrons-nous seulement sur comment le serveur peut envoyer un MPEGTS diffuser sur les paquets UDP.
Le flux de données est codé dans MPEGTS format.
Ce que je suis en train de faire est de la lecture de certains paquets (la principale question est "combien?") et les encapsulant dans des paquets UDP. La destination (un client) lit ces paquets UDP et puis les transmet à VLC, qui est capable de jouer MPEGTS flux réseau par la lecture des paquets UDP.
Si j'envoie la vidéo uniquement les paquets, tout fonctionne bien, au lieu de cela, si j'essaie de les encapsuler dans le même paquet UDP, tant certains paquets vidéo et quelques paquets audio, VLC n'est pas capable de décoder et lire le contenu.
J'ai lu quelque part que chaque paquet UDP doit contenir 7 TS les paquets, mais malheureusement, même si je respecte cette règle, VLC ne pas décoder le flux de données correctement.
Voici un exemple de code de mon programme: http://pastebin.com/evMi6FkY
Comment dois-je encapsuler MPEGTS paquets dans des paquets UDP?
Merci!
@ dans l'url, même si l'url n'a pas de nom d'utilisateur/mot de passe. Cela dit, que pas plus de 8 188 octets ts les paquets de tenir dans un paquet udp, vous ne pouvez pas inclure plus. (moins n'est pas un problème). Et un paquet udp doit commencer avec le début de la ts paquet, c'est à dire le premier octet doit être 0x47. Utiliser wireshark pour vérifier les données.Avez-vous résolu votre problème? J'ai fait une vidéo en streaming avec dvblast, envoyer des paquets UDP, et les recevoir avec ffmpeg. Même définir des tailles de paquets UDP à 1316; Mais j'obtiens l'erreur: "PES taille de paquet" incompatibilité régulièrement et de sortie vidéo est terrible.
OriginalL'auteur pAkY88 | 2012-05-23
Vous devez vous connecter pour publier un commentaire.
Votre problème est le suivant: "nous allons ignorer la façon dont les paquets sont transmis entre le serveur et les clients".
UDP vous oblige à faire face à tous les problèmes de réseau de transport, y compris le contrôle du flux, de la détection et de la récupération, chemin de transmission maximum de la taille de l'unité, packetization, de mise en mémoire tampon, la sérialisation, la duplication, etc.
Même si vous cassez vos données dans les paquets de la taille et de les envoyer au bon taux, certains vont encore être perdus, dupliqués, ou délivré de la commande. Votre code doit gérer l'ensemble de ces conditions, vous ne pourrez pas la confiance que ce que vous recevez ce que vous avez envoyé.
Dans ce cas particulier, je suppose que vos paquets sont devenues trop grandes, ce qui entraîne une fragmentation et à haut taux d'abandon. De manière générale, il est préférable de ne pas avoir plus de 1400 octets par paquet. Mais le mauvais ordre, de la perte, et la duplication de tous les possibles et tous sont plus susceptibles que vous essayez d'envoyer de grandes quantités de données.
Disclaimer: je travaille pour une société qui produit commercial UDP transport de données du logiciel.
Les paquets peuvent être perdus sur l'ordinateur local s'ils sont envoyés trop vite, trop gros, si un pare-feu local est en cours d'exécution, ou si l'OS se sent juste comme elle. UDP est jamais fiable, sauf si vous les rendre fiables. Pour l'encapsulation, vous aurez besoin d'un en-tête d'au moins identifier le séquencement des paquets de sorte que vous pouvez tampon et re-commande et/ou de détecter la perte. Garder la taille vers le bas pour pas plus de 1408 octets, y compris votre en-tête. Si les différents paquets peuvent contenir différentes combinaisons de données, puis ajouter une description à votre en-tête. Ne prenez rien pour acquis.
-1, votre réponse s'applique à général transfert de l'udp. Mais cette question est à propos MPEG-TS. MPEG-TS est utilisé dans des situations où la communication est unidirectionnelle et retransmet ne sont pas possibles tels que les satellites de communication ou de multidiffusion udp. La perte de paquets est pas une grosse affaire ici. Il y a une simple somme de contrôle dans un TS paquet de détecter les erreurs. Ensuite, il nous suffit de jeter données et re-sync.
Alors, que faites-vous suggérer au lieu de UDP pour le transfert de vidéo?! Si RTP, je fais de la vidéo en temps réel-streaming Android, donc il n'y a pas de RTP Joueur (j'ai pas encore trouvé).
Il y a 3 large choix de transport vidéo: écrivez votre propre TCP, écrire votre propre UDP, ou l'utilisation d'une trousse d'outils comme RTP (qui généralement s'appuie sur UDP). Mais la capture et la lecture sont des questions distinctes de transport, si vous êtes à la construction à partir de zéro. Propriétaire de boîtes à outils (comme QuickTime ou WMP) ont tendance à combiner tous les trois et essayez de vous forcer à utiliser leur logiciel de bout en bout. Même si elles peuvent utiliser le protocole RTP, ils ne fournissent pas d'Api pour obtenir en elle. Approche la plus simple: trouver un bout-à-bout, vous pouvez vivre avec / se permettre.
OriginalL'auteur Seth Noble
Vous pouvez essayer https://github.com/KwikFlixTV/kwik-udp-send
Il utilise ts ou FIFO des fichiers et envoyer débit constant de flux.
Liste des caractéristiques importantes:
L'envoi de fichier ts(s) en tant que ts udp flux
Si il n'y a pas de fichiers à envoyer, il envoie null paquets
Fonctionne en temps réel les processus/threads priorités afin de garantir la stabilité des flux de
Fonctionne avec FIFO fichiers
Lecture de fichiers vers un tampon de cache avec une accumulation de la partie pour assurer la stabilité du flux
OriginalL'auteur pashamesh