Exploration approfondie du mécanisme de mise en œuvre du délai anti-réseau audio NetEQ et de l'anti-perte de paquets dans la bibliothèque open source audio et vidéo WebRTC

Table des matières

1. Introduction

2. Introduction à WebRTC

3. Qu'est-ce que NetEQ ?

4. Explication détaillée de la technologie NetEQ

4.1. Présentation de NetEQ

4.2. Technologie d'élimination de la gigue

4.3. Technologie de compensation des pertes de paquets

4.4. Conception générale de NetEQ

4.5. Mécanisme de commande NetEQ

4.6. Mécanisme de lecture NetEQ

4.7. Mécanisme de contrôle du MCU

4.8. Traitement de l'algorithme DSP

4.9. Test de simulation de l'algorithme DSP

5. Description du fichier source NetEQ

6. Documents de référence


Résumé du développement des fonctions communes de VC++ (liste des articles de chroniques, bienvenue pour s'abonner, mises à jour continues...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/124272585 Série de tutoriels de dépannage d'anomalies logicielles C++ de entrée à la compétence (liste des articles de la colonne), bienvenue pour vous abonner et continuer à mettre à jour...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/125529931 Outils d'analyse de logiciels C++ de l'entrée à la collection de cas de maîtrise (colonne l'article est en cours de mise à jour...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/131405795 Bases et avancées du C/C++ (article de chronique, mis à jour continuellement...) icon-default.png?t=N7T8https://blog.csdn.net /chenlycly/category_11931267.htmlComposants open source et technologie de base de données (article de chronique, mis à jour continuellement...) icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/category_12458859.html        Logiciels audio et vidéo À mesure que les scénarios d'application et les environnements d'utilisation changent, la qualité audio les exigences sont de plus en plus élevées. , pour obtenir des effets audio de haute qualité, vous pouvez apprendre de certaines solutions matures dans le domaine audio et vidéo. WebRTC est actuellement l'un des moteurs vocaux les plus avancés qui résout les problèmes de qualité vocale. Parmi eux, le module d'égalisation de réseau NetEQ résout bien les problèmes de retard, de gigue et de perte de paquets dans les données audio avec une faible bande passante. Cet article analysera en détail le principe de mise en œuvre, le flux de traitement et le mécanisme de traitement de compensation de perte de paquets de l'égaliseur de réseau NetEQ dans WebRTC.

1. Introduction

       Étant donné que les réseaux IP sont principalement utilisés pour les services de transmission de données, contrairement aux téléphones traditionnels qui occupent des lignes logiques ou physiques indépendantes, il n'y a aucune garantie de qualité de service (Qos), et il existe des problèmes tels que l'arrivée de paquets dans le désordre, le retard, la perte de paquets, et la gigue. En cas de perte de paquets, des mécanismes de retransmission ou de transmission multiples peuvent être utilisés dans l'entreprise. Cependant, les logiciels audio et vidéo sont des services en temps réel et ont des exigences strictes en matière de bande passante, de délai et de gigue, de sorte que certaines garanties de QoS doivent être fournies.

       Il existe deux facteurs principaux qui affectent la qualité audio dans les logiciels audio et vidéo : la gigue de retard et le traitement des pertes de paquets. Généralement, les tampons de gigue sont utilisés pour éliminer les effets néfastes causés par la transmission réseau. La technologie des tampons de gigue affecte directement le traitement des pertes de paquets. Le tampon de réception peut être utilisé pour éliminer la gigue de retard, mais en cas de perte de paquets, il gèlera ou remplira le silence ou la compensation d'interpolation. Cependant, dans un réseau avec un retard important, une gigue importante et une perte de paquets importante, l'effet n'est pas idéal. .

        Comment emprunter la technologie d'égalisation de réseau NetEQ dans WebRTC pour améliorer la qualité audio du logiciel. Tout d'abord, vous devez analyser et décomposer les principes et les procédures de traitement de NetEQ. Deuxièmement, vous devez comprendre les principes et les scénarios d'utilisation de la perte de paquets. algorithme de compensation, puis l'appliquer efficacement à la conception de produits logiciels.

2. Introduction à WebRTC

        Avant de présenter en détail l'égaliseur de réseau NetEQ dans WebRTC, commençons par avoir une compréhension générale de WebRTC.

       WebRTC (Web Real-Time Communication) est une bibliothèque open source C++ de communication audio et vidéo en temps réel initiée par Google. Elle fournit un ensemble complet de solutions audio et vidéo telles que la collecte audio et vidéo, l'encodage, la transmission réseau, le décodage et l'affichage. , etc. Nous pouvons utiliser cette bibliothèque open source pour créer rapidement une application de communication audio et vidéo.

Un logiciel d'application audio et vidéo temps réel comprend généralement les liens suivants : collection audio et vidéo, encodage audio et vidéo (compression), pré- et post-traitement (embellissement, filtres, annulation d'écho, suppression de bruit, etc.), réseau transmission, décodage et rendu (lecture audio et vidéo), etc. Chacun de ces liens subdivisés comporte également des modules techniques plus subdivisés.

      Bien qu'il s'appelle WebRTC, il prend en charge non seulement la communication audio et vidéo entre le Web, mais également les plates-formes mobiles telles que Windows, Android et iOS. La couche inférieure de WebRTC est développée en C/C++ et offre de bonnes performances multiplateformes.

  • WebRTC est principalement développé et implémenté en C++. Le code utilise un grand nombre de nouvelles fonctionnalités de C++ 11 et supérieur. Avant de lire le code source, vous devez avoir une compréhension générale de ces nouvelles fonctionnalités de C++.
  • Il est nécessaire d'apprendre les nouvelles fonctionnalités de C++ 11. Non seulement les nouvelles fonctionnalités sont fréquemment utilisées dans le code open source C++, mais elles sont également souvent demandées lors d'entretiens écrits lors d'un changement de poste.
  • Il est recommandé de lire attentivement le nouveau " Guide de style du projet Google Open Source (zh-google-styleguide) ", gratuit et public. Il ne s'agit pas seulement des normes de codage de Google, il vous indique non seulement quoi faire lors du codage, mais aussi vous dit pourquoi vous devriez le faire. Faites-le ! C’est également très bénéfique pour apprendre les nouvelles fonctionnalités de C++11 et supérieur ! Notre équipe de projet a étudié systématiquement ce guide de style de projet l'année dernière et en a tiré de nombreux enseignements : il constitue une grande valeur de référence !

       En raison de ses bons effets audio et vidéo et de sa bonne adaptabilité réseau, WebRTC a été largement utilisé dans les vidéoconférences, la diffusion audio et vidéo en direct en temps réel et dans d'autres domaines. Dans le domaine de la vidéoconférence, des fabricants nationaux tels que Tencent Conference, Huawei WeLink, Byte Feishu, Alibaba DingTalk, Xiaoyu Yilian et Xiamen Yilian proposent tous des vidéoconférences basées sur des solutions WebRTC.

       Agora, un fournisseur de services audio et vidéo professionnel bien connu, est basé sur la bibliothèque open source WebRTC et propose des services de diffusion sociale en direct, d'éducation, de jeux et d'e-sports, d'IoT, d'AR/VR, de finance, d'assurance, de médecine, de collaboration d'entreprise et autres industries.Solutions interactives audio et vidéo. Les entreprises utilisant les services de Shengwang incluent Xiaomi, Momo, Douyu, Bilibili, New Oriental, Xiaohongshu, HTC VIVE, The Meet Group, Bunch, Yalla et d'autres géants mondiaux, licornes et startups. Outre la société leader Shengwang, de nombreuses entreprises ont développé plusieurs applications audio et vidéo basées sur le WebRTC open source, fournissant des solutions de communication audio et vidéo dans de multiples domaines.

3. Qu'est-ce que NetEQ ?

       NetEQ est essentiellement un JitterBuffer audio (tampon de gigue), le nom complet est Network Equalizer (Network Equalizer).

       L'une des deux technologies principales du moteur vocal GIPS est une technologie avancée de tampon de gigue adaptative qui inclut un algorithme de masquage de perte de paquets, appelé NetEQ. En 2010, Google a acquis cette technologie auprès de Global IP Solutions pour 68,2 millions de dollars. Une autre technologie de base est l'algorithme 3A. Par la suite, Google l'a intégré à WebRTC et l'a publié en open source en 2011.

        NetEQ intègre un algorithme de contrôle adaptatif de la gigue et un algorithme de masquage des pertes de paquets vocaux, et est intégré au décodeur, afin que NetEQ puisse toujours maintenir une bonne qualité vocale dans un environnement à perte de paquets élevée.

4. Explication détaillée de la technologie NetEQ

4.1. Présentation de NetEQ

       Le traitement NetEQ inclut un algorithme de contrôle adaptatif de la gigue et un algorithme de compensation de perte de paquets vocaux. L'algorithme de gigue adaptatif peut s'adapter rapidement à l'environnement réseau changeant, tandis que l'algorithme de compensation de perte de paquets vocaux peut garantir une certaine qualité et clarté sonore avec un délai de mise en mémoire tampon minimal. De plus, le test de simulation de l'algorithme NetEQ permet d'évaluer l'effet de la qualité sonore et comment il se compare à l'existant La combinaison organique de la conception de logiciels.

       Le traitement NetEQ inclut un algorithme de contrôle adaptatif de la gigue et un algorithme de compensation de perte de paquets vocaux. L'algorithme de gigue adaptatif peut s'adapter rapidement à l'environnement réseau changeant, tandis que l'algorithme de compensation de perte de paquets vocaux peut garantir une certaine qualité et clarté sonore avec un délai de mise en mémoire tampon minimal. De plus, le test de simulation de l'algorithme NetEQ permet d'évaluer l'effet de la qualité sonore et comment il se compare à l'existant La combinaison organique de la conception de logiciels.

       Le diagramme de présentation du module de NetEQ est le suivant :

Comme le montre la figure ci-dessus, NetEQ est divisé en 4 parties : tampon de paquets adaptatif, décodeur vocal, contrôle de la gigue et masquage des erreurs, et lecture. Le module de contrôle de gigue et de compensation de perte de paquets est l'algorithme de base de NetEQ, qui contrôle non seulement la mise en mémoire tampon adaptative, mais contrôle également le décodeur et l'algorithme de compensation de perte de paquets, et transmet les résultats finaux du calcul à la carte son pour la lecture.

       Tout d’abord, NetEQ est actuellement la technologie d’élimination du jitter la plus complète. Comparé à la mise en mémoire tampon de gigue fixe et à la mise en tampon de gigue adaptative traditionnelle, NetEQ peut s'adapter rapidement aux environnements réseau changeants, garantissant ainsi des délais plus courts et moins de pertes de paquets. La comparaison des performances de l'algorithme de tramage adaptatif NetEQ est présentée dans la figure ci-dessous :

       Deuxièmement, le module de contrôle de la gigue et de compensation de perte de paquets se compose de trois opérations principales, à savoir Expansion, Normal et Accélération :

Expansion : opération d'expansion, c'est-à-dire allongement de la durée de la voix, y compris les modes expand et preemptive_expand. Le premier est le traitement de compensation de perte de paquets de NetEQ, dont la fonction est d'attendre les paquets retardés et de compenser la perte de paquets ; le second est une expansion prioritaire, qui allonge la durée de la voix en fonction des données d'origine, et sa fonction est de ralentir la lecture.
Normal : fonctionnement de lecture normal, c'est-à-dire fonctionnement lorsque l'environnement réseau est normal et relativement stable.
Accélérer : Accélérez l'opération, c'est-à-dire obtenez une lecture rapide.

En résumé, cet article traite principalement de la technologie d'élimination de la gigue et de compensation des pertes de paquets de NetEQ, et combine des tests de simulation et une analyse de conception de produits pour améliorer encore la qualité sonore des appels des produits de visioconférence. La liste des performances NetEQ ressemble à ceci :

4.2. Technologie d'élimination de la gigue

       Il existe deux définitions de la gigue :

Définition de gigue 1 : fait référence aux changements dans le taux d'arrivée des paquets de données sur le réseau en raison de divers retards. Plus précisément, la gigue peut être définie comme la différence entre l'intervalle d'envoi du flux de données à l'extrémité d'envoi et l'intervalle de réception à l'extrémité de réception, ce qui convient aux scénarios de débit de code variable.
Définition de gigue 2 : la différence entre l'intervalle d'arrivée d'un certain paquet de données à l'extrémité de réception et l'intervalle d'arrivée moyen des paquets de données est définie comme la gigue de retard du paquet de données et est utilisée dans des scénarios de débit de code constant.

La gigue est une séquence aléatoire de moyenne nulle constituée de différences de délai dans les paquets IP en file d'attente. Lorsque les paquets de données s'accumulent, cela signifie que les paquets de données arrivent plus tôt. Bien que l'intégrité de la voix soit assurée, cela peut facilement provoquer un débordement de tampon à la réception et augmenter le délai de bout en bout. Lorsque le paquet de données expire, cela signifie que le paquet de données n'a pas atteint l'extrémité de réception après un certain temps après avoir été transmis via le réseau, ce qui indique que le paquet de données peut arriver en retard ou être perdu. Étant donné que le débordement et le délai d'attente peuvent entraîner une perte de paquets, ils augmenteront la probabilité de perte de paquets de bout en bout. Par conséquent, la gigue doit être contrôlée efficacement pour réduire la perte de paquets qu’elle provoque.

       La gigue est généralement éliminée à l'aide de la technologie de mise en tampon de gigue, c'est-à-dire qu'un tampon est établi au niveau du récepteur. Lorsque le paquet vocal arrive au récepteur, il entre d'abord dans le tampon et est temporairement stocké. Ensuite, le système extrait le paquet vocal du tampon à un débit constant et le décompresse. Jouez à partir du port audio. L'état idéal d'élimination de la gigue est le suivant : le délai de chaque paquet dans la transmission réseau doit être égal au délai de toutes les données mises en mémoire tampon dans le tampon, et la taille du tampon doit être égale à la gigue de chaque paquet arrivant en avance plus le temps mis en mémoire tampon. données. La somme des retards est égale.

       Les algorithmes de contrôle du tampon de gigue incluent des algorithmes de contrôle de la gigue du tampon statique et des algorithmes de contrôle de la gigue du tampon adaptatif :

Algorithme de contrôle de gigue statique : Le délai et la taille du tampon sont des valeurs fixes après l'établissement de l'appel vocal jusqu'à la fin de l'appel. Les données avec un délai d'attente et une gigue dépassant la taille du tampon seront rejetées. Le modèle d'algorithme est simple et facile à mettre en œuvre ; cependant, lorsque le délai et la gigue du réseau sont importants, le taux de perte de paquets est élevé, et lorsque le délai et la gigue du réseau sont faibles, le délai vocal est important, et le délai et la taille de le tampon ne peut pas être modifié dynamiquement en fonction des conditions du réseau. , et la valeur initiale limite les conditions de réseau applicables.

Algorithme de contrôle adaptatif de la gigue : le délai et la taille du tampon changent en fonction de la gigue du réseau réel. L'extrémité réceptrice compare le retard du paquet de données actuellement reçu avec les informations de retard enregistrées dans l'algorithme pour obtenir la gigue maximale du réseau actuel, sélectionnant ainsi le retard et la taille du tampon appropriés. L'avantage de cet algorithme est que le taux de perte de paquets est faible lorsque la gigue du réseau est importante, et le délai est faible lorsque la gigue du réseau est faible. L'inconvénient est que l'algorithme est diversifié et relativement complexe.

Compte tenu de la complexité et de la variabilité des réseaux actuels, des algorithmes de gigue adaptatifs sont généralement utilisés, et l'élimination de la gigue de NetEQ appartient également à ce type d'algorithme.

4.3. Technologie de compensation des pertes de paquets

       La compensation de perte de paquets est également appelée Packet Loss Concealment, ou PLC en abrégé, et peut être divisée en deux catégories : la compensation basée sur l'expéditeur et la compensation basée sur le récepteur. La technologie de compensation de perte de paquets comprend les éléments suivants :


       La compensation basée sur l'expéditeur est également appelée récupération de perte de paquets, c'est-à-dire Packet Loss Recovery. D'une manière générale, la compensation basée sur l'émetteur est meilleure que la compensation basée sur le récepteur, mais elle augmentera la bande passante et le délai du réseau.

       FEC (Forward Error Correction) est actuellement la technologie de codage redondant la plus prometteuse pour améliorer la qualité de la voix VoIP, visant à améliorer la fiabilité de la transmission des données vocales. Pour cette raison, FEC doit non seulement transmettre les données originales, mais également transmettre certaines données redondantes basées sur la corrélation, afin que le décodeur puisse reconstruire le paquet de données perdu sur la base de la corrélation entre les données. Le plus simple en VoIP est le code de parité. Cette méthode consiste à transmettre un code de contrôle contenant l'opération XOR des n paquets de données précédents pour tous les n paquets de données 1. Lorsque le réseau ne perd qu'un paquet tous les n paquets de données, il peut obtenir le code de contrôle à partir d'autres n-1 données. paquets pour reconstruire les paquets perdus. La FEC basée sur les paquets de parité ressemble à ceci :

       En cas de perte continue de paquets, diverses techniques de compensation telles que la FEC ne sont pas efficaces. Afin de résister à de larges segments de perte soudaine et continue de la voix, la technologie d’entrelacement peut être utilisée. La technologie d'entrelacement n'est pas une véritable technologie de récupération de perte de paquets car elle ne peut pas récupérer les paquets de données perdus, mais cette technologie peut réduire les pertes causées par la perte de paquets. La technologie d'entrelacement divise les données d'origine en plusieurs unités plus petites que les paquets IP et réorganise l'ordre de ces unités avant l'envoi, de sorte que les données de chaque paquet IP proviennent de trames vocales différentes. Lorsqu'une trame est perdue, seule chaque partie de la trame les données d'une trame sont perdues, toutes les données d'une trame ne seront pas perdues. Ces unités sont réorganisées à l'extrémité de réception. La technologie d'entrelacement tire parti de la capacité du cerveau humain à récupérer automatiquement une partie des données perdues en utilisant la perception auditive. Lorsque seule une petite quantité de données est perdue par image, l’impact sur l’audition humaine est moindre, améliorant ainsi la qualité du son. Puisqu'aucune information supplémentaire n'est émise, la bande passante ne sera pas augmentée, mais comme une réorganisation est nécessaire à la réception, le délai sera augmenté et sera intolérable dans une certaine mesure. Le système GSM utilise la technologie d'entrelacement.

       La technique d'entrelacement est la suivante :

       Le codage redondant à faible débit est une technologie redondante. En plus de ses propres données, chaque paquet de données contient également une copie compressée des données de la trame précédente. Cette copie est de faible qualité et occupe des bits. Le nombre est petit. Lorsque l'extrémité réceptrice perd un paquet, cette copie peut être utilisée pour reconstruire rapidement le paquet perdu à partir des paquets de données suivants. Contrairement à FEC, le nombre de bits ajoutés est corrélé aux trames précédentes et suivantes. Il est simplement copié dans les paquets suivants, ce qui augmente également la bande passante et le délai. Cependant, comme FEC, il ne s'applique pas à la perte continue de paquets lorsque le réseau est encombré, ce qui entraînera une perte de paquets plus grave. G.729A utilise une technologie de codage redondante. Le diagramme schématique de la perte de paquets de récupération de codage redondant est le suivant :

       Le principe de base de la technologie de compensation de perte de paquets à l'extrémité réceptrice est de générer une voix de remplacement similaire au paquet vocal perdu. La faisabilité de cette technologie repose sur la similarité à court terme de la voix et l'effet de masquage de l'oreille humaine. , et peut gérer des pertes de paquets plus faibles (<15 %) et des paquets vocaux plus petits (4 ~ 40 ms). La compensation pour la perte de paquets à la réception ne peut pas remplacer la compensation à l’envoi car les données perdues ne peuvent pas être récupérées avec précision. Par conséquent, lorsque le taux de perte de paquets du réseau est important, vous devez vous fier à la technologie de compensation de l'expéditeur, mais lorsque le taux de perte de paquets est trop important, vous ne pouvez qu'optimiser le réseau.

       La méthode basée sur l'insertion fait référence à une méthode permettant de masquer la perte de paquets en insérant une simple forme d'onde à l'emplacement de perte de paquet. Cette forme d'onde n'a généralement aucune corrélation avec la forme d'onde perdue, y compris le silence, le bruit blanc et la copie.

       Le champ d'application du remplacement silencieux est très limité et il fonctionne mieux lorsque le taux de perte de paquets est inférieur à 2 % et que la trame vocale est inférieure à 4 ms. Le bruit blanc ou bruit de confort tire parti de la capacité subconsciente du cerveau humain à réparer les formes d'onde perdues avec une parole correcte, ce qui est mieux que le silence.

       La copie est une méthode utilisée par le système GSM. Lorsqu'une perte continue de paquets se produit, la forme d'onde compensée est générée en atténuant progressivement les données de la trame précédente. Puisque la corrélation entre les trames précédentes et suivantes de la voix n'est pas prise en compte, l'effet est pas très idéal. La technologie d'interpolation fait référence à l'utilisation de formes d'onde similaires pour compenser la perte de paquets. Cette technologie est relativement complexe. Elle utilise les données avant et après la perte de paquets pour estimer les données perdues, puis remplace la forme d'onde perdue par la forme d'onde la plus similaire, de sorte que l'effet est mieux que la technologie d’insertion. .

       La technologie d'interpolation inter-trames est une technologie traditionnelle de dissimulation d'erreurs. Pour les codeurs vocaux avec codage par transformation ou codage par prédiction linéaire, le décodeur peut compenser en interpolant les paramètres de la trame précédente sur la base de la stationnarité à court terme du signal vocal et de la corrélation de paramètres entre trames adjacentes. G.723.1 utilise la technologie d'interpolation de paramètres pour effectuer une interpolation inter-trame sur les coefficients LSP et les signaux d'excitation respectivement afin de compenser les trames perdues ; G.729 utilise également les paramètres de la trame précédente pour l'interpolation afin de masquer les trames d'erreur, en utilisant la linéarité de la trame précédente. coefficient de prédiction de trame (LPC) et coefficient de réduction de gain pour compenser les trames perdues.

       La technologie de compensation basée sur la reconstruction reconstruit les informations de décodage avant et après la perte de paquet pour générer un paquet de compensation, qui nécessite la plus grande quantité de calculs et a le meilleur effet. Il est complété à l'extrémité de réception et ne nécessite pas la participation de l'extrémité d'envoi ni de flux binaires supplémentaires, il peut donc répondre aux exigences de la transmission en temps réel et est plus efficace et plus pratique dans la transmission sur réseau moderne.

       La technologie de remplacement de forme d'onde basée sur la détection de hauteur consiste à calculer la période de hauteur, puis à juger le son non voisé et voisé de la trame en fonction de la période de hauteur. S'il n'est pas voisé, utilisez la forme d'onde la plus récente avant la perte de paquet, sinon utilisez le segment avec la longueur de la période de pitch avant la perte du paquet. Remplacez-le par une forme d'onde appropriée, puis combinez l'énergie à court terme et le taux de passage à zéro pour récupérer la parole perdue. L'effet est dû à la technologie d'insertion, mais il est relativement compliqué.

       L'unité de base du traitement numérique du signal vocal est la tonalité fondamentale. La tonalité fondamentale fait référence au son de fréquence la plus basse émis lorsqu'un objet vibre, le reste étant constitué d'harmoniques. C'est-à-dire que lorsque le corps émetteur du son vibre, il transporte la majeure partie de l'énergie de la parole. La fréquence de cette vibration des cordes vocales est appelée fréquence fondamentale, et la période correspondante est la fréquence fondamentale. L'estimation de la période de hauteur est appelée détection de hauteur et son objectif est d'obtenir la durée de la période de hauteur qui correspond exactement à la fréquence de vibration des cordes vocales.

       La technologie de compensation de perte de paquets n'est pas utilisée dans l'encodeur G.711 qui utilise le codage de forme d'onde, mais afin d'améliorer la qualité de la voix, une technologie de remplacement de forme d'onde basée sur la détection de hauteur est ajoutée à l'annexe du protocole G.711 pour compenser la perte de trame, ce qui utilise la trame précédente décodée. Les données sont utilisées pour estimer la période de hauteur du signal vocal actuel, et les données de la période de hauteur la plus récente et du quart de période de hauteur avant celle-ci sont utilisées pour compenser les données manquantes. Les données du premier quart de période de hauteur sont utilisées pour se chevaucher et s'ajouter au signal vocal avant la perte de trame afin d'assurer une transition douce entre le signal d'origine et le signal de compensation. Si les données de la trame suivante ne sont pas perdues, afin d'assurer une transition en douceur, les données de période de 1/4 de hauteur sont étendues et superposées et ajoutées aux données décodées normales. Si l'image suivante est toujours perdue, les données d'une période de pitch supplémentaire seront extraites à des fins de compensation. Jusqu'à 3 périodes de pitch peuvent être extraites. Plus il y a de trames perdues, plus la différence entre la parole compensée et la parole réelle est grande. Par conséquent, à l'exception de la première image, la compensation continue de la perte de trame doit être atténuée image par image à un taux de 20 %. Puisque le signal vocal est une série temporelle quasi-stationnaire, en particulier le signal voisé, qui a une certaine périodicité, il est préférable d'utiliser les données vocales avant la perte de trame pour reconstruire les données de perte de trame.

       La technologie de correction du domaine temporel utilise les formes d'onde des deux côtés de l'espace pour s'étendre dans la direction de l'espace afin de combler l'espace, trouver les vecteurs qui se chevauchent de la période de hauteur de chaque côté de l'espace, les décaler pour couvrir l'espace, et faire la moyenne des parties qui se chevauchent. Cette méthode évite le phénomène de discontinuité de phase à la limite de l'espace et aucun son plosif n'est entendu à la jonction de la perte de paquets. L'effet subjectif est meilleur que le remplacement de la forme d'onde de la détection de hauteur.

       La technologie de compensation de perte de paquets de NetEQ dans WebRTC utilise une technologie de compensation de perte de paquets qui intègre l'algorithme iLBC. Le nom complet d'iLBC est Internet Low Bit rate Codec. Il s'agit d'un algorithme de codage et de décodage développé par GIPS spécialement conçu pour la communication réseau à commutation de paquets. Le taux d'échantillonnage est de 8 kHz. Il existe deux temps de codage de 20 ms et 30 ms. Les taux de code sont 15,2 kbps et 13,3 kbps respectivement, ce qui est très résistant à la perte de paquets. La compensation de perte de paquets d'iLBC n'est traitée qu'à l'extrémité du décodage, et la méthode de récupération basée sur un modèle est utilisée pour générer des paquets de compensation. Les étapes spécifiques sont :

1) Reconstruire les coefficients de prédiction linéaire (LPC) , c'est-à-dire utiliser le système LPC de la dernière image à reconstruire. Parce que la dernière image a la plus grande corrélation avec le LPC de l'image perdue actuelle, à la fois spatialement et temporellement, mais cette simple copie introduira évidemment une plus grande distorsion lorsqu'il s'agira de trames perdues consécutives.
2) Reconstruire le signal résiduel . Le signal résiduel peut généralement être divisé en deux parties : les composantes quasi-périodiques et les composantes de type bruit. La composante quasi-périodique peut être approchée sur la base de la période de hauteur de la trame précédente, tandis que la composante de type bruit peut être obtenue en générant un bruit aléatoire. Le rapport énergétique des deux peut également être dérivé de la relation proportionnelle de la trame précédente. . Par conséquent, la hauteur de la trame précédente doit d'abord être détectée, puis le signal vocal de la trame perdue est reconstruit de manière synchronisée, puis la corrélation est utilisée pour obtenir le gain de type bruit, et enfin un mélange est effectué pour reconstruire l'intégralité de la trame. signal résiduel.
3) En cas de perte de trame continue , chaque trame vocale compensée par PLC a les mêmes caractéristiques spectrales (même LPC) et fréquence de pitch. Afin de réduire la corrélation entre chaque trame de compensation, l'énergie sera réduite image par image.

       La compensation de perte de paquets d'OPUS est divisée en deux modes : CELT et SILK. Le codec OPUS a été conçu par l'Internet Engineering Task Force (IETF) pour une sortie vocale et audio interactive sur Internet, intégrant le SILK de Skype (incompatible avec l'algorithme SILK existant de Skype) et la technologie CELT de Xiph.Org. La compensation de perte de paquets en mode CELT est similaire à celle d'iLBC.

Le cadre du module d'encodeur SILK est le suivant :

4.4. Conception générale de NetEQ

        Le module NetEQ comprend principalement deux unités de traitement principales, MCU et DSP. Le module MCU (Micro Control Unit) est l'unité de contrôle du tampon de gigue. Puisque le tampon de gigue est utilisé pour stocker temporairement les données reçues, la fonction principale du MCU est d'insérer paquets de données et contrôler la sortie des paquets. La technologie d'annulation de gigue est incluse dans le module de contrôle MCU.

       La conception générale de NetEQ est la suivante :

       Il y a 240 emplacements dans le tampon de gigue. Chaque paquet de données original transmis depuis le réseau sera placé dans un emplacement approprié dans le tampon de gigue, qui stocke principalement l'horodatage, le numéro de séquence, le type de données, etc. tandis que le support de données réel est stocké dans une mémoire tampon. Lorsqu'un nouveau paquet de données arrive, de l'espace est alloué dans la mémoire tampon pour stocker sa porteuse, permettant ainsi d'éliminer la gigue.

       Le module DSP est principalement responsable du traitement algorithmique des paquets de données lus à partir du MCU, y compris le décodage, le traitement du signal, la sortie de données, etc. La technologie de compensation de perte de paquets est incluse dans le module DSP.

       Le tampon vocal stocke les données décodées et traitées par signal à lire, qui peuvent stocker des échantillons 565. curPosition représente le point de départ des données à lire et sampleLefe est le nombre d'échantillons à lire.

       La mémoire partagée, le tampon de décodage et le tampon d'algorithme sont tous des tampons de données temporaires. La mémoire partagée est utilisée pour stocker temporairement les données à décoder lues à partir du tampon de gigue, et stocke le nombre de pertes d'échantillons et les commandes de contrôle MCU ; le tampon de décodage est temporairement stocké. les données décodées ; le tampon de l'algorithme NetEQ stocke temporairement les données traitées par l'algorithme DSP et est utilisé pour compléter les nouvelles données dans le tampon vocal ; le tampon de lecture est le tampon de données du pilote de lecture et est utilisé pour lire les données de la voix tampon et jouer.

4.5. Mécanisme de commande NetEQ

       Le flux de traitement de NetEQ est contrôlé par diverses commandes, et la commande à utiliser est déterminée en fonction de l'état du paquet de données reçu :

1) La trame précédente et la trame actuelle sont reçues normalement : à ce moment, le paquet de données entre dans le flux de traitement normal et les données décodées sont sélectionnées comme expansion normale, accélérée ou préemptive en fonction du besoin d'élimination de la gigue.
2) Seule la trame actuelle perd des paquets ou expire : si la trame actuelle perd des paquets ou expire, entrez dans le traitement PLC pour reconstruire le LPC et les signaux résiduels, c'est-à-dire l'opération d'expansion. NetEQ attendra jusqu'à 100 ms pour les trames d'expiration et de perte de paquets. Si ce délai est dépassé, il extraira et lira directement l'image suivante.
3) Délais d'expiration continus de plusieurs trames ou pertes de paquets : si plusieurs trames consécutives sont perdues, plusieurs opérations PLC sont nécessaires. À ce stade, plus les données sont éloignées, plus il est difficile de reconstruire avec précision le paquet de compensation, donc l'énergie de compensation Le gain pour la perte continue de paquets est adopté et la réduction image par image est adoptée pour éviter d'introduire une plus grande distorsion.
4) L'image précédente est perdue et l'image actuelle est normale : L'image précédente est perdue, puis les données de l'image précédente jouée sont compensées par le PLC. Afin de maintenir la continuité vocale entre la trame compensée par l'automate et la trame normalement décodée, un lissage est requis en fonction de la corrélation entre les trames précédentes et suivantes. Dans ce cas, sélectionnez Normal ou Fusionner.

       De plus, le décodeur sera réinitialisé lorsque NetEQ reçoit un paquet pour la première fois ou après la réinitialisation de l'intégralité de NetEQ. D'un autre côté, lorsque NetEQ reçoit un paquet avec un délai de plus de 3,75 s, il ne sera pas rejeté en tant que paquet de délai d'attente, mais sera inséré dans le tampon de gigue et l'état du tampon sera réinitialisé.

4.6. Mécanisme de lecture NetEQ

       Le moteur vocal de WebRTC démarre deux threads lors de son exécution : un thread reçoit le paquet de données et l'insère dans le tampon de gigue ; l'autre thread lit des données de 10 ms dans le tampon vocal toutes les 10 ms pour la lecture.

       NetEQ combinera le stockage des données dans le tampon vocal et le stockage des données dans le tampon de gigue pour décider s'il faut lire les données du tampon de gigue :

1) Lorsque la commande de contrôle est Normal, Expansion, réinitialisation du décodeur ou réinitialisation de l'état du tampon de paquet, et que SampleLeft est supérieur ou égal à 10 ms, les données ne seront pas lues à partir du tampon de gigue et le DSP effectuera un fonctionnement normal.
2) Lorsque la commande de contrôle est normale, la réinitialisation du décodeur ou la réinitialisation de l'état du tampon de paquets et que SampleLeft est inférieur à 10 ms, après avoir lu les données du tampon de gigue, le DSP effectue un fonctionnement normal.
3) Lorsque la commande de contrôle est Expand et que SampleLeft est inférieur à 10 ms, les données ne sont pas lues à partir du tampon de gigue et le DSP effectue l'opération Expand.
4) Lorsque la commande de contrôle est Merge, après avoir lu les données du tampon de gigue, le DSP effectue l'opération de fusion.
5) Lorsque la commande de contrôle est Accélérer, lorsque SampleLeft est supérieur ou égal à 30 ms, les données ne sont pas lues à partir du tampon de gigue et le DSP effectue l'opération d'accélération ; lorsque SampleLeft est supérieur ou égal à 10 ms et inférieur à 30 ms. , les données sont lues à partir des différents tampons de gigue et le DSP effectue l'opération normale. ; Lorsque SampleLeft est inférieur à 10 ms, après avoir lu les données du tampon de gigue, le DSP effectue une opération d'accélération.
6) Lorsque la commande de contrôle est Preemptive Expand, lorsque SampleLeft est supérieur ou égal à 10 ms, le DSP ne lit pas les données du tampon de gigue et le DSP effectue l'opération d'expansion préemptive ; lorsque SampleLeft est inférieur à 10 ms, après la lecture. les données du tampon de gigue, le DSP effectue l'opération d'extension préemptive.

       Dans le traitement des commandes ci-dessus, en raison de la nécessité d'éviter un délai d'appel supplémentaire dans le tampon vocal, il n'est pas nécessaire de lire les données du tampon de gigue lorsque SampleLeft est supérieur ou égal à 10 ms. Les données ne seront lues que lorsqu'elles sont inférieures. supérieure ou égale à 10 ms. Maintenir une quantité appropriée de données dans le tampon vocal ; lorsque la commande de contrôle est Fusionner, les données doivent être lues à partir du tampon de gigue à tout moment pour assurer la continuité des données avant et après ; lorsque la commande de contrôle est Expand, une compensation de perte de paquets se produira. Une certaine quantité de données, il n'est donc pas nécessaire de lire les données du tampon de gigue, mais lorsque SampleLeft est supérieur ou égal à 10 ms, l'opération d'expansion n'est pas effectuée car il y a suffisamment de données dans le tampon vocal pour la lecture, et seule l’opération normale est effectuée.

4.7. Mécanisme de contrôle du MCU

       Dans l'algorithme de gigue de NetEQ, Blo (optBufferLevel) est utilisé pour calculer la gigue du réseau prédit en fonction de l'algorithme du facteur d'oubli, et BLc (bufferLevelFit) est utilisé pour calculer la gigue du tampon de gigue prédit en fonction de l'algorithme de moyenne adaptative. Le mécanisme de commande du MCU sélectionne la commande d'opération sur la base de la relation entre l'horodatage des données lues (playedOutTS, enregistré comme TSplay), l'horodatage du paquet de données à lire (availableTS, enregistré comme TSavail), Blo et Blc. La relation entre TSplay et TSavail est utilisée pour déterminer si les données réseau sont normales.

      Une comparaison de Blo et Blc est présentée ci-dessous :

La relation entre Blo et Blc dans la figure ci-dessus détermine la sélection des opérations d'accélération, d'expansion préemptive, d'expansion et de fusion.

       En bref, l'élimination de la gigue dans NetEQ s'effectue principalement en envoyant différentes commandes pour demander au DSP d'effectuer les opérations correspondantes en fonction de la relation entre le délai du réseau et le délai du tampon de gigue.

4.8. Traitement de l'algorithme DSP

       Le module DSP est le module de traitement du signal vocal de NetEQ et ses commandes de fonctionnement sont contrôlées par le MCU. La méthode de la fonction d'autocorrélation est utilisée dans WebRTC. Étant donné que le signal vocal est un signal non stationnaire, la fonction d'autocorrélation à court terme est utilisée pour le traitement du signal. La détection génétique utilisant la méthode de la fonction d'autocorrélation à court terme utilise principalement la caractéristique de la fonction d'autocorrélation à court terme pour être maximale à la période du signal et détermine la période de hauteur en comparant la similarité entre le signal d'origine et son signal décalé. la distance est égale à la période de hauteur, alors les deux signaux ont la plus grande similitude. Lorsque la fonction classique d'autocorrélation à court terme est utilisée pour la détection de hauteur, une fonction de fenêtre est utilisée. La fenêtre ne bouge pas et le signal vocal se déplace. La longueur de la fenêtre doit être au moins deux fois supérieure à la période de pitch. Plus la longueur de la fenêtre est longue, plus la période de pitch est précise, mais la quantité de calcul augmentera également en conséquence.

        Les opérations d'accélération et de décélération dans WebRTC sont basées sur l'algorithme WSOLA pour ajuster la durée de la voix, qui consiste à compresser ou étirer la voix sur la timeline sans changer la hauteur de la voix et assurer une bonne qualité sonore, communément appelée vitesse variable. ... Pas de mélodie. Les algorithmes d'ajustement de la durée de la parole sont divisés en deux catégories : le domaine temporel et la fréquence. Le domaine temporel est représenté par l'algorithme de similarité de forme d'onde dans la zone de chevauchement (WSOLA). Pour les signaux vocaux, une qualité vocale supérieure peut être obtenue et la complexité de calcul de la fréquence l’algorithme est plus petit. Pour l'audio avec des changements de fréquence drastiques, tels que les signaux musicaux, il est généralement difficile pour les algorithmes du domaine temporel d'obtenir une qualité vocale supérieure. Dans ce cas, des algorithmes de fréquence avec une grande complexité de calcul, tels que l'algorithme de sous-bande WSOLA, sont généralement utilisés. Depuis que GIPS a conçu NetEQ pour les services VoIP, les données sont principalement des signaux vocaux et les changements dans le domaine fréquentiel sont faibles, c'est pourquoi l'algorithme du domaine temporel WSOLA est utilisé.

       Le traitement DSP est la clé pour éliminer la gigue, compenser la perte de paquets et obtenir une faible latence et une meilleure qualité sonore pour la voix jouée. Les différentes opérations du DSP sont présentées ci-dessous :

1) Accélération : réduisez le nombre d'échantillons dans un paquet vocal. Les données réduites sont la période de hauteur obtenue sur la base de la corrélation des échantillons vocaux. Les données vocales de deux périodes d'échantillonnage sont lissées et converties en données d'une période de hauteur. L'opération d'accélération prend 30 ms par image. Elle ne sera accélérée que lorsque la corrélation est très forte (>0,9) ou que l'énergie du signal est très faible. L'algorithme est similaire au traitement de décélération. Comme indiqué ci-dessous:


2) Ralentissement : augmentez le nombre d'échantillons dans un paquet vocal. Les données ajoutées sont la période de hauteur obtenue sur la base de la corrélation des échantillons vocaux. Les données vocales de deux périodes d'échantillonnage sont lissées et insérées entre les deux périodes d'échantillonnage. L'opération de décélération prend 30 ms pour une image et les données à lire sont d'au moins 0,625 ms, sinon l'image précédente sera lue à plusieurs reprises ; lorsque le cache de données décodées est inférieur à 30 ms, il sera copié directement dans le cache de lecture. La période de pitch varie de 2,5 ms à 15 ms, elle peut donc être prolongée jusqu'à 15 ms. Comme indiqué ci-dessous:


3) Insertion de trame : l'algorithme de compensation de perte de paquets d'iLBC est utilisé, c'est-à-dire que le système de prédiction linéaire est reconstruit, le signal résiduel est reconstruit et l'énergie de compensation de trame est réduite image par image. Pendant l'opération d'insertion de trame, le tampon à lire doit être inférieur au temps de lecture de lecture (10 ms). Comme indiqué ci-dessous:


4) Fusion : Après la perte de paquet de la trame précédente, une opération d'insertion de trame sera effectuée. Lorsque les nouvelles données sont décodées, afin d'améliorer la cohérence des données vocales, les nouvelles données décodées et les données d'insertion de trame sont lissées. et l'énergie augmente progressivement. Les données intermédiaires générées par l'opération de fusion sont volumineuses et un maximum d'espace doit être réservé. Comme indiqué ci-dessous:

5) Normal : à ce moment, les nouvelles données décodées sont émises et lues normalement, mais si les données de la trame précédente sont des données de trame interpolées, la trame doit d'abord être interpolée puis lissée.

4.9. Test de simulation de l'algorithme DSP

       Compte tenu du fonctionnement de l'algorithme DSP ci-dessus, cet article a effectué des tests de simulation sur les signaux vocaux intermittents (Test1), les signaux vocaux continus (Test2) et les signaux musicaux (Test3) sous différents taux de perte de paquets, et a adopté la norme de mesure objective ITU-T P563. Pour l'estimation de la valeur MOS, LostData est utilisé pour remplir le silence lorsque des paquets sont perdus, Expand est utilisé pour insérer des trames lorsque des paquets sont perdus et Expand+Merge est utilisé pour insérer des trames avant la fusion lorsque des paquets sont perdus.

test

séquence

Cadre de sortie

durée

Taux de perte de paquets

MOS(P563)

Données perdues

Développer

Développer+Fusionner

essai 1

10 ms

10,00%

2.131

2.163

2.377

11,11%

2.237

3.085

3.073

12,50%

1.717

2.930

3.231

14,29%

2.159

3.138

3.348

16,67%

1.656

2.650

3,275

20,00%

2.364

2.161

2.333

25,00%

1.838

3.001

3.033

             
   
       Les signaux vocaux intermittents ne sont pas très sensibles aux changements du taux de perte de paquets, car la valeur MOS sera meilleure lorsque trop de voix n'est pas perdue pendant la perte de paquets. Les sons plosifs générés pendant la perte de paquets sont considérablement améliorés après compensation de la perte de paquets. Expérience subjective bonne .

test

séquence

Cadre de sortie

durée

Taux de perte de paquets

MOS(P563)

Données perdues

Développer

Développer+Fusionner

test2

10 ms

10,00%

2.656

2.872

3.598

11,11%

2.568

2.997

2.926

12,50%

2.634

3.162

3.038

14,29%

2.530

3.169

3.007

16,67%

2.290

2.903

2.980

20,00%

2.522

3.206

3.108

25,00%

1.952

2.943

2.952

                       
   
       Le signal vocal continu montre une tendance progressive à la baisse en fonction du taux de perte de paquets. L'effet de la compensation de perte de paquets est similaire à celui du Test1, les plosives sont considérablement améliorées et l'expérience subjective est bonne.

test

séquence

Cadre de sortie

durée

Taux de perte de paquets

MOS(P563)

Données perdues

Développer

Développer+Fusionner

Test3

10 ms

10,00%

2.428

2.658

2.855

11,11%

2.577

2.708

2.663

12,50%

3.420

2.478

2.739

14,29%

3.552

2.444

2.863

16,67%

3.251

2.421

2.792

20,00%

1.000

2.208

2.527

25,00%

1.099

1.993

2.474

                

        Le signal musical est "Castle in the Sky" de Joe Hisaishi. Le spectre entier change considérablement. Lorsque le taux de perte de paquets est faible, l'effet de compensation est bon. Plus le taux de perte de paquets est élevé, plus l'effet subjectif de la compensation est mauvais.

        Les opérations d'accélération, de décélération et normales ne sont pas comparées une par une. Les opérations d'accélération et de décélération sont très efficaces pour éliminer la gigue et maintenir l'intégrité du signal vocal lorsqu'il n'y a pas de perte de paquet.


       La valeur initiale de la simulation dynamique dans la figure ci-dessus est de 37 échantillons, c'est-à-dire qu'il y a 37 échantillons à lire initialement. La valeur MOS obtenue par la fusion après l'expansion diminue. Il y a deux raisons possibles : 1. Le nombre d'octets à lire avant l'expansion est faible, ce qui entraîne une faible qualité sonore des données d'image insérées ; 2. Plus il y a de données compensées par l'expansion avant La fusion affecte la valeur MOS après la fusion. Pour la qualité du son, idéalement, il devrait y avoir une correspondance biunivoque entre étendre et fusionner.


       La valeur fixe de la simulation fixe dans la figure ci-dessus est de 500 échantillons, c'est-à-dire que le nombre d'échantillons à lire reste à 500. À l'heure actuelle, la valeur MOS obtenue par Expand a été considérablement améliorée, après quoi l'opération de fusion est effectuée à chaque fois pour aider à augmenter la valeur MOS.


       La valeur initiale de la simulation dynamique dans la figure ci-dessus est 0, c'est-à-dire qu'il y a 0 échantillons à lire initialement. À ce stade, le nombre d'échantillons à lire avant l'expansion est réduit, ce qui entraîne une diminution de la valeur MOS des données de trame insérées dans l'expansion. Après cela, bien que l'expansion et la fusion ne correspondent pas un à un, il y a moins de données. à lire avant chaque fusion, il y aura donc moins de données à lisser. Aide à augmenter la valeur MOS.

       Plusieurs paramètres importants de la norme P563 sont : le rapport signal sur bruit (SNR), l'intervalle de silence et la période de hauteur moyenne, etc. Il n'y a pas de changement de phase de référence, mais le changement de phase a un grand impact subjectif sur l'audition, comme la discontinuité de phase. après l'insertion des données d'image, la forme d'onde peut produire des sons éclatants, ce qui affectera la qualité du son. Par conséquent, bien que la valeur MOS du P563 soit parfois estimée comme étant presque la même entre l'interpolation d'image et la fusion, l'expérience subjective de la fusion est nettement meilleure que celle d'interpolation de trame.

5. Description du fichier source NetEQ

mcu_dsp_common.h : instance NetEQ.

neteq_error_codes.h : codes d'erreur NetEQ.

neteq_statistics.h : statistiques de l'automate NetEQ.

dsp.h : fichier d'en-tête pour le fonctionnement de l'automate sur dsp.

accéléré.c : accélère les opérations pour réduire la latence. Le traitement est effectué lorsque la corrélation du signal est forte et l'énergie du signal est faible.

expand.c : génère des signaux audio et génère du bruit de fond.

preemptive_expand.c : ralentissez pour augmenter le délai.

normal.c : lecture normale.

merge.c : lisser la nouvelle trame de données et la trame de données précédente étendue.

bgn_update.c : estimation et mise à jour du bruit de fond.

cng_internal.c : Génère un bruit de fond confortable.

dsp.c : fonction d'initialisation et définition de table constante du fonctionnement dsp.

recin.c : ajoutez des paquets RTP.

recout.c : décodage et sortie PCM.

dsp_helpfunctions.h

dsp_helpfunctions.c : deux fonctions dsp, la fréquence est un multiple de 8k et le sous-échantillonnage à 4k.

min_distortion.c : Calcul de la distorsion minimale.

correlator.c : Calculer la corrélation des signaux.

Peak_detection.c : Détection et positionnement des pics de corrélation.

mix_voice_unvoice.c : mélanger

mute_signal.c : muet (affaiblir)

unmute_signal.c : Désactiver la sourdine (crescendo)

random_vector.c : vecteur aléatoire.

codec_db_defines.h

codec_db.c : gère la base de données de la bibliothèque d'algorithmes.

dtmf_buffer.h

dtmf_buffer.c : messages DTMF et décodage.

dtmf_tonegen.h

dtmf_tonegen.c : génère un signal DTMF.

mcu.h : opération côté MCU.

mcu_address_init.c : initialisation de l'adresse MCU.

mcu_dsp_common.c : Communication entre MCU et DSP.

mcu_reset.c : réinitialisez les données côté MCU.

set_fs.c : taux d'échantillonnage DTMF.

signal_mcu.c : informe le MCU que les données sont disponibles et demande une commande PLC.

split_and_insert.c : diviser l'en-tête RTP et l'ajouter au tampon du paquet.

rtcp.h

rtcp.c : statistiques RTCP.

rtp.h

rtp.c : fonction RTP.

automode.h

automode.c : stratégie de mise en cache dynamique.

paquet_buffer.h

packet_buffer.c : Gestion du cache de paquets.

tampon_stats.h

bufstats_decision.c : donne des commandes PLC basées sur la gigue du tampon.

webrtc_neteq.h

webrtc_neteq_help_macros.h : définition de macro NetEQ

webrtc_neteq.c:API NetEQ。

webrtc_neteq_internal.h : fonction interne de NetEQ

webrtc_neteq_unittest.cc : test unitaire NetEQ.

6. Documents de référence

《GIPS NetEQ》,Solutions IP mondiales

"Recherche sur la technologie NetEQ dans le moteur vocal WebRTC", Wu Jiangrui

"Recherche sur la technologie de mise en cache de paquets dans le moteur vocal WebRTC", Xiao Hongliang

"Recherche et développement de la technologie de traitement des pertes de paquets VoIP", Li Ruwei, Bao Changchun

《ITU-T P.563 Méthode asymétrique pour l'évaluation objective de la qualité de la parole dans les applications de téléphonie à bande étroite》,国际电联ITU(Union internationale des télécommunications)

http://en.wikipedia.org/wiki/Opus_(codec)

Je suppose que tu aimes

Origine blog.csdn.net/chenlycly/article/details/133922114
conseillé
Classement