Bonjour j'aimerait savoir si les pertent du protocole udp sont forte ??

J'aimerait savoir s'il es possible de faire passer de la vidéo de haute qualité !! , lors du passage je présume que ça devrait , effacer une certaine quantité , de pixel , mais je pense que à 25 frame/s , ça pourrait le faire nan ??

ps: Simple question , d’intérêt , me sauter pas dessus , pour me tuer

Salut,

En UDP, les pertes ne sont pas contrôlées, mais ça ne veut pas dire qu'il y en ait forcément...

Une petite question: Pourquoi veut tu faire passer de la vidéo en UDP ?! Ça me semble compliquer en mettre en oeuvre, autant utiliser TCP ...

En tout cas, ta question n'a pas grand chose à voir avec le Python, tu devrais aller la poser sur un site spécialisé....

En faite il me semble que l"udp soit plus rapide que le tcp à l'envoit ainsi que à la reception , d'ailleur c pour cela que l'ont fait passer les jeux 3d en réseaux en udp , bien sur aussi contrairement au tcp , l'udp peut générer de grosse perte , qui sont récupérer dans les jeux par le nombre de frame , alors que le passage d'un page hml est faite en tcp , pour permetre l'affichage , d'un page correct

Je maitrise pas trop tous se qui touche aux réseaux, mais à mon avis les perte en UDP ne doivent pas être fixe, je veux dire par là que un coup sa peut passer un autre tu peux perdre 30% de tes données.

A la limite tu peux faire une moyenne en faisant plusieurs test et encore je serais pas étonné quand faisant plusieurs fois ce test de moyenne tu arrive à avoir des résultat différent.

Car si les perte UDP était calculable je pense que quelqu'un aurait déjà cherché à contrôler ces pertes pour profité de la rapidité de l'UDP.

D'ailleurs si l'UDP est rapide cela doit surement être du au fait qu'il n'y est pas de contrôle à l'envoi réception contrairement au TCP.
Je pense par contre qu'il serait intéressant de faire des test.

Tes vidéos se sera en streaming ou juste du DL ?

Streaming , Ouais justement je sais que la non vérification des paquets reçut est justement le problème qui fat que l'ont n'a des pertes , mais je pense que les pertes de l'udp serait calculable , ensuite tout dépend de la connections de l'utilisateur , ainsi que sont utilisation , vue que la vidéo est souvent dans les 14 frames , sur le web , faire passer un vidéo en hd , 24 frames , pourrait alors devenir aussi rapide Que de balancer 14 frames en bas débit , ensuite la qualité viendra du fait de la connections , soit ceux qui auront une assez bonne connections aurons une excellente image eh de même pour ceux qui en auront une mauvaise , seulement que la qualité sera réduite , mais normalement ce sur quoi mise les jeux vidéo est que le nombre de frames fera en sorte à ce que tout les animations jouer au sein du jeu le mouvement de chaque perso reste fluide vue le grand nombre de rafraîchissement !!

Je comprend pas pourquoi tu veux faire passer une vidéo en streaming dans un jeu ? Après, si tu as une bonne raison de le faire, je pense que l'UDP n'est pas une bonne idée. Il est possible par exemple que les données n'arrivent pas dans le bon ordre ou qu'elles n'arrivent pas du tout et tu ne peux pas prédire quelles donnée arrivera, arrivera pas... Alors qu'en TCP, tu n'a pas à vérifier l'intégrité des données, le protocole le fait pour toi.

L'intégrité des données est assurée en UDP, en tout cas assurée d'être non corrompues.

Par contre ce n'est pas fiable en ce qui concerne l'arrivée des paquets (qui puis est pas forcément dans l'ordre d'envoi des paquets), mais ça peut être résolu avec le protocole RTP

Cependant il faut admettre que l'UDP pourrait être utilisé dans les applications audio/vidéo car on peut tolérer des pertes pour une transmission en temps réel.

Ça doit pouvoir se faire sans doute avec le module socket et sa constante socket.SOCK_DGRAM

Tu as un exemple de client et server sur cette page

RTMPy à l'air de faire ce que tu veux.

Cool , je me disait aussi , donc mes prévisions était bonne !!

Alors il faut comprendre plusieurs chose par rapport à ce que j'ai pu lire dans ce sujet. TCP est un protocole qui fait bien plus de chose que juste envoyer avec "certitude" des données.

Si vous passez très rapidement sur la page wikidepia de tcp : http://fr.wikipedia.org/wiki/Tcp

Vous pourrez voir sur le schéma que l'en-tête TCP est grande, la raison de cette taille est qu'elle gère beaucoup de chose. Entre autre la confirmation de réception (acquittement), le controle de congestion en cas de ligne saturé, la temporisation en cas de perte d'un packet, le controle de flux pour ne pas surchargé le recepteur, etc.

Bref, tous ces controles représente des algorithmes, des envoies et renvoie de données à des seul fin de contrôle, et donc du temps (le prix à payer pour s'assurer que toutes les données arrivent).

L'UDP, quant à lui ne s'occupe que de vérifier la somme de controle, et comme on peut le voir dans le schéma de sa trame, l'en-tête est bien plus courte que pour le TCP.

http://fr.wikipedia.org/wiki/User_Datagram_Protocol

En gros, exit tous les beaux algorithmes du TCP pour garantir l'arrivé des données, le controle de congestion etc. Il n'y a même pas de connexion avec l'UDP (contrairement au TCP).

Après, pour calculé les pertes, rien de bien compliqué, il suffit d'implémenter sois-même, un niveau au dessus un algo permettant de garantir la réception des paquets et de rajouter le calcul des pertes dedans (ce ne sera qu'une approximation bien sûr).

Et pour répondre à NuDub, les pertes sur un réseau dépendent directement de la qualité de ce réseau et de son taux d'utilisation au moment de l'envoie. Les mêmes données envoyées deux fois auront donc une très faible probabilité d'avoir le même taux de perte.

Merci dalshim de nous apporter , t lumières !!
A présent je sais sur quoi je vais me baser