4. Audio

Audio

4.1 Règles indépendantes du codage

Puisque la capacité de supprimer le silence est l'une des principales motivations de l'utilisation de paquets pour transmettre la voix, l'en-tête RTP transporte à la fois un numéro de séquence et un horodatage pour permettre à un récepteur de distinguer les paquets perdus des périodes de temps sans transmission de données. La transmission discontinue (suppression de silence) PEUT être utilisée avec n'importe quel format de charge utile audio. Les récepteurs DOIVENT supposer que les émetteurs peuvent supprimer le silence, à moins que cela ne soit restreint par une signalisation spécifiée ailleurs. (Même si l'émetteur ne supprime pas le silence, le récepteur devrait être prêt à gérer des périodes sans présence de données car des paquets peuvent être perdus.)

Certains formats de charge utile (voir les sections 4.5.3 et 4.5.6) définissent un "descripteur d'insertion de silence" ou une trame de "bruit de confort" pour spécifier les paramètres pour le bruit artificiel qui peut être généré pendant une période de silence pour se rapprocher du bruit de fond à la source. Pour d'autres formats de charge utile, un format de charge utile générique de bruit de confort (CN) est spécifié dans la RFC 3389 [9]. Lorsque le format de charge utile CN est utilisé avec un autre format de charge utile, différentes valeurs dans le champ de type de charge utile RTP distinguent les paquets de bruit de confort de ceux du format de charge utile sélectionné.

Pour les applications qui n'envoient pas de paquets ou qui envoient occasionnellement des paquets de bruit de confort pendant le silence, le premier paquet d'une salve de parole, c'est-à-dire le premier paquet après une période de silence pendant laquelle les paquets n'ont pas été transmis de manière continue, DEVRAIT être distingué en mettant le bit marqueur de l'en-tête de données RTP à un. Le bit marqueur dans tous les autres paquets est à zéro. Le début d'une salve de parole PEUT être utilisé pour ajuster le délai de lecture afin de refléter l'évolution des délais du réseau. Les applications sans suppression de silence DOIVENT mettre le bit marqueur à zéro.

La fréquence d'horloge RTP utilisée pour générer l'horodatage RTP est indépendante du nombre de canaux et du codage ; elle est généralement égale au nombre de périodes d'échantillonnage par seconde. Pour les codages à N canaux, chaque période d'échantillonnage (disons, 1/8 000 de seconde) génère N échantillons. (Cette terminologie est standard, mais quelque peu confuse, car le nombre total d'échantillons générés par seconde est alors le taux d'échantillonnage multiplié par le nombre de canaux.)

Si plusieurs canaux audio sont utilisés, les canaux sont numérotés de gauche à droite, en commençant par un. Dans les paquets audio RTP, les informations provenant des canaux numérotés inférieurs précèdent celles des canaux numérotés supérieurs.

Pour plus de deux canaux, la convention suivie par le format d'échange audio AIFF-C DEVRAIT être suivie [3], en utilisant la notation suivante, sauf si une autre convention est spécifiée pour un codage ou un format de charge utile particulier :

  l  gauche (left)
  r  droite (right)
  c  centre (center)
  S  surround
  F  avant (front)
  R  arrière (rear)

  canaux    description  canal
                            1     2   3   4   5   6
  _________________________________________________
  2         stéréo          l     r
  3                         l     r   c
  4                         l     c   r   S
  5                        Fl     Fr  Fc  Sl  Sr
  6                         l     lc  c   r   rc  S

     Note : La RFC 1890 définissait deux conventions pour l'ordre de quatre
     canaux audio. Comme l'ordre est indiqué implicitement par
     le nombre de canaux, c'était ambigu. Dans cette révision,
     l'ordre décrit comme "quadriphonique" a été éliminé pour
     supprimer l'ambiguïté. Ce choix était basé sur l'observation
     que le format audio grand public quadriphonique n'est pas devenu populaire
     alors que le son surround l'est devenu par la suite.

Les échantillons pour tous les canaux appartenant à un seul instant d'échantillonnage DOIVENT être dans le même paquet. L'entrelacement des échantillons de différents canaux dépend du codage. Des directives générales sont données aux sections 4.3 et 4.4.

La fréquence d'échantillonnage DEVRAIT être tirée de l'ensemble : 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100 et 48 000 Hz. (Les anciens ordinateurs Apple Macintosh avaient un taux d'échantillonnage natif de 22 254,54 Hz, qui peut être converti à 22 050 avec une qualité acceptable en supprimant 4 échantillons dans une trame de 20 ms.) Cependant, la plupart des codages audio sont définis pour un ensemble plus restreint de fréquences d'échantillonnage. Les récepteurs DEVRAIENT être prêts à accepter l'audio multicanal, mais PEUVENT choisir de ne lire qu'un seul canal.

4.2 Recommandations opérationnelles

Les recommandations suivantes sont des paramètres de fonctionnement par défaut. Les applications DEVRAIENT être prêtes à gérer d'autres valeurs. Les plages données sont destinées à donner des conseils aux auteurs d'applications, permettant à un ensemble d'applications conformes à ces directives d'interagir sans négociation supplémentaire. Ces directives ne sont pas destinées à restreindre les paramètres de fonctionnement pour les applications qui peuvent négocier un ensemble de paramètres interopérables, par exemple, via un protocole de contrôle de conférence.

Pour l'audio par paquets, l'intervalle de mise en paquets par défaut DEVRAIT avoir une durée de 20 ms ou une trame, selon la plus longue des deux, sauf indication contraire dans le tableau 1 (colonne "ms/paquet"). L'intervalle de mise en paquets détermine le délai de bout en bout minimum ; des paquets plus longs introduisent moins de surcharge d'en-tête mais un délai plus élevé et rendent la perte de paquets plus perceptible. Pour les applications non interactives telles que les conférences ou pour les liaisons avec de sévères contraintes de bande passante, un délai de mise en paquets plus élevé PEUT être utilisé. Un récepteur DEVRAIT accepter des paquets représentant entre 0 et 200 ms de données audio. (Pour les codages audio tramés, un récepteur DEVRAIT accepter des paquets avec un nombre de trames égal à 200 ms divisé par la durée de la trame, arrondi au supérieur.) Cette restriction permet un dimensionnement raisonnable de la mémoire tampon pour le récepteur.

4.3 Directives pour les codages audio basés sur des échantillons

Dans les codages basés sur des échantillons, chaque échantillon audio est représenté par un nombre fixe de bits. Dans les données audio compressées, les codes pour les échantillons individuels peuvent s'étendre sur les limites des octets. Un paquet audio RTP peut contenir n'importe quel nombre d'échantillons audio, sous réserve de la contrainte que le nombre de bits par échantillon multiplié par le nombre d'échantillons par paquet donne un nombre entier d'octets. Les codages fractionnaires produisent moins d'un octet par échantillon.

La durée d'un paquet audio est déterminée par le nombre d' échantillons dans le paquet.

Pour les codages basés sur des échantillons produisant un ou plusieurs octets par échantillon, les échantillons de différents canaux échantillonnés au même instant d'échantillonnage DEVRAIENT être emballés dans des octets consécutifs. Par exemple, pour un codage à deux canaux, la séquence d'octets est (canal gauche, premier échantillon), (canal droit, premier échantillon), (canal gauche, deuxième échantillon), (canal droit, deuxième échantillon), .... Pour les codages multi-octets, les octets DEVRAIENT être transmis dans l'ordre des octets du réseau (c'est-à-dire, l'octet le plus significatif en premier).

L'emballage des codages basés sur des échantillons produisant moins d'un octet par échantillon est spécifique au codage.

L'horodatage RTP reflète l'instant auquel le premier échantillon dans le paquet a été échantillonné, c'est-à-dire l'information la plus ancienne dans le paquet.

4.4 Directives pour les codages audio basés sur des trames

Les codages basés sur des trames codent un bloc audio de longueur fixe en un autre bloc de données compressées, généralement aussi de longueur fixe. Pour les codages basés sur des trames, l'émetteur PEUT choisir de combiner plusieurs telles trames en un seul paquet RTP. Le récepteur peut dire le nombre de trames contenues dans un paquet RTP, si toutes les trames ont la même longueur, en divisant la longueur de la charge utile RTP par la taille de la trame audio qui est définie comme partie intégrante du codage. Cela ne fonctionne pas lors du transport de trames de tailles différentes, sauf si les tailles de trame sont relativement premières. Sinon, les trames DOIVENT indiquer leur taille.

Pour les codecs basés sur des trames, l'ordre des canaux est défini pour l'ensemble du bloc. C'est-à-dire, pour l'audio à deux canaux, les échantillons droit et gauche DEVRAIENT être codés indépendamment, avec la trame codée pour le canal gauche précédant celle pour le canal droit.

Tous les codecs audio orientés trame DEVRAIENT être capables d'encoder et de décoder plusieurs trames consécutives dans un seul paquet. Comme la taille de trame pour les codecs orientés trame est donnée, il n'est pas nécessaire d'utiliser une désignation distincte pour le même codage, mais avec un nombre différent de trames par paquet.

Les paquets RTP DOIVENT contenir un nombre entier de trames, avec les trames insérées selon l'âge dans un paquet, de sorte que la trame la plus ancienne (à jouer en premier) apparaisse immédiatement après l'en-tête du paquet RTP. L'horodatage RTP reflète l'instant auquel le premier échantillon dans la première trame a été échantillonné, c'est-à-dire l'information la plus ancienne dans le paquet.

4.5 Codages audio

nom du fréquence défaut codage échantillon/trame bits/échantillon d'échantillonnage ms/trame ms/paquet

DVI4 échantillon 4 var. 20 G722 échantillon 8 16 000 20 G723 trame N/A 8 000 30 30 G726-40 échantillon 5 8 000 20 G726-32 échantillon 4 8 000 20 G726-24 échantillon 3 8 000 20 G726-16 échantillon 2 8 000 20 G728 trame N/A 8 000 2,5 20 G729 trame N/A 8 000 10 20 G729D trame N/A 8 000 10 20 G729E trame N/A 8 000 10 20 GSM trame N/A 8 000 20 20 GSM-EFR trame N/A 8 000 20 20 L8 échantillon 8 var. 20 L16 échantillon 16 var. 20 LPC trame N/A 8 000 20 20 MPA trame N/A var. var. PCMA échantillon 8 var. 20 PCMU échantillon 8 var. 20 QCELP trame N/A 8 000 20 20 VDVI échantillon var. var. 20

Tableau 1 : Propriétés des codages audio (N/A : non applicable ; var. : variable)

Les caractéristiques des codages audio décrits dans ce document sont présentées dans le Tableau 1 ; ils sont énumérés dans l'ordre de leur type de charge utile dans le Tableau 4. Alors que la plupart des codecs audio sont spécifiés uniquement pour une fréquence d'échantillonnage fixe, certains algorithmes basés sur des échantillons (indiqués par une entrée "var." dans la colonne de fréquence d'échantillonnage du Tableau 1) peuvent être utilisés avec différentes fréquences d'échantillonnage, entraînant différents débits binaires codés. Lorsqu'utilisé avec une fréquence d'échantillonnage autre que celle pour laquelle un type de charge utile statique est défini, des moyens non-RTP hors du cadre de ce mémo DOIVENT être utilisés pour définir un type de charge utile dynamique et DOIVENT indiquer la fréquence d'horloge d'horodatage RTP sélectionnée, qui est généralement la même que la fréquence d'échantillonnage pour l'audio.

4.5.1 DVI4

DVI4 utilise un schéma de codage par modulation par impulsion et codage différentiel adaptatif (ADPCM) qui a été spécifié par l'Interactive Multimedia Association (IMA) comme le "type d'onde ADPCM IMA". Cependant, le codage défini ici comme DVI4 diffère à trois égards de la spécification IMA :

o L'en-tête RTP DVI4 contient la valeur prédite plutôt que la première valeur d'échantillon contenue dans l'en-tête de bloc ADPCM IMA.

o Les blocs ADPCM IMA contiennent un nombre impair d'échantillons, car le premier échantillon d'un bloc est contenu uniquement dans l'en-tête (non compressé), suivi d'un nombre pair d'échantillons compressés. DVI4 a un nombre pair d'échantillons compressés uniquement, utilisant le mot `predict' de l'en-tête pour décoder le premier échantillon.

o Pour DVI4, les échantillons de 4 bits sont emballés avec le premier échantillon dans les quatre bits les plus significatifs et le deuxième échantillon dans les quatre bits les moins significatifs. Dans le codec ADPCM IMA, les échantillons sont emballés dans l'ordre inverse.

Chaque paquet contient un seul bloc DVI. Ce profil définit uniquement la version à 4 bits par échantillon, tandis que l'IMA a également spécifié un codage à 3 bits par échantillon.

Le mot "en-tête" pour chaque canal a la structure suivante :

  int16  predict;  /* valeur prédite du premier échantillon
                      du bloc précédent (format L16) */
  u_int8 index;    /* index actuel dans la table de taille de pas */
  u_int8 reserved; /* mis à zéro par l'émetteur, ignoré par le récepteur */

Chaque octet suivant l'en-tête contient deux échantillons de 4 bits, donc le nombre d'échantillons par paquet DOIT être pair car il n'y a aucun moyen indiquer un dernier octet partiellement rempli.

L'emballage des échantillons pour plusieurs canaux est à l'étude.

L'algorithme ADPCM IMA a été décrit dans le document IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0). Cependant, l'Interactive Multimedia Association a cessé ses activités en 1997. Les ressources pour une copie archivée de ce document et une implémentation logicielle du codage RTP DVI4 sont énumérées à la section 13.

4.5.2 G722

G722 est spécifié dans la Recommandation ITU-T G.722, "Codage audio à 7 kHz sous 64 kbit/s". L'encodeur G.722 produit un flux d'octets, dont chacun DOIT être aligné sur l'octet dans un paquet RTP. Le premier bit transmis dans l'octet G.722, qui est le bit le plus significatif de l'échantillon de sous-bande supérieure, DOIT correspondre au bit le plus significatif de l'octet dans le paquet RTP.

Même si le taux d'échantillonnage réel pour l'audio G.722 est de 16 000 Hz, la fréquence d'horloge RTP pour le format de charge utile G722 est de 8 000 Hz car cette valeur a été attribuée par erreur dans la RFC 1890 et doit rester inchangée pour la compatibilité descendante. Le taux d'octets ou taux de paires d'échantillons est de 8 000 Hz.

4.5.3 G723

G723 est spécifié dans la Recommandation ITU G.723.1, "Codage de parole à double débit pour les communications multimédia transmettant à 5,3 et 6,3 kbit/s". Le codec G.723.1 5,3/6,3 kbit/s a été défini par l'ITU-T comme un codec obligatoire pour les applications de terminal visiophonique ITU-T H.324 GSTN. L'algorithme a une spécification en virgule flottante dans l'Annexe B de G.723.1, un algorithme de compression de silence dans l'Annexe A de G.723.1 et un schéma de codage de canal évolutif pour les applications sans fil dans G.723.1 Annexe C.

Cette Recommandation spécifie une représentation codée qui peut être utilisée pour compresser la composante du signal vocal des services multimédia à un très faible débit binaire. L'audio est encodé en trames de 30 ms, avec un délai supplémentaire de 7,5 ms dû à l'anticipation (look-ahead). Une trame G.723.1 peut avoir l'une des trois tailles suivantes : 24 octets (trame 6,3 kb/s), 20 octets (trame 5,3 kb/s), ou 4 octets. Ces trames de 4 octets sont appelées trames SID (Descripteur d'Insertion de Silence) et sont utilisées pour spécifier les paramètres de bruit de confort. Il n'y a aucune restriction sur la manière dont les trames de 4, 20 et 24 octets sont mélangées. Les deux bits les moins significatifs du premier octet de la trame déterminent la taille de la trame et le type de codec :

     bits  contenu                      octets/trame
  parole à haut débit (6,3 kb/s)         24
  parole à bas débit (5,3 kb/s)          20
  trame SID                              4
  réservé

Il est possible de basculer entre les deux débits à n'importe quelle limite de trame de 30 ms. Les deux débits (5,3 kb/s et 6,3 kb/s) sont une partie obligatoire de l'encodeur et du décodeur. Les récepteurs DOIVENT accepter les deux débits de données et DOIVENT accepter les trames SID à moins que la restriction de ces capacités n'ait été signalée. L'enregistrement MIME pour G723 dans la RFC 3555 [7] spécifie les paramètres qui PEUVENT être utilisés avec MIME ou SDP pour restreindre à un seul débit de données ou pour restreindre l'utilisation des trames SID. Ce codeur a été optimisé pour représenter la parole avec une qualité proche de la qualité téléphonique aux débits ci-dessus en utilisant une quantité limitée de complexité.

L'emballage du flux binaire encodé en octets et l'ordre de transmission des octets sont spécifiés dans la Rec. G.723.1 et sont les mêmes que ceux produits par l'implémentation de référence du code C G.723. Pour le débit de données de 6,3 kb/s, cet emballage est illustré comme suit, où les bits d'en-tête (HDR) sont toujours "0 0" comme indiqué sur la Fig. 1 pour indiquer un fonctionnement à 6,3 kb/s, et le bit Z est toujours mis à zéro. Les diagrammes montrent l'emballage des bits dans "l'ordre des octets du réseau", également connu sous le nom d'ordre big-endian. Les bits de chaque mot de 32 bits sont numérotés de 0 à 31, avec le bit le plus significatif à gauche et numéroté 0. Les octets (bytes) de chaque mot sont transmis l'octet le plus significatif en premier. Les bits de chaque champ de données sont numérotés dans l'ordre de la représentation du flux binaire du codage (bit le moins significatif en premier). Les barres verticales indiquent les limites entre les fragments de champ.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSBPOS |Z|POS| MSBPOS | POS0 |POS| POS0 | | | | 0 | | | 1 | | |0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1| |6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS1 | POS2 | POS1 | POS2 | POS3 | POS2 | | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1| |9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | PSIG0 |POS|PSIG2| PSIG1 | PSIG3 |PSIG2| | | | 3 | | | | | |1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0| |1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1 : Emballage des bits G.723 (6,3 kb/s)

Pour le débit de données de 5,3 kb/s, les bits d'en-tête (HDR) sont toujours "0 1", comme indiqué sur la Fig. 2, pour indiquer un fonctionnement à 5,3 kb/s.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS0 | POS1 | POS0 | POS1 | POS2 | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 | | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2 : Emballage des bits G.723 (5,3 kb/s)

L'emballage des trames SID (silence) G.723.1, qui sont indiquées par les bits d'en-tête (HDR) ayant le motif "1 0", est représenté sur la Fig. 3.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | GAIN |LPC| | | | | | | | |0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3 : Emballage des bits en mode SID G.723

4.5.4 G726-40, G726-32, G726-24, et G726-16

La Recommandation ITU-T G.726 décrit, entre autres, l'algorithme recommandé pour la conversion d'un seul canal PCM A-law ou mu-law à 64 kbit/s codé à 8 000 échantillons/s vers et depuis un canal à 40, 32, 24 ou 16 kbit/s. La conversion est appliquée au flux PCM en utilisant une technique de transcodage par Modulation par Impulsion et Codage Différentiel Adaptatif (ADPCM). La représentation ADPCM consiste en une série de mots de code avec une correspondance biunivoque avec les échantillons du flux PCM. Les débits de données G726 de 40, 32, 24 et 16 kbit/s ont des mots de code de 5, 4, 3 et 2 bits, respectivement.

Les codages à 16 et 24 kbit/s ne fournissent pas une parole de qualité téléphonique. Ils sont conçus pour être utilisés dans des Équipements de Multiplication de Circuit Numérique (DCME) surchargés. L'ITU-T G.726 recommande que les codages à 16 et 24 kbit/s soient alternés avec des codages à débit de données plus élevé pour fournir une taille d'échantillon moyenne comprise entre 3,5 et 3,7 bits par échantillon.

Les codages de G.726 sont ici notés G726-40, G726-32, G726-24, et G726-16. Avant 1990, G721 décrivait le codage ADPCM à 32 kbit/s, et G723 décrivait les codages à 40, 32 et 16 kbit/s. Ainsi, G726-32 désigne le même algorithme que G721 dans la RFC 1890.

Un flux de mots de code G726 ne contient aucune information sur le codage utilisé, par conséquent les transitions entre les types de codage G726 ne sont pas autorisées au sein d'une séquence de mots de code emballés. Les applications DOIVENT déterminer le type de codage des mots de code emballés à partir de l'identifiant de charge utile RTP.

Aucune information d'en-tête spécifique à la charge utile NE DOIT être incluse comme partie de l'audio. Un flux de mots de code G726 DOIT être emballé dans des octets comme suit : le premier mot de code est placé dans le premier octet de telle sorte que le bit le moins significatif du mot de code s'aligne avec le bit le moins significatif de l'octet, le deuxième mot de code est ensuite emballé de sorte que son bit le moins significatif coïncide avec le bit inoccupé le moins significatif dans l'octet. Lorsqu'un mot de code complet ne peut pas être placé dans un octet, les bits chevauchant la limite de l'octet sont placés dans les bits les moins significatifs de l'octet suivant. L'emballage DOIT se terminer par un dernier octet complètement rempli. Le nombre de mots de code emballés sera donc un multiple de 8, 2, 8, et 4 pour G726-40, G726-32, G726-24 et G726-16, respectivement. Un exemple du schéma d'emballage pour les mots de code G726-32 est présenté ci-dessous, où le bit 7 est le bit le moins significatif du premier octet, et le bit A3 est le bit le moins significatif du premier mot de code :

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |B B B B|A A A A|D D D D|C C C C| ...
     |0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Un exemple du schéma d'emballage pour les mots de code G726-24 suit, où le bit 7 est à nouveau le bit le moins significatif du premier octet, et le bit A2 est le bit le moins significatif du premier mot de code :

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
     |1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Notez que la direction "little-endian" dans laquelle les échantillons sont emballés dans les octets dans les formats de charge utile G726-16, -24, -32 et -40 spécifiés ici est cohérente avec la Recommandation ITU-T X.420, mais est l'opposé de ce qui est spécifié dans la Recommandation ITU-T I.366.2 Annexe E pour le transport ATM AAL2. Un deuxième ensemble de formats de charge utile RTP correspondant à la mise en paquets de l'Annexe E de I.366.2 et identifié par les sous-types MIME AAL2-G726-16, -24, -32 et -40 sera spécifié dans un document séparé.

4.5.5 G728

G728 est spécifié dans la Recommandation ITU-T G.728, "Codage de la parole à 16 kbit/s utilisant la prédiction linéaire à excitation par code à faible délai".

Un codeur G.278 traduit 5 échantillons audio consécutifs en un index de livre de codes de 10 bits, résultant en un débit binaire de 16 kb/s pour de l'audio échantillonné à 8 000 échantillons par seconde. Le groupe de cinq échantillons consécutifs est appelé un vecteur. Quatre vecteurs consécutifs, étiquetés V1 à V4 (où V1 doit être joué en premier par le récepteur), construisent une trame G.728. Les quatre vecteurs de 40 bits sont emballés dans 5 octets, étiquetés B1 à B5. B1 DOIT être placé en premier dans le paquet RTP.

En se référant à la figure ci-dessous, le principe de l'ordre des bits est le "maintien de la signification des bits". Les bits d'un vecteur plus ancien sont plus significatifs que les bits de vecteurs plus récents. Le MSB de la trame va au MSB de B1 et le LSB de la trame va au LSB de B5.

               1         2         3        3
     0         0         0         0        9
     ++++++++++++++++++++++++++++++++++++++++
     <---V1---><---V2---><---V3---><---V4---> vecteurs
     <--B1--><--B2--><--B3--><--B4--><--B5--> octets
     <------------- trame 1 ---------------->

En particulier, B1 contient les huit bits les plus significatifs de V1, avec le MSB de V1 étant le MSB de B1. B2 contient les deux bits les moins significatifs de V1, le plus significatif des deux dans son MSB, et les six bits les plus significatifs de V2. B1 DOIT être placé en premier dans le paquet RTP et B5 en dernier.

4.5.6 G729

G729 est spécifié dans la Recommandation ITU-T G.729, "Codage de la parole à 8 kbit/s utilisant la prédiction linéaire à excitation par code algébrique à structure conjuguée (CS-ACELP)". Ce codec a été optimisé pour représenter la parole avec une haute qualité, là où G.728 est à faible délai et G.723.1 est à faible débit binaire. L'encodeur G.729 fonctionne sur des trames de parole de 10 ms correspondant à 80 échantillons à un taux d'échantillonnage de 8 000 échantillons par seconde. Le flux binaire généré a un débit binaire de 8 kbit/s. Par conséquent, chaque trame contient 80 bits.

L'emballage du flux binaire encodé en octets et l'ordre de transmission des octets sont spécifiés dans la Rec. G.729 et sont les mêmes que ceux produits par l'implémentation de référence du code C G.729. Les bits de chaque trame de 80 bits sont numérotés de 1 à 80, avec le bit le plus significatif à gauche et numéroté 1. Les octets (bytes) de chaque mot sont transmis l'octet le plus significatif en premier. Les bits de chaque champ de données sont numérotés dans l'ordre de la représentation du flux binaire du codage (bit le moins significatif en premier). Les barres verticales indiquent les limites entre les fragments de champ.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L0 | L1 | L2 | L3 | P1 | | | | | | | |0|0 0 0 0 0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0 0 0 0 0 0| | |6 5 4 3 2 1 0|4 3 2 1 0|4 3 2 1 0|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P1 | P2 | C1 | S1 | C2 | S2 | P1 | | | | | | | | | |0 0|0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0 0 0 0| |9 8|4 3 2 1 0|c c c c c|3 2 1 0|c c c c c|3 2 1 0|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 | C3 | S3 | C4 | S4 | | | | | | | |0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0|0 0 0| |4 3 2 1 0|c c c c c|3 2 1 0|c c c c c|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L'Annexe A de G.729 spécifie une version à complexité réduite de l'algorithme G.729. Le codeur de l'Annexe A produit un flux binaire identique à celui du codeur G.729.

L'Annexe B de G.729 définit un algorithme de compression de silence, qui est utilisé avec G.729 ou G.729 Annexe A. En détectant une période de silence, l'encodeur transmet une trame SID (Descripteur d'Insertion de Silence) de 2 octets qui spécifie les paramètres de bruit de confort. Il n'y a aucune restriction sur la manière dont les trames de 10 et 2 octets sont mélangées. La trame SID est partiellement des indices de livre de codes de somme et partiellement des paramètres de l'algorithme de compression de silence. Les champs de la trame SID sont présentés dans le diagramme ci-dessous.

0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L0 | L1 | L2 | L3 | GAIN | | | | | | | |0|0 0 0 0 0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0 0 0| | |6 5 4 3 2 1 0|4 3 2 1 0|4 3 2 1 0|4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pour G.729 Annexe B, la génération VAD/DTX codée par canal comprend la transmission de trames à 1/16ème de débit (800 bps) qui ne font que 10 bits de longueur (1,25 octets). Comme celles-ci ne rentrent pas dans un nombre entier d'octets, l'emballage de ces trames reste à étudier. Les récepteurs fonctionnant sous ce format de charge utile DOIVENT accepter les trames de parole de 80 bits et les trames SID de 16 bits. Le récepteur PEUT rejeter les trames de 10 bits, le cas échéant.

4.5.7 G729D et G729E

L'Annexe D de G.729 définit une extension à débit binaire inférieur (6,4 kb/s) à l'algorithme. Le codeur G.729 Annexe D produit une trame de 64 bits.

L'Annexe E de G.729 définit une extension à débit binaire supérieur (11,8 kb/s) à l'algorithme. Le codeur G.729 Annexe E produit une trame de 118 bits.

L'emballage du flux binaire encodé en octets et l'ordre de transmission des octets sont spécifiés dans la Rec. G.729 et sont les mêmes que ceux produits par l'implémentation de référence du code C G.729. Les bits de chaque trame de 64 bits ou 118 bits sont numérotés de 1 à n, avec le bit le plus significatif à gauche et numéroté 1. Les octets (bytes) de chaque mot sont transmis l'octet le plus significatif en premier. Les bits de chaque champ de données sont numérotés dans l'ordre de la représentation du flux binaire du codage (bit le moins significatif en premier).

Les Rec. ITU-T G.729 Annexes D et E ne spécifient pas actuellement comment la Détection d'Activité Vocale (VAD) et la Transmission Discontinue (DTX) devraient être gérées. Par conséquent, elles NE DEVRAIENT PAS être utilisées avec ce format de charge utile.

4.5.8 GSM

GSM (Group Speciale Mobile) désigne la norme européenne GSM 06.10 pour le transcodage de la parole à plein débit, ETS 300 961, qui est basée sur le codage RPE/ LTP (excitation par impulsion résiduelle/prédiction à long terme) à un débit de 13 kb/s [11,12,13]. Le texte de la norme peut être obtenu sur le site web de l'ETSI (Institut européen des normes de télécommunication) à http://www.etsi.org.

4.5.8.1 Problèmes généraux d'emballage

La norme GSM spécifie le flux binaire produit par le codec, mais ne spécifie pas comment ces bits doivent être emballés pour la transmission. Contrairement aux formats de charge utile pour les autres codages audio spécifiés dans ce document, le format de charge utile GSM emballe les octets différemment de la représentation standard utilisée par l'implémentation de référence C GSM 06.10.

L'implémentation standard GSM 06.10 empaquette les 260 bits d'une trame GSM en 33 octets (16 mots dans les systèmes 16 bits), avec les bits occupant les bits les moins significatifs de chaque octet/mot. Pour transmettre ceux-ci en RTP, les 260 bits sont emballés dans 33 octets comme défini dans ETSI TS 101 318 [4]. Ce dernier est effectivement la norme pour la VoIP/VoFR/VoATM et est le même que le format "Toast" utilisé par l'implémentation GSM citée à la Section 13.

Dans le format de charge utile RTP, une trame est emballée dans 33 octets (264 bits) en remplissant les 4 bits libres du dernier octet avec des zéros. Deux trames sont emballées dans 66 octets. La correspondance des champs est présentée dans le Tableau 2.

4.5.8.2 Noms de variables et numéros GSM

Les paramètres du codec audio GSM sont nommés de la manière suivante, selon la norme GSM 06.10.

                         Tableau 2 : Format de charge utile GSM

Champ Nom du champ Bits Octet Bit

1 LARc[0] 6 1 0--5 2 LARc[1] 6 1, 2 6--7, 0--3 3 LARc[2] 5 2, 3 4--7, 0 4 LARc[3] 5 3 1--5 5 LARc[4] 4 3, 4 6--7, 0--1 6 LARc[5] 4 4 2--5 7 LARc[6] 3 4, 5 6--7, 0 8 LARc[7] 3 5 1--3 9 Nc[0] 7 5, 6 4--7, 0--2 10 bc[0] 2 6 3--4 11 Mc[0] 2 6 5--6 12 xmaxc[0] 6 6, 7 7, 0--4 13 xmc[0] 3 7 5--7 14 Nc[1] 7 8 0--6 15 bc[1] 2 8, 9 7, 0 16 Mc[1] 2 9 1--2 17 xmaxc[1] 6 9, 10 3--7, 0 18 xmc[1] 3 10 1--3 19 Nc[2] 7 10, 11 4--7, 0--2 20 bc[2] 2 11 3--4 21 Mc[2] 2 11 5--6 22 xmaxc[2] 6 11, 12 7, 0--4 23 xmc[2] 3 12 5--7 24 Nc[3] 7 13 0--6 25 bc[3] 2 13, 14 7, 0 26 Mc[3] 2 14 1--2 27 xmaxc[3] 6 14, 15 3--7, 0 28 xmc[3] 3 15 1--3

4.5.9 GSM-EFR

GSM-EFR est spécifié dans ETS 300 726 (GSM 06.60). C'est un codec vocal à plein débit amélioré, avec la même fréquence d'horloge (8 000 Hz) et le même débit binaire (12,2 kb/s) que le codec GSM.

4.5.10 L8

L8 désigne des échantillons de données audio linéaires, utilisant 8 bits de précision avec un décalage de 128, c'est-à-dire que le signal le plus négatif est représenté par la valeur 0, le signal nul par la valeur 128, et le signal le plus positif par la valeur 255.

4.5.11 L16

L16 désigne des échantillons de données audio linéaires signés (16 bits). Les échantillons audio linéaires L16 DEVRAIENT être transmis dans l'ordre des octets du réseau (octet le plus significatif en premier).

4.5.12 LPC

LPC désigne un codage prédictif linéaire expérimental fourni par Ron Frederick au Xerox PARC, qui est basé sur une implémentation écrite à l'origine par Steve Casner à l'ISI. Le code source pour l' encodeur et le décodeur est disponible comme indiqué à la Section 13.

4.5.13 MPA

MPA désigne l'utilisation de flux élémentaires audio MPEG-1 ou MPEG-2. Le format de charge utile RTP est tel que spécifié dans la RFC 2250 [14], Section 3.

4.5.14 PCMA et PCMU

PCMA et PCMU sont spécifiés dans la Recommandation ITU-T G.711. Les données audio sont codées sous forme de huit bits par échantillon, après une mise à l'échelle logarithmique. PCMU désigne la mise à l'échelle mu-law, PCMA la mise à l'échelle A-law. Une description détaillée est donnée par Jayant et Noll [15]. Chaque octet G.711 DOIT être aligné sur l'octet dans un paquet RTP. Le bit de signe de chaque octet G.711 DOIT correspondre au bit le plus significatif de l'octet dans le paquet RTP (c'est-à-dire, en supposant que les échantillons G.711 sont traités comme des octets sur la machine hôte, le bit de signe doit être le bit le plus significatif de l' octet tel que défini par le format de la machine hôte). Les modes 56 kb/s et 48 kb/s de G.711 ne sont pas applicables au RTP, puisque PCMA et PCMU DOIVENT toujours être transmis sous forme d'échantillons de 8 bits.

4.5.15 QCELP

Le codec audio Qualcomm Code Excited Linear Prediction (QCELP) est spécifié dans TIA/EIA IS-733, "TR45: High Rate Speech Service Option 17 for Wideband Spread Spectrum Communication Systems".

Le codec QCELP est utilisé pour la norme de système de téléphonie cellulaire CDMA TIA/EIA IS-95. Le codec QCELP s'adapte à différents débits de données, qui peuvent être sélectionnés trame par trame. Le débit de données maximum est de 13 kbit/s. Ce format de charge utile ne définit aucun type de trame silencieuse distinct, mais le débit de données peut être réduit à environ 1 kbit/s dans les périodes de silence.

Le format de charge utile RTP est spécifié dans [16].

4.5.16 RED

Le format de charge utile audio redondant "RED" est spécifié dans la RFC 2198 [17]. Il définit un moyen par lequel plusieurs copies redondantes d'un paquet audio peuvent être transmises dans un seul flux RTP.

4.5.17 VDVI

VDVI est une version à débit variable de DVI4, disponible pour une affectation dynamique. Les échantillons DVI4 sont emballés dans des octets, mais le nombre de bits par échantillon peut varier d'un paquet à l'autre et est spécifié dans l'en-tête du paquet. Pour VDVI, le champ de type de charge utile de l'en-tête RTP est un type dynamique mappé à "VDVI".

Chaque paquet contient un seul bloc DVI. Le mot "en-tête" pour chaque canal a la structure suivante :

  int16  predict;  /* valeur prédite du premier échantillon
                      du bloc précédent (format L16) */
  u_int8 index;    /* index actuel dans la table de taille de pas */
  u_int8 sample_size; /* nombre de bits par échantillon */

La taille de l'échantillon DOIT être l'une des valeurs 3, 4 ou 5. Si sample_size est 4, l' emballage des échantillons est le même que pour DVI4. Si sample_size est 3 ou 5, les échantillons sont emballés dans les prochains bits disponibles de l'octet courant de la fenêtre de paquet, en commençant par le MSB. Lorsqu'un échantillon chevauche une limite d'octet, les bits sont placés dans les LSB du premier octet et les MSB du deuxième octet. L'échantillon suivant est ensuite emballé en commençant au premier MSB disponible du deuxième octet. Le processus continue pour l'ensemble du paquet.