O melhor sistema neural de ocultação de perda de pacotes no Audio Deep PLC Challenge do INTERSPEECH 2022, da Microsoft, obteve PLCMOS de 4,28 em uma escala de 1 a 5, contra 2,90 para a simples inserção de silêncio e 4,51 para o original limpo (Microsoft, artigo do INTERSPEECH 2022 Audio Deep PLC Challenge). Dois anos depois, quando o mesmo desafio passou para áudio de banda completa e rajadas de perda de até 3 segundos, os vencedores compartilhados só conseguiram elevar a qualidade geral de 2,37 para 3,49, ainda bem abaixo dos 4,01 da fala limpa (Microsoft, artigo do ICASSP 2024 Audio Deep PLC Challenge). O problema não é raro: o Google informou que 99% das chamadas do Duo precisavam lidar com perda de pacotes, jitter ou atraso, e que uma em cada dez chamadas perdia mais de 8% do seu áudio (Google Research, blog WaveNetEQ 2020). A ocultação é a camada silenciosa por baixo das tendências de mercado em nossas estatísticas de VoIP e UCaaS e complementa o quadro do lado das operadoras em nossas estatísticas de qualidade de voz celular (MOS). Reunimos dados de artigos dos desafios da Microsoft Research, do IETF e da ITU-T, do W3C, do Google Research, dos desenvolvedores do Opus na Xiph.Org, da Meta Engineering, da documentação da Microsoft Learn e da Twilio, e de estudos revisados por pares sobre PLC listados na metodologia.
TL;DR
- 99% das chamadas do Google Duo precisavam lidar com perda de pacotes, jitter ou atraso; 10% perdiam mais de 8% do áudio total (Google Research, blog WaveNetEQ 2020).
- O Microsoft Teams marca um fluxo de áudio como Poor quando a perda média de pacotes passa de 0,1, ou seja, 10% (Microsoft Learn, CQD Stream Classification 2026).
- O G.711 com a ocultação de seu Apêndice I tem fator de robustez à perda de pacotes de 25,1, contra 4,3 sem ocultação (ITU-T G.113, 09/2024).
- Vencedor do PLC neural: PLCMOS 4,28 contra 2,90 do preenchimento com zeros e 4,51 da fala limpa (Microsoft, artigo do INTERSPEECH 2022 Deep PLC Challenge).
- O PLC híbrido da equipe do Opus ficou em primeiro em acurácia de palavras (0,882) e em segundo no geral no desafio de 2022 (Valin et al., Real-Time PLC with Mixed Generative and Predictive Model 2022).
- Com rajadas de até 3 segundos, 2 de 8 sistemas elegíveis pontuaram abaixo do áudio com perdas sem processamento na qualidade geral P.804 (Microsoft, artigo do ICASSP 2024 Deep PLC Challenge).
- O PLCMOS alcança correlação de Pearson por modelo de cerca de 0,97 com as notas humanas; em dados alinhados à referência, o PESQ chega a 0,52 (Diener et al., artigo do PLCMOS 2023).
- O FEC em banda LBRR do Opus cobre 1 quadro a cerca de 2/3 da taxa de bits regular; o DRED cobre até 1 segundo a cerca de 1/50 (IETF draft-ietf-mlcodec-opus-dred-07, agosto de 2026).
- O Opus precisa de pelo menos 19 kbps para codificar FEC em banda com 10% de perda de pacotes, segundo a comparação própria da Meta com o MLow (Meta Engineering, MLow 2024).
- O Opus 1.6 reduziu seus modelos DRED cerca de 3 vezes, para 600 kB dos 1.800 kB anteriores (Xiph.Org, demonstração do Opus 1.6, dezembro de 2025).
1. Quanto Áudio Se Perde e Onde as Plataformas Traçam o Limite
Um pacote, neste contexto, é uma pequena fatia de áudio (frequentemente de 20 ms) enviada pela rede. Quando ele chega tarde demais ou não chega, o receptor tem duas opções: reproduzir silêncio ou ocultar a lacuna sintetizando algo que soe como a fala ausente. Os dados do próprio Google mostraram que 99% das chamadas do Duo precisavam lidar com perda de pacotes, jitter ou atraso (Google Research, Improving Audio Quality in Duo with WaveNetEQ 2020). A ocultação, portanto, não é um caso de borda: ela roda em quase toda chamada.
As plataformas divergem sobre o ponto em que a perda deixa de ser ruído de fundo e vira problema. O Microsoft Teams traça sua linha Poor em 10% de perda média, a Twilio em 5%, e a Microsoft avisa explicitamente que o rótulo Poor não significa que os usuários realmente perceberam um problema de qualidade, porque sua pilha de mídia corrige as perdas (Microsoft Learn, Stream Classification in CQD 2026). Essa ressalva é todo o argumento a favor de uma ocultação melhor: quanto mais o PLC rende, mais alto a plataforma pode fixar seu limite de alarme.
| Métrica | Valor | Fonte |
|---|---|---|
| Parcela das chamadas do Google Duo que precisam lidar com perda de pacotes, jitter ou atraso | 99% | Google Research, blog WaveNetEQ 2020 |
| Parcela das chamadas do Duo que perdem mais de 3% da duração total do áudio | 20% | Google Research, blog WaveNetEQ 2020 |
| Parcela das chamadas do Duo que perdem mais de 8% da duração total do áudio | 10% | Google Research, blog WaveNetEQ 2020 |
| Taxa média de perda de pacotes acima da qual o Teams classifica um fluxo de áudio como Poor | Acima de 0,1 (10%), aplicada apenas a fluxos com mais de 500 pacotes | Microsoft Learn, CQD Stream Classification 2026 |
| Nível de perda de pacotes que aciona a tag de chamada high_packet_loss da Twilio | Acima de 5% | Twilio Voice Insights, Details: Call Tags |
| MOS estimado abaixo do qual a Twilio marca uma chamada de navegador ou SDK móvel como low_mos | Abaixo de 3,5 | Twilio Voice Insights, Details: Call Tags |
| Taxa média de perda no conjunto de teste do Deep PLC Challenge usado para avaliar o Opus DRED | 18,4%, com rajadas de até um segundo | Valin et al., artigo do DRED (arXiv 2212.04453 v3, 2024) |
Dados disponíveis mais recentes: Google Research, 2020. Nenhuma grande plataforma publicou uma distribuição de perdas por chamada mais nova. O Teams informa por fluxo o indicador relacionado “Ratio Concealed Samples Avg”, em que 0,1 significa que 10% dos quadros de áudio continham amostras ocultadas (Microsoft Learn, CQD dimensions and measures 2026), mas a Microsoft não publica valores de toda a base de chamadas. Os equivalentes do lado do navegador, concealedSamples e concealmentEvents, estão definidos na API de estatísticas do W3C WebRTC (rascunho de Recomendação Candidata, 25 de setembro de 2025).
2. Ocultação Clássica de Codecs sob o Modelo E da ITU-T
Antes das redes neurais, ocultar significava repetir ou extrapolar o último período de pitch bom. O modelo de planejamento da ITU-T (o modelo E) avalia o quanto um codec sobrevive às perdas por meio do fator de robustez à perda de pacotes, Bpl: um número simples em que valores maiores indicam que a qualidade decai mais devagar à medida que os pacotes somem. O G.711 com o algoritmo de ocultação de seu Apêndice I tem Bpl de 25,1, quase seis vezes os 4,3 do G.711 sem ocultação (ITU-T G.113 09/2024, Tabela I.4).
O que essa diferença significa na prática fica mais claro com números. Usando a Equação 7-29 da ITU-T G.107 (06/2015), Ie-eff = Ie + (95 - Ie) x Ppl / (Ppl/BurstR + Bpl), o G.711 (Ie = 0) com 5% de perda aleatória (BurstR = 1) resulta em 95 x 5 / (5 + 4,3) = 51,1 pontos de degradação sem ocultação e 95 x 5 / (5 + 25,1) = 15,8 com ela. Subtraídos da nota padrão de R = 93,2, isso dá R 42,1 contra R 77,4, que a fórmula do Anexo B da G.107 converte em um MOS estimado de cerca de 2,2 contra 3,9 (cálculo nosso; todos os demais parâmetros do modelo E mantidos no valor padrão). Só a ocultação já leva uma chamada com 5% de perda de ruim a aceitável.
| Métrica | Valor | Fonte |
|---|---|---|
| G.711 (64 kbit/s, pacotes de 10 ms) sem ocultação: fator de robustez à perda de pacotes Bpl sob perda aleatória | 4,3 | ITU-T G.113 (09/2024), Tabela I.4 |
| G.711 com o algoritmo de ocultação do Apêndice I da G.711: Bpl sob perda aleatória | 25,1 | ITU-T G.113 (09/2024), Tabela I.4 |
| G.729 Anexo A com detecção de atividade de voz (8 kbit/s, pacotes de 20 ms, ocultação nativa): Ie e Bpl | Ie 11, Bpl 19,0 | ITU-T G.113 (09/2024), Tabela I.4 |
| G.711 com pacotes de 20 ms, 8 pacotes perdidos em uma única rajada com 2% de perda (razão de rajada 7,84): degradação efetiva Ie-eff | 10 | ITU-T G.113 (09/2024), Tabela I.6 |
| G.722 a 64 kbit/s com a ocultação de alta qualidade do Apêndice III da G.722: Bpl em banda larga (ouvindo com os dois ouvidos) | 7,1 | ITU-T G.113 (09/2024), Apêndice IV |
| EVS em modo super-banda larga a 24,4 kbit/s: Bpl em banda completa | 11,4 | ITU-T G.113 (09/2024), Apêndice V |
| Fator de avaliação R do modelo E quando todos os parâmetros estão no valor padrão | 93,2 | ITU-T G.107 (06/2015) |
Contexto: os valores de Bpl só são comparáveis dentro da mesma escala (banda estreita, banda larga ou banda completa). A G.113 não lista nenhum valor para o Opus, de modo que o áudio WebRTC baseado em Opus precisa ser avaliado com outras ferramentas (veja a seção 5).
3. Ocultação Neural contra Silêncio: o Deep PLC Challenge de 2022
O desafio do INTERSPEECH 2022 avaliou o PLC neural em padrões reais de perda, usando traços gravados em chamadas do Microsoft Teams e uma regra rígida de tempo real: latência algorítmica total de no máximo 20 ms. Seu resultado principal é o tamanho da distância entre o vencedor e não fazer nada. O sistema vencedor obteve -0,55 na escala de comparação (CMOS, em que 0 significa indistinguível do original limpo), contra -1,23 do preenchimento com zeros (Microsoft, artigo do INTERSPEECH 2022 Audio Deep PLC Challenge).
A inteligibilidade conta uma história mais modesta. A acurácia de palavras, medida como 1 menos a taxa de erro de palavras de um reconhecedor de fala, subiu apenas de 0,86 com silêncio para 0,88 com o vencedor, contra 0,97 da fala limpa. Os ouvintes percebem a ocultação como uma grande melhora, mas o reconhecedor ainda errou 12% das palavras com o sistema vencedor, contra 3% na fala limpa, um padrão que vale ter em mente ao lado de nossas estatísticas de taxa de erro de palavras no reconhecimento de fala.
| Métrica | Valor | Fonte |
|---|---|---|
| Fala limpa de referência: PLCMOS (1 a 5) e acurácia de palavras | 4,51 e 0,97 | Microsoft, artigo do INTERSPEECH 2022 Deep PLC Challenge |
| Linha de base com preenchimento com zeros (silêncio no lugar dos pacotes perdidos): PLCMOS, CMOS e acurácia de palavras | 2,90, -1,23 e 0,86 | Microsoft, artigo do INTERSPEECH 2022 Deep PLC Challenge |
| Sistema vencedor (equipe nº 12, U-Net no domínio do tempo, cerca de 2,36 M de parâmetros): PLCMOS, CMOS e acurácia de palavras | 4,28, -0,55 e 0,88 | Microsoft, artigo do INTERSPEECH 2022 Deep PLC Challenge |
| Sistema elegível de pior classificação (equipe nº 6) contra a linha de base com preenchimento com zeros: CMOS | -1,31 contra -1,23 | Microsoft, artigo do INTERSPEECH 2022 Deep PLC Challenge |
| PLC híbrido generativo e preditivo da equipe do Opus: acurácia de palavras e posição nessa métrica | 0,882, primeiro; segundo em CMOS e no geral | Valin et al., Real-Time PLC with Mixed Generative and Predictive Model 2022 |
| Mesmo sistema: computação por 10 ms de fala em uma CPU de notebook (Intel i7-10810U) | 1,3 a 1,4 ms, cerca de 13% a 14% de um núcleo | Valin et al. 2022 |
Nota sobre o valor atípico: um sistema classificado pontuou abaixo da linha de base de silêncio em CMOS, um lembrete de que um gerador mal ajustado pode soar pior que uma lacuna. O conjunto cego foi ponderado para rajadas curtas: 504 de seus 966 trechos tinham rajada máxima de até 120 ms. Os números do sistema híbrido vêm de Valin et al., cuja ocultação foi depois incluída no Opus 1.5 (veja a seção 7).
4. Rajadas Longas: Onde a Ocultação Ainda Falha (ICASSP 2024)
A edição de 2024 tornou a tarefa deliberadamente mais difícil: áudio de banda completa a 48 kHz, avaliado com o método multidimensional ITU-T P.804 (Microsoft Research, ICASSP 2024 Audio Deep PLC Challenge), e rajadas de perda de até 3 segundos. Mesmo o melhor sistema fechou apenas cerca de dois terços da distância entre o áudio com perdas e o áudio limpo: a qualidade geral subiu de 2,37 para 3,49, contra 4,01 da fala limpa ((3,49 - 2,37) / (4,01 - 2,37) = 68%) (Microsoft, artigo do ICASSP 2024 Audio Deep PLC Challenge).
A coluna mais reveladora é a de descontinuidade, a nota do P.804 para quebras e falhas audíveis (valores maiores indicam áudio mais fluido). Ela subiu de 2,47 para 3,90 no melhor sistema, um salto maior que o de qualquer outra dimensão. A ocultação conserta primeiro os buracos que os ouvintes notam, enquanto a fala sintetizada ainda custa naturalidade. A acurácia de palavras mostra a mesma troca: um dos co-vencedores reconheceu 0,81 das palavras, um pouco abaixo dos 0,83 do áudio com perdas intocado, indício de que a fala inventada pode confundir um reconhecedor mais do que o silêncio.
| Métrica | Valor | Fonte |
|---|---|---|
| Qualidade geral P.804 (1 a 5): fala limpa contra áudio com perdas sem processamento contra os vencedores compartilhados (1024K e NWPU & ByteAudio) | 4,01 contra 2,37 contra 3,49 e 3,44 | Microsoft, artigo do ICASSP 2024 Deep PLC Challenge |
| Nota de descontinuidade P.804: limpo contra com perdas contra o melhor sistema (1024K) | 4,55 contra 2,47 contra 3,90 | Microsoft, artigo do ICASSP 2024 Deep PLC Challenge |
| Acurácia de palavras: limpo contra com perdas contra 1024K contra NWPU & ByteAudio | 0,98 contra 0,83 contra 0,81 contra 0,84 | Microsoft, artigo do ICASSP 2024 Deep PLC Challenge |
| Sistemas elegíveis com nota abaixo do áudio com perdas sem processamento na qualidade geral P.804 | 2 de 8 (2,11 e 2,17) | Microsoft, artigo do ICASSP 2024 Deep PLC Challenge |
| Largura de banda do áudio e método do teste de audição da edição de 2024 | Banda completa, 48.000 Hz; avaliação multidimensional ITU-T P.804 mais taxa de erro de palavras | Microsoft Research, página do ICASSP 2024 Deep PLC Challenge |
Contexto: um nono sistema obteve 2,91 no geral, mas não cumpriu o limite de latência e foi listado como não concluído. Os organizadores observam que os sistemas da época de 2022 “podem não conseguir um bom desempenho em sequências mais longas de perdas”, que é exatamente onde a codificação de redundância (seção 6) assume.
5. Medindo a Ocultação: Por Que as Métricas Genéricas de Qualidade Não a Captam
Os erros de ocultação são curtos, intermitentes e muitas vezes plausíveis, exatamente o que as métricas de qualidade de uso geral não foram feitas para captar. Em dados alinhados à referência, o PESQ alcançou correlação de Pearson por modelo de apenas 0,52 com as notas humanas de sistemas de PLC, e o STOI só 0,21, enquanto o PLCMOS alcançou 0,98 (Diener et al., artigo do PLCMOS, Microsoft, Interspeech 2023). Uma métrica que classifica os sistemas de forma errada pode levar uma área inteira de pesquisa na direção errada.
O PLCMOS funciona sem referência limpa, o que importa em chamadas reais, nas quais o áudio original nunca está disponível no receptor. Sua fraqueza é a precisão por arquivo: 0,85 por trecho contra 0,97 por sistema, de modo que ele classifica algoritmos muito melhor do que avalia uma única chamada. A mesma tensão atravessa a avaliação de fala sintética, tratada em nossas estatísticas de MOS de naturalidade da fala sintética.
| Métrica | Valor | Fonte |
|---|---|---|
| PLCMOS contra notas humanas: correlação de Pearson por modelo e correlação de postos | Cerca de 0,97 e cerca de 0,95 | Diener et al., artigo do PLCMOS 2023 |
| DNSMOS (métrica geral de supressão de ruído): correlação de Pearson por arquivo contra por modelo | 0,52 contra 0,85 | Diener et al., artigo do PLCMOS 2023 |
| PESQ contra PLCMOS em dados alinhados à referência: correlação de Pearson por modelo | 0,52 contra 0,98 | Diener et al., artigo do PLCMOS 2023 |
| STOI (métrica de inteligibilidade): correlação de Pearson por modelo | 0,21 | Diener et al., artigo do PLCMOS 2023 |
| Votos humanos no principal conjunto de treinamento do PLCMOS (LibriSpeech Basic) | 333.740 | Diener et al., artigo do PLCMOS 2023 |
| Arquivos de teste na bateria de testes de audição de codecs de aprendizado de máquina do IETF | 100 de fala limpa, 90 com ruído ou reverberação, 20 com vozes sobrepostas | IETF draft-ietf-mlcodec-test-battery-00, junho de 2026 |
Contexto: as notas obtidas por crowdsourcing se correlacionaram com as notas de especialistas em cerca de 0,83 de PCC (IC de 95%: [0,78; 0,87]) no pré-estudo de rotulagem do PLCMOS. O rascunho da bateria de testes do IETF ainda lista seus cenários de perda de pacotes como “Details TBD”, portanto ainda não existe um teste de perda padronizado para codecs neurais.
6. Codificação de Redundância: Pagar Bits para Evitar a Ocultação
A ocultação adivinha; a redundância envia um reserva. A correção de erros direta (FEC) consiste em anexar uma cópia de qualidade inferior do áudio anterior aos pacotes seguintes, de modo que um pacote perdido possa ser reconstruído em vez de inventado. A contrapartida é a largura de banda. O FEC em banda clássico do Opus (LBRR) cobre apenas um quadro a cerca de 2/3 da taxa de bits regular, enquanto o Deep REDundancy (DRED) transporta até um segundo ou mais a cerca de 1/50 da taxa de bits regular (IETF draft-ietf-mlcodec-opus-dred-07, agosto de 2026).
A abordagem RED, mais antiga, mostra a escala do efeito. Em um teste no Chrome com 20% de perda, enviar um quadro anterior em cada pacote reduziu a parcela de áudio ocultado de 18% para 4%, e dois quadros anteriores a reduziram para 0,7% (webrtcHacks, RED: Improving Audio Quality with Redundancy 2020). O custo: o áudio subiu de cerca de 30 kbps para 60 kbps com uma cópia e 90 kbps com duas. O DRED existe para obter proteção semelhante sem dobrar a taxa de bits.
| Métrica | Valor | Fonte |
|---|---|---|
| FEC em banda LBRR do Opus: profundidade da redundância e custo em taxa de bits | 1 quadro; cerca de 2/3 da taxa de bits regular do Opus | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Opus DRED: profundidade da redundância e custo em taxa de bits | Até um segundo ou mais por pacote; cerca de 1/50 da taxa de bits regular | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Avaliação do DRED: redundância transportada por pacote e número de vezes que cada quadro é enviado | 1,04 segundo; 52 cópias | Valin et al., artigo do DRED (arXiv 2212.04453 v3, 2024) |
| Taxa de bits da condição de teste LBRR na avaliação do DRED (24 kb/s de base mais LBRR) | 40 kb/s no total, com o LBRR em média de cerca de 16 kb/s | Valin et al., artigo do DRED 2024 |
| Parcela de áudio ocultado com 20% de perda no Chrome: sem RED contra um quadro anterior contra dois quadros anteriores | 18% contra 4% contra 0,7% | webrtcHacks, teste de RED de Hancke 2020 |
| Parcela de áudio ocultado com 60% de perda aleatória: sem RED contra um contra dois quadros anteriores | 60% contra 32% contra 18% | webrtcHacks, teste de RED de Hancke 2020 |
| Taxa de bits mínima do Opus para codificar FEC em banda com 10% de perda de pacotes | 19 kbps (comparação do próprio fornecedor) | Meta Engineering, blog do codec MLow 2024 |
| Taxa de bits das amostras MLow da Meta com 30% de perda de pacotes no receptor | 14 kbps (alegação do próprio fornecedor) | Meta Engineering, blog do codec MLow 2024 |
Contexto: os números do webrtcHacks vêm de um teste de laboratório de um único autor, de 2020 (a medição pública mais recente disponível do RED no Chrome). Os números da Meta vêm de seu próprio anúncio do MLow e não foram replicados de forma independente. Todas as diferenças do DRED no teste de audição P.808 do artigo (966 locuções, 10 ouvintes cada) foram relatadas como significativas a p < 0,05.
7. Colocando a Ocultação em Produção: Computação, Tamanho e Padrões
Um modelo de ocultação só importa se couber no celular mais barato da chamada. O Deep PLC do Opus 1.5 custa cerca de 1% de um núcleo de CPU de notebook em altas taxas de perda e acrescenta cerca de 1 MB à biblioteca (Xiph.Org, demonstração do Opus 1.5, março de 2024, números dos próprios desenvolvedores). A proposta do desafio de 2022 da mesma equipe precisava de 13% a 14% de um núcleo (seção 3), embora as duas cifras tenham sido medidas de formas diferentes e não sejam uma comparação rigorosa de igual para igual.
A camada de padrões, por outro lado, quase não se move. As regras de áudio do WebRTC (RFC 7874, 2016) tornam obrigatórios o Opus e o G.711, mas não estabelecem nenhum requisito de ocultação ou de FEC, deixando a qualidade sob perda inteiramente a cargo de cada implementação. O Opus 1.6 continuou reduzindo os modelos: suas redes DRED são cerca de 3 vezes menores que as do 1.5 (Xiph.Org, demonstração do Opus 1.6, dezembro de 2025).
| Métrica | Valor | Fonte |
|---|---|---|
| Deep PLC do Opus 1.5: tamanho adicionado à biblioteca e custo de CPU | Cerca de 1 MB; cerca de 1% de um núcleo de notebook com alta perda; exige complexidade do decodificador 5 ou superior | Xiph.Org, demonstração do Opus 1.5 2024 (números dos próprios desenvolvedores) |
| DRED do Opus 1.5: tamanho adicionado à biblioteca, custo em tempo de execução e sobrecarga de taxa de bits | Cerca de 2 MB; cerca de 1%; cerca de 12 a 32 kb/s | Xiph.Org, demonstração do Opus 1.5 2024 (números dos próprios desenvolvedores) |
| Vocoder neural FARGAN usado para sintetizar a fala ocultada e redundante: complexidade | 600 MFLOPS, 1/5 do LPCNet | Xiph.Org, demonstração do Opus 1.5 2024 |
| Taxas de perda nos testes WebRTC do Opus 1.5 (PLCMOS v2) | 0% a 90% em passos de 10%; o DRED teria mantido a qualidade com 90% de perda | Xiph.Org, demonstração do Opus 1.5 2024 (alegação dos próprios desenvolvedores) |
| Tamanho do modelo DRED do Opus 1.6 contra o do Opus 1.5 | 600 kB contra 1.800 kB | Xiph.Org, demonstração do Opus 1.6, dezembro de 2025 |
| Tamanhos de quadro do Opus, duração do pacote e faixa de taxa de bits | Quadros de 2,5 a 60 ms; pacotes de até 120 ms; 6 a 510 kbit/s | IETF RFC 6716 (2012) |
| Atraso algorítmico do Opus | 5 ms a 65,2 ms | IETF RFC 6716 (2012) |
| Codecs que os endpoints WebRTC devem suportar | Opus e G.711 (PCMA e PCMU); sem requisito de PLC ou FEC | IETF RFC 7874 (2016) |
Contexto: a RFC 6716 e a RFC 7874 têm mais de três anos, mas continuam sendo os padrões vigentes (RFC 6716, RFC 7874). O rascunho do DRED, se aprovado, atualizaria a RFC 6716 com uma camada neural de redundância.
Resumo: Ocultação de Perda de Pacotes de Áudio WebRTC em Números
| Métrica | Valor | Fonte |
|---|---|---|
| Chamadas do Google Duo que precisam lidar com perda de pacotes, jitter ou atraso | 99% | Google Research, blog WaveNetEQ 2020 |
| Chamadas do Duo que perdem mais de 8% do áudio | 10% | Google Research, blog WaveNetEQ 2020 |
| Limite Poor do Teams para a perda média de pacotes de áudio | Acima de 0,1 (10%) | Microsoft Learn, CQD Stream Classification 2026 |
| Limite da tag high_packet_loss da Twilio | Acima de 5% | Twilio Voice Insights, Details: Call Tags |
| Fator de robustez Bpl do G.711: sem ocultação contra ocultação do Apêndice I | 4,3 contra 25,1 | ITU-T G.113 (09/2024) |
| G.729 Anexo A com detecção de atividade de voz: Bpl | 19,0 | ITU-T G.113 (09/2024) |
| PLCMOS do desafio de 2022: preenchimento com zeros contra vencedor contra limpo | 2,90 contra 4,28 contra 4,51 | Microsoft, artigo do INTERSPEECH 2022 Deep PLC Challenge |
| Acurácia de palavras do desafio de 2022: preenchimento com zeros contra vencedor contra limpo | 0,86 contra 0,88 contra 0,97 | Microsoft, artigo do INTERSPEECH 2022 Deep PLC Challenge |
| Computação do PLC híbrido da equipe do Opus por 10 ms de fala | 1,3 a 1,4 ms (13% a 14% de um núcleo) | Valin et al. 2022 |
| Qualidade geral P.804 do desafio de 2024: com perdas contra melhor contra limpo | 2,37 contra 3,49 contra 4,01 | Microsoft, artigo do ICASSP 2024 Deep PLC Challenge |
| Sistemas do desafio de 2024 com nota abaixo do áudio com perdas sem processamento | 2 de 8 | Microsoft, artigo do ICASSP 2024 Deep PLC Challenge |
| Correlação de Pearson por modelo do PLCMOS com as notas humanas | Cerca de 0,97 | Diener et al., artigo do PLCMOS 2023 |
| Correlação de Pearson por modelo de PESQ contra STOI em sistemas de PLC | 0,52 contra 0,21 | Diener et al., artigo do PLCMOS 2023 |
| Profundidade de redundância do LBRR contra a do DRED | 1 quadro contra até um segundo ou mais | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Taxa de bits de redundância do DRED em relação ao Opus regular | Cerca de 1/50 | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Áudio ocultado com 20% de perda: sem RED contra RED de dois quadros | 18% contra 0,7% | webrtcHacks, teste de RED de Hancke 2020 |
| Taxa de bits mínima de FEC em banda do Opus com 10% de perda | 19 kbps (comparação do próprio fornecedor) | Meta Engineering, blog do codec MLow 2024 |
| Custo de CPU do Deep PLC do Opus 1.5 | Cerca de 1% de um núcleo de notebook | Xiph.Org, demonstração do Opus 1.5 2024 |
| Tamanho do modelo DRED do Opus 1.6 contra o do 1.5 | 600 kB contra 1.800 kB | Xiph.Org, demonstração do Opus 1.6 2025 |
Metodologia e Fontes
- Microsoft Research, artigo do INTERSPEECH 2022 Audio Deep Packet Loss Concealment Challenge (Diener et al., 2022): arxiv.org/pdf/2204.05222
- Microsoft Research, artigo do ICASSP 2024 Audio Deep Packet Loss Concealment Challenge (2024): arxiv.org/html/2402.16927v1
- Microsoft Research, página do programa do ICASSP 2024 Audio Deep PLC Challenge: microsoft.com
- Diener et al., PLCMOS: a data-driven non-intrusive metric for the evaluation of packet loss concealment algorithms (Interspeech 2023): arxiv.org/pdf/2305.15127
- Valin et al., Real-Time Packet Loss Concealment With Mixed Generative and Predictive Model (2022): arxiv.org/pdf/2205.05785
- Valin et al., DRED: Deep REDundancy Coding of Speech Using a Rate-Distortion-Optimized Variational Autoencoder (arXiv v3, 2024): arxiv.org/pdf/2212.04453
- IETF, Deep Audio Redundancy (DRED) Extension for the Opus Codec, draft-ietf-mlcodec-opus-dred-07 (agosto de 2026): ietf.org
- IETF, ML codec listening test battery, draft-ietf-mlcodec-test-battery-00 (junho de 2026): ietf.org
- IETF RFC 6716, Definition of the Opus Audio Codec (2012): rfc-editor.org
- IETF RFC 7874, WebRTC Audio Codec and Processing Requirements (2016): rfc-editor.org
- W3C, Identifiers for WebRTC’s Statistics API (rascunho de Recomendação Candidata, 25 de setembro de 2025): w3.org
- ITU-T G.113 (09/2024), Transmission impairments due to speech processing: itu.int
- ITU-T G.107 (06/2015), The E-model: itu.int
- Google Research, Improving Audio Quality in Duo with WaveNetEQ (abril de 2020): research.google
- Microsoft Learn, Stream Classification in Call Quality Dashboard (atualizado em junho de 2026): learn.microsoft.com
- Microsoft Learn, Dimensions and measures available in Call Quality Dashboard (atualizado em julho de 2026): learn.microsoft.com
- Twilio, Voice Insights Details: Call Tags: twilio.com
- Meta Engineering, MLow: Meta’s low bitrate audio codec (junho de 2024): engineering.fb.com
- Xiph.Org, demonstração do Opus 1.5 (março de 2024) e demonstração do Opus 1.6 (dezembro de 2025): opus-codec.org/demo/opus-1.5, opus-codec.org/demo/opus-1.6
- webrtcHacks, RED: Improving Audio Quality with Redundancy (Philipp Hancke, agosto de 2020): webrtchacks.com
- Nota sobre os dados: a única distribuição de perdas por chamada de uma grande plataforma é a cifra do Duo do Google, de 2020, e as medições de ocultação com RED são um teste de 2020 de um único autor, por isso ambas são sinalizadas como os dados disponíveis mais recentes. O exemplo do modelo E na seção 2 é um cálculo nosso, feito a partir da Equação 7-29 e do Anexo B da ITU-T G.107 com os valores de Bpl da G.113, mantendo todos os demais parâmetros no valor padrão; é uma estimativa, não uma medição. As pontuações dos desafios não são comparáveis entre as edições: a de 2022 usou áudio de banda larga, PLCMOS e CMOS com rajadas de até 1 segundo, enquanto a de 2024 usou áudio de banda completa, P.804 e rajadas de até 3 segundos. No artigo de 2022, o PLCMOS se correlacionou com o CMOS em cerca de 0,95 de Pearson, enquanto a versão posterior do PLCMOS relata cerca de 0,97 em um conjunto de avaliação diferente. Os números da Xiph.Org e da Meta são alegações dos próprios desenvolvedores. Os limites do Teams (10%) e da Twilio (5%) divergem por concepção, porque cada fornecedor os ajusta à sua própria pilha de mídia. O rascunho do DRED (que expira em fevereiro de 2027) e o rascunho da bateria de testes do IETF, cujos cenários de perda de pacotes ainda estão indefinidos, podem mudar antes da publicação como RFCs.
Última atualização: 24 de outubro de 2026. Atualizamos este levantamento trimestralmente, e a próxima revisão é esperada quando o grupo de trabalho mlcodec do IETF publicar a próxima versão do rascunho do Opus DRED e dos cenários de perda de pacotes da bateria de testes.