FMUSER Wirless transmet la vidéo et l'audio plus facilement!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikaans
sq.fmuser.org -> albanais
ar.fmuser.org -> arabe
hy.fmuser.org -> Armenian
az.fmuser.org -> azerbaïdjanais
eu.fmuser.org -> basque
be.fmuser.org -> biélorusse
bg.fmuser.org -> Bulgare
ca.fmuser.org -> catalan
zh-CN.fmuser.org -> chinois (simplifié)
zh-TW.fmuser.org -> Chinois (traditionnel)
hr.fmuser.org -> croate
cs.fmuser.org -> tchèque
da.fmuser.org -> danois
nl.fmuser.org -> Néerlandais
et.fmuser.org -> estonien
tl.fmuser.org -> Philippin
fi.fmuser.org -> finnois
fr.fmuser.org -> Français
gl.fmuser.org -> Galicien
ka.fmuser.org -> géorgien
de.fmuser.org -> allemand
el.fmuser.org -> Grec
ht.fmuser.org -> Créole haïtien
iw.fmuser.org -> hébreu
hi.fmuser.org -> Hindi
hu.fmuser.org -> Hongrois
is.fmuser.org -> islandais
id.fmuser.org -> indonésien
ga.fmuser.org -> irlandais
it.fmuser.org -> Italien
ja.fmuser.org -> japonais
ko.fmuser.org -> coréen
lv.fmuser.org -> letton
lt.fmuser.org -> Lituanien
mk.fmuser.org -> macédonien
ms.fmuser.org -> malais
mt.fmuser.org -> maltais
no.fmuser.org -> Norwegian
fa.fmuser.org -> persan
pl.fmuser.org -> polonais
pt.fmuser.org -> portugais
ro.fmuser.org -> Roumain
ru.fmuser.org -> russe
sr.fmuser.org -> serbe
sk.fmuser.org -> slovaque
sl.fmuser.org -> Slovène
es.fmuser.org -> espagnol
sw.fmuser.org -> Swahili
sv.fmuser.org -> suédois
th.fmuser.org -> Thai
tr.fmuser.org -> turc
uk.fmuser.org -> ukrainien
ur.fmuser.org -> ourdou
vi.fmuser.org -> Vietnamienne
cy.fmuser.org -> Gallois
yi.fmuser.org -> Yiddish
1. Introduction à RTP
RTP est un protocole de transmission en temps réel qui fournit un service de transmission de bout en bout, qui prend en charge la transmission de données en temps réel dans un service de réseau de diffusion à cible unique et de diffusion multi-objectifs, tandis que la transmission de données en temps réel est surveillée et contrôlée par le protocole RTCP.
2. RTP est défini dans RFC
L'application utilisant le protocole RTP s'exécute sur RTP, tandis que le programme exécutant RTP s'exécute sur la couche supérieure d'UDP, afin d'utiliser le numéro de port et le contrôle et d'UDP. RTP peut être considéré comme une sous-couche de la couche transport. Les blocs de données audio et TV générés par les applications multimédias sont encapsulés dans des paquets RTP, chaque paquet RTP est encapsulé dans un segment de message UDP, puis conditionné dans des paquets IP.
La structure du paquet comprend plusieurs domaines largement utilisés dans le multimédia, notamment l'audio à la demande, la vidéo à la demande, la téléphonie Internet et la visioconférence. La spécification RTP ne définit pas de normes pour les formats compressés pour le son et la télévision, et elle peut être utilisée pour transmettre des fichiers au format normal. Par exemple, le son au format wav ou GSM (Global System for mobile communications), MPEG-1 et MPEG-2 TV peuvent également être utilisés pour transmettre des fichiers audio et TV stockés dans des formats propriétaires.
Du point de vue des développeurs d'applications, les exécuteurs RTP peuvent être considérés comme faisant partie de l'application car les développeurs doivent intégrer RTP dans l'application. À la fin de l'envoi, les développeurs doivent écrire le programme exécutant le protocole RTP dans le programme d'application qui crée le package d'informations RTP, puis le programme d'application envoie le package d'informations RTP à l'interface socket d'UDP, comme illustré à la figure 2; De même, les paquets RTP sont entrés dans l'application via l'interface de socket UDP au niveau du récepteur. Par conséquent, les développeurs doivent écrire le programme exécutant le protocole RTP dans l'application qui extrait les données multimédias du paquet RTP.
Le document prend RTP comme exemple pour illustrer son processus de travail. Supposons que le son de la source sonore soit un son codé PCM de 64 kb / s, et supposons que l'application prend 20 ms de données codées sous forme de bloc, c'est-à-dire 160 octets de données audio dans un bloc de données. L'application doit ajouter un titre RTP à ces données audio pour générer des paquets RTP, qui incluent le type, le numéro de séquence et l'horodatage des données audio. Les paquets RTP sont ensuite envoyés à l'interface de socket UDP, où ils sont encapsulés dans les paquets UDP. Au niveau du récepteur, le programme d'application reçoit le paquet d'informations RTP de l'interface de socket, extrait le bloc de données audio du paquet d'informations RTP, puis décode et lit le son correctement en utilisant les informations du champ titre du paquet RTP.
Si l'application n'utilise pas de solutions propriétaires pour fournir le type de charge utile, le numéro de séquence ou l'horodatage, mais utilise le protocole RTP standard, l'application sera plus facile à exécuter avec d'autres applications réseau, ce que tout le monde espère. Par exemple, si deux sociétés différentes développent un logiciel de téléphonie Internet, elles intègrent toutes le RTP dans leurs produits, ce qui laisse espérer que les utilisateurs utilisant différents logiciels de téléphonie d'entreprise pourront communiquer.
Il est important de souligner que RTP ne fournit aucun mécanisme pour garantir que les données sont livrées au récepteur dans le temps ou d'une autre qualité de service. Il ne garantit pas que le paquet d'informations n'est pas perdu ou que l'ordre des paquets n'est pas perturbé. En effet, l'encapsulation RTP n'est visible que du côté système. Le routeur au milieu ne distingue pas que le datagramme IP transporte des paquets RTP.
RTP permet à chaque source multimédia de se voir attribuer un flux de paquets RTP distinct, tel qu'une caméra ou un microphone. Par exemple, une conférence télévisée avec deux groupes impliqués pourrait ouvrir quatre flux de paquets: deux caméras transmettant des flux TV et deux microphones pour transmettre des flux sonores. Cependant, de nombreuses technologies de codage populaires, y compris MPEG-1 et MPEG-2, lient les images audio et TV ensemble pour former un flux de données unique dans le processus de codage et génèrent un flux de paquets RTP dans une direction.
Les paquets RTP ne sont pas limités à la diffusion à une seule cible, et ils peuvent également être transmis sur une à plusieurs arborescences de diffusion multi-cibles ou multi-à-plusieurs arborescence de diffusion multi-cibles. Par exemple, une diffusion multi-cible avec plusieurs à plusieurs, dans cette application, tous les terminaux émetteurs envoient généralement leur flux de paquets RTP à l'arbre de diffusion multi-objectifs avec la même adresse de diffusion multi-objectifs.
3. Champ d'en-tête de paquet RTP
Le titre RTP se compose de quatre champs d'en-tête de paquet et d'autres domaines : domaine de type de charge utile, domaine de numéro de séquence, domaine d'horodatage et domaine d'identifiant de source de synchronisation.
1) type de charge utile
Le champ de type de charge utile dans le paquet RTP a une longueur de 7 bits, de sorte que RTP peut prendre en charge 128 types de charge utile différents. Pour le flux sonore, ce champ est utilisé pour indiquer le type de codage utilisé par le son, tel que PCM, modulation delta adaptative, codage prédictif linéaire, etc. Si l'expéditeur décide de changer la méthode de codage pendant la session ou la diffusion, l'expéditeur peut avertir le destinataire via ce domaine. Le tableau 1 répertorie les types de charges utiles sonores que RTP peut actuellement prendre en charge.
Pour les flux TV, les types de données utiles peuvent être utilisés pour indiquer le type de codage TV, tels que Motion JPEG, MPEG-1, MPEG-2, h.231, etc. L'expéditeur peut également modifier la méthode de codage du téléviseur à tout moment pendant la session ou pendant la session. Le tableau 16-02 répertorie certains types de charges utiles TV que RTP peut actuellement prendre en charge.
2) numéro de série
Le champ de champ de numéro de séquence a une longueur de 16 bits. Ajoutez 1 à chaque numéro de séquence de paquet RTP. Le récepteur peut l'utiliser pour vérifier si le paquet est manquant et traiter le paquet en fonction du numéro de séquence. Par exemple, l'application réceptrice reçoit un flux de paquets RTP, qui a un intervalle entre les numéros de séquence 86 et 89, et le récepteur sait que les paquets 87 et 88 ont été perdus et prend des mesures pour traiter les données perdues.
3) horodatage
Le domaine d'horodatage a une longueur de 32 octets. Il reflète le temps d'échantillonnage (temps) du premier octet du paquet RTP. Le récepteur peut utiliser cet horodatage pour supprimer la gigue des paquets provoquée par le réseau et fournir une fonction de synchronisation pour la lecture à l'extrémité de réception.
4) identifiant de source de synchronisation
La longueur du domaine de l'identificateur de source de synchronisation (SSRC) est de 32 bits. Il est utilisé pour identifier l'origine du flux de paquets RTP, et chaque flux de paquets pendant la session ou la période RTP a un SSRC clair. SSRC n'est pas l'adresse IP de l'expéditeur, mais un numéro attribué au hasard par la source au début du nouveau flux de paquets.
|
Entrez l'email pour avoir une surprise
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikaans
sq.fmuser.org -> albanais
ar.fmuser.org -> arabe
hy.fmuser.org -> Armenian
az.fmuser.org -> azerbaïdjanais
eu.fmuser.org -> basque
be.fmuser.org -> biélorusse
bg.fmuser.org -> Bulgare
ca.fmuser.org -> catalan
zh-CN.fmuser.org -> chinois (simplifié)
zh-TW.fmuser.org -> Chinois (traditionnel)
hr.fmuser.org -> croate
cs.fmuser.org -> tchèque
da.fmuser.org -> danois
nl.fmuser.org -> Néerlandais
et.fmuser.org -> estonien
tl.fmuser.org -> Philippin
fi.fmuser.org -> finnois
fr.fmuser.org -> Français
gl.fmuser.org -> Galicien
ka.fmuser.org -> géorgien
de.fmuser.org -> allemand
el.fmuser.org -> Grec
ht.fmuser.org -> Créole haïtien
iw.fmuser.org -> hébreu
hi.fmuser.org -> Hindi
hu.fmuser.org -> Hongrois
is.fmuser.org -> islandais
id.fmuser.org -> indonésien
ga.fmuser.org -> irlandais
it.fmuser.org -> Italien
ja.fmuser.org -> japonais
ko.fmuser.org -> coréen
lv.fmuser.org -> letton
lt.fmuser.org -> Lituanien
mk.fmuser.org -> macédonien
ms.fmuser.org -> malais
mt.fmuser.org -> maltais
no.fmuser.org -> Norwegian
fa.fmuser.org -> persan
pl.fmuser.org -> polonais
pt.fmuser.org -> portugais
ro.fmuser.org -> Roumain
ru.fmuser.org -> russe
sr.fmuser.org -> serbe
sk.fmuser.org -> slovaque
sl.fmuser.org -> Slovène
es.fmuser.org -> espagnol
sw.fmuser.org -> Swahili
sv.fmuser.org -> suédois
th.fmuser.org -> Thai
tr.fmuser.org -> turc
uk.fmuser.org -> ukrainien
ur.fmuser.org -> ourdou
vi.fmuser.org -> Vietnamienne
cy.fmuser.org -> Gallois
yi.fmuser.org -> Yiddish
FMUSER Wirless transmet la vidéo et l'audio plus facilement!
Contactez-Nous
Adresse :
No.305 Chambre HuiLan Building No.273 Huanpu Road Guangzhou Chine 510620
Catégories
Newsletter