MLow: o codec de áudio de baixa taxa de bits da Meta
(engineering.fb.com)- A Meta criou o novo codec de áudio de baixa taxa de bits MLow para manter a qualidade de chamadas em tempo real no WhatsApp, Instagram e Messenger mesmo em redes lentas e dispositivos antigos
- O Opus existente opera em NarrowBand a 6 kbps, o que dificulta capturar bem as frequências da voz, e quando a rede piora durante chamadas de vídeo, a taxa de bits destinada ao áudio cai ainda mais
- Codecs de áudio baseados em ML podem oferecer boa qualidade em baixas taxas de bits, mas o custo computacional é alto, então muitas vezes são mais adequados para dispositivos móveis modernos e de alto desempenho
- No padrão WideBand a 6 kbps, o MLow apresenta POLQA MOS 3.9, cerca de 2 vezes mais qualidade que o 1.89 do Opus, e a complexidade computacional é 10% menor que a do Opus
- Ele já foi aplicado integralmente às chamadas do Instagram e do Messenger e está sendo distribuído no WhatsApp; além disso, consegue inserir FEC com mais eficiência em baixas taxas de bits, o que ajuda na recuperação de áudio em situações de perda de pacotes
Por que a Meta criou um novo codec
- Os apps da Meta, incluindo WhatsApp, Instagram e Messenger, oferecem recursos de comunicação em tempo real (RTC) para bilhões de pessoas
- Em RTC, os codecs de áudio e vídeo comprimem os dados capturados para transmissão pela internet e são componentes centrais para manter a chamada em tempo real
- O áudio bruto de uma chamada comum tem 768 kbps com base em amostragem de 48 kHz, 16 bits e mono, e codecs modernos conseguem comprimi-lo para 25~30 kbps
- No processo de compressão pode haver perda de qualidade por causa da perda de informação, mas um bom codec equilibra qualidade, taxa de bits e complexidade usando as características do sinal de áudio e conhecimento de psicoacústica
- O Opus é um codec open source amplamente conhecido, lançado em 2012, e a Meta vinha usando o Opus para suas necessidades de RTC
As limitações de baixas taxas de bits e dispositivos antigos
- No ambiente de RTC em grande escala da Meta, é possível observar diretamente como diferentes condições de rede afetam a experiência de chamada
- Uma parcela considerável das chamadas enfrenta conexão de rede ruim em todo o trajeto ou em parte dele
- O módulo de estimativa de largura de banda (BWE) detecta a qualidade da rede
- Quando a qualidade da rede piora, é preciso reduzir a taxa de bits do codec para evitar congestionamento e manter o fluxo de áudio
- Em chamadas de vídeo, sobra ainda menos margem para o áudio em condições ruins de rede
- O ponto mínimo de operação do Opus é 6 kbps, e nesse caso ele funciona no modo NarrowBand de 0~4 kHz
- Essa faixa não consegue capturar adequadamente todas as frequências produzidas pela voz humana
- Como resultado, a voz soa menos clara e menos natural
- Codecs de áudio baseados em ML, como o Encodec divulgado pela Meta em outubro de 2022, oferecem áudio nítido mesmo em taxas de bits muito baixas
- Porém, o custo computacional é alto, então muitas vezes eles só rodam com estabilidade em dispositivos móveis mais potentes e caros
- Usuários de dispositivos de baixo desempenho ainda sofrem com problemas de qualidade de áudio em baixas taxas de bits
- Mais de 20% das chamadas da Meta acontecem em dispositivos ARMv7, e no WhatsApp há dezenas de milhões de chamadas por dia em aparelhos com mais de 10 anos de uso
Desempenho do MLow e status de implantação
- A Meta começou a desenvolver o novo codec no fim de 2021 e, após quase 2 anos de desenvolvimento e testes, anunciou o Meta Low Bitrate audio codec, ou MLow
- A qualidade em WideBand a 6 kbps é de POLQA MOS 3.9, aproximadamente 2 vezes maior que os 1.89 do Opus
- A complexidade computacional é 10% menor que a do Opus
- Na comparação pela escala MOS (Mean Opinion Score) de 1 a 5, o MLow mostra ampla vantagem sobre o Opus na faixa de baixa taxa de bits e atinge saturação de qualidade mais rapidamente que o Opus
- Ele já foi aplicado a todas as chamadas do Instagram e do Messenger e está sendo amplamente distribuído no WhatsApp
- Também foi confirmado que a melhor qualidade de áudio leva a uma melhora no engajamento dos usuários
FEC em situações de perda de pacotes
- Se for possível codificar áudio de alta qualidade em baixa taxa de bits, a estratégia de Forward Error Correction (FEC) também pode ser usada com mais eficiência
- Em comparação com o Opus, o MLow tem margem para incluir FEC mesmo em taxas de bits mais baixas
- Essa característica ajuda a melhorar a qualidade de áudio em situações de perda de pacotes
- Há uma comparação de amostras em uma situação severa com 30% de perda de pacotes no lado do receptor a 14 kbps
- O Opus não consegue codificar FEC in-band nessa taxa de bits
- Para o Opus codificar FEC in-band com 10% de perda de pacotes, são necessários pelo menos 19 kbps
- Essa limitação prejudica a recuperação de áudio
Estrutura interna do MLow
- O MLow é baseado nos conceitos tradicionais do codec CELP (Code Excited Linear Prediction)
- Os principais pontos de melhoria estão na geração da excitação, na quantização de parâmetros e no método de codificação
- O codificador recebe o sinal de entrada, o áudio PCM bruto, e o divide em banda de baixa frequência e banda de alta frequência
- Cada banda é codificada separadamente, mas usa informações compartilhadas para melhorar a compressão
- A saída passa por um codificador por intervalo (range encoder) para compressão adicional, gerando o payload codificado
- O decodificador recebe o payload e executa o processo inverso para produzir o sinal de áudio de saída
- Com otimização por banda dividida, o MLow consegue codificar a banda de alta frequência com pouquíssimos bits
- Graças a essa estrutura, ele consegue oferecer áudio SuperWideBand, ou seja, áudio com amostragem de 32 kHz, mesmo em taxas de bits mais baixas
Próximos passos
- O MLow aumenta significativamente a qualidade de áudio em dispositivos de baixo desempenho, mantendo a criptografia de ponta a ponta das chamadas
- Como consegue inserir áudio redundante com eficiência em baixas taxas de bits, o trabalho para melhorar a recuperação de áudio em redes com forte perda de pacotes continua
1 comentários
Opiniões do Hacker News
Novos codecs de baixa taxa de bits são impressionantes, mas, na maioria dos cenários em que a Meta pretende usá-los, talvez eles não sejam tão úteis na prática
Para reduzir a latência em comunicações em tempo real, a frequência de envio de pacotes precisa ser bastante alta e, a partir de certo ponto, a sobrecarga de UDP, IP e das camadas inferiores passa a dominar mais do que a carga útil real
Por exemplo, (S)RTP sobre UDP/IP tem, no mínimo, 12 bytes de RTP, 8 bytes de UDP e 20 bytes de IPv4, totalizando 40 bytes de overhead. Com 50 pacotes por segundo, ou seja, considerando uma latência de serialização de 20 ms, só o overhead já chega a 16 kbps
Se reduzir para 25 pacotes por segundo, o overhead cai para 8 kbps, mas ainda assim representa uma fatia grande da taxa de transmissão total
Onde esse tipo de codec realmente brilha é em comunicação por comutação de circuitos na faixa de cerca de 2 kbps, como em alguns telefones via satélite, ou em sistemas de VoIP cientes do protocolo, como IMS em LTE/5G, que usam compressão de cabeçalhos na qual a maior parte dos 40 bytes por quadro é previsível
Pacotes de 100 ms aumentam bastante a latência, mas aí a economia do codec passa a fazer sentido. Sistemas mais sofisticados podem ajustar o codec e o número de amostras por pacote conforme as condições atuais
O sistema com que eu trabalho usa um codec fixo com 60 ms de áudio por pacote, então não é ideal, mas funciona muito melhor em baixa largura de banda do que pacotes de 20 ms
A Meta tem uma distribuição muito ampla de servidores de encaminhamento, então também tem margem para adicionar um pouco mais de atraso de amostragem. Ela pode encaminhar a partir de equipamentos de conteúdo dentro de vários ISPs, reduzindo a latência de rede em comparação com serviços concorrentes cuja capacidade global de hospedagem de encaminhamento é limitada. P2P nem sempre funciona, e também nem sempre tem latência menor do que passar por um servidor de encaminhamento próximo
Em especial, mensagens de voz e chamadas do WhatsApp têm participação significativa em países com redes intermitentes e pouco confiáveis. Se for mais resistente a perda de pacotes e jitter, também pode depender de protocolos com menos overhead de correção de erro, fragmentação e confirmações de recebimento
Não é exagero supor que essa tecnologia possa reduzir bastante o consumo total de largura de banda gerado por áudio, mantendo ou melhorando a confiabilidade e a qualidade percebida
Quando observei uma chamada ativa do WhatsApp no Wireshark, durante uma chamada de 1 minuto foram enviados cerca de 380 pacotes UDP do remetente para o destinatário e alguns pacotes TCP para o servidor do WhatsApp. Isso dá um overhead de transmissão de cerca de 2,2 kbps
Para acrescentar o motivo: aqui, o ptime inicial, isto é, o tamanho de áudio por pacote, é configurado como 20 ms, mas o maxptime é configurado como 150 ms. O cliente pode usar isso de forma oportunista, levando em conta a latência dos dois lados e a largura de banda disponível, para reduzir o número de pacotes transmitidos
Imagem: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
Codecs de voz como AMBE+2, comuns em sistemas de rádio, soam bem ruins e não lidam com perda de pacotes de forma tão elegante quanto os codecs novos
Pode ser só marketing, mas, considerando que a Meta é uma das maiores operadoras de chamadas de voz e vídeo em dispositivos de baixa largura de banda, isso parece pouco provável
Não sei qual é a base para achar que a Meta esteve se iludindo esse tempo todo
Por exemplo, quando a criptografia de ponta a ponta impede a mixagem no servidor, dá para colocar dados de vários fluxos em um único pacote. Chamadas de áudio com criptografia de ponta a ponta já estão bastante difundidas, e o Facebook parece bem posicionado para fazer multiplexação customizada em seus próprios produtos
Sou só eu que sinto que a Meta voltou a parecer legal ao compartilhar muito trabalho de pesquisa e open source, ou com pesos públicos?
A reputação do Facebook estava no fundo do poço, mas agora parece ter recuperado um pouco
A reputação do Facebook como rede social talvez não brilhe, mas acho que a reputação da Meta como empresa de engenharia é bem alta
É um pouco parecido com a IBM. Como fornecedora de soluções de hardware ou software, talvez ela não pareça excelente, mas suas áreas de pesquisa e microeletrônica ainda são bem legais
A Microsoft Research também produz coisas realmente incríveis, mas isso não significa que a mesma Microsoft não coloque anúncios no menu Iniciar do sistema operacional
Alguns anos atrás, quando eu era adolescente, vi essa dissociação interessante na Microsoft, e não é nada surpreendente que dentro do Facebook existam ao mesmo tempo departamentos fazendo coisas legais como zstandard e pessoas completamente separadas trabalhando em objetivos totalmente diferentes. Provavelmente, em quase toda empresa com mais de algumas centenas de pessoas existe esse tipo de dissociação entre departamentos
Mas tenho uma visão muito negativa da postura da Meta em relação a privacidade, segurança e responsabilidade social
CassandraDB e (Py)Torch me vêm à mente
A ausência total de menção ou comparação com o Codec2 já torna o valor real e a motivação deste trabalho imediatamente suspeitos
Não precisamos de mais um codec de áudio preso a direitos de propriedade intelectual nessa área
https://jmvalin.ca/demo/lpcnet_codec/
Fico curioso se isso é melhor do que o que o Google Meet usa
Mesmo em uma internet lenta, com cortes a ponto de quase não dar para usar, o Google Meet cumpriu o objetivo de chamada de áudio, enquanto outros serviços concorrentes falharam. Por exemplo, testei em uma ilha remota nas Filipinas com uma internet péssima
Só que, até onde sei, a tecnologia do Google Meet não foi divulgada em lugar nenhum
Só dá para julgar pelo mesmo pouco que todo mundo, olhando alguns exemplos publicados
Também não foi comparado ao Pied Piper
Fugindo um pouco do assunto, por que hoje as ligações telefônicas comuns são mais difíceis de entender do que o μ-law de 8 kHz e 8 bits e o ADPCM dos anos 90?
Edit: troquei “soa pior” por “é mais difícil de entender”
Não é ótimo para música, mas é aceitável para voz e, acima de tudo, é muito consistente. Nas chamadas dos anos 90, o trecho final era quase todo comutado por circuito e, nas linhas digitais, era multiplexado amostra por amostra. T1 e acima funcionavam assim
Por isso, a latência era muito baixa e o jitter era zero. Comparado a uma chamada analógica comutada por circuito nas duas pontas, havia uma latência mensurável, mas difícil de perceber na prática; como a amostragem digital ocorria perto das duas pontas, o ruído era muito menor. Comutação por circuito também significa que as amostras não se perdem. Ou a conexão existe, ou não existe; às vezes acontece de só funcionar em uma direção
Chamadas modernas geralmente usam amostras de 20 ms sobre uma rede comutada por pacotes, então adicionam atraso de amostragem, jitter e buffer de jitter. O codec em si também faz mais do que simplesmente um ADC/DAC com escala logarítmica, então há atraso de codificação e decodificação. A maioria dos codecs usa muito menos bits por amostra do que μ-law, e esse custo não sai de graça
HD Voice (G.722.2 AMR-Wideband) tem uma faixa de passagem de frequência muito mais ampla, então soa muito melhor que GSM, Opus e a maioria dos codecs de baixa largura de banda. Ainda assim, a latência permanece. Alguém pode dizer que 20 a 100 ms de atraso não são perceptíveis, mas, se você ouvir em A/B uma chamada com 0 ms e outra com 20 ms de atraso, vai dizer que a chamada com 0 ms é melhor
Em 2013, troquei um celular flip por um iPhone e a diferença foi enorme. Passei imediatamente a usar earbuds ou viva-voz, e eu era adolescente na época
A maioria das ligações dos anos 90 não usava ADPCM, mas simplesmente PCM. Talvez venha daí a confusão
E também não se usava rádio. Havia um fio de cobre sólido ligando meu microfone ao receptor da outra pessoa. Rádio — isto é, celular, Wi‑Fi e telefone sem fio — é inerentemente menos confiável
Telefones antigos tinham sidetone, mas muitos apps de VoIP não têm
Por fim, hoje o uso de viva-voz se disseminou, e viva-voz não combina com sidetone e acrescenta bastante desvanecimento por múltiplos caminhos no áudio
A falta de menção ao NoLACE reduz um pouco a utilidade das amostras de comparação: https://opus-codec.org/demo/opus-1.5/
https://datatracker.ietf.org/wg/mlcodec/documents/
Seria bom se a Meta doasse isso ao mundo, para reduzir as amarras de trolls de patentes e nos levar ao futuro que deveríamos ter
Isso vai ser publicado, ou é só uma exibição de engenharia? Não consigo encontrar nenhuma outra referência ao MLow além deste post no blog
O Facebook/Meta AI Research faz coisas legais, e publica uma boa parte delas. Eu não gosto do Facebook, mas dá para reconhecer que ele é muito inovador na área de IA
O texto diz: “estamos muito felizes com o que realizamos nos últimos dois anos: desenvolver um novo codec e implantá-lo com sucesso para bilhões de usuários no mundo todo”
Pergunta sincera: por que otimizar para menos de 10 kbps?
Conseguir esse nível a 6 kbps é realmente impressionante, mas o LTE já suporta 32 kbps ou mais, e nessa faixa existem AMR-WB e Opus. O Opus também tem correção de erro direta dentro da banda nessa taxa de bits, então perda de pacotes não é tão fatal assim.
Talvez seja útil para usos como conexão direta satélite-celular.
Presumir que há largura de banda acima de 32 kbps é uma premissa ruim.
Reduzir a taxa de bits do codec de áudio usado permite falar por mais tempo no mês com o mesmo plano de dados.
Só que, nessa área, os ganhos diminuem por causa do overhead de RTP, UDP e IP. Mais detalhes estão em outro comentário meu.
Hoje essa área é dominada pelo AMBE, que é horrível em todos os indicadores mensuráveis e deveria ser queimado nas chamas mais profundas do inferno e apagado da história.
Se você precisa de latência baixa e estável, como em uma chamada telefônica, a vazão que dá para obter fica muito pequena.
Exemplos seriam Wi‑Fi no limite do alcance ou uma conexão LTE com uma barrinha de sinal.
Nesses casos, um teste de velocidade pode dizer que você tem alguns megabits, mas, se quiser baixa latência estável, a largura de banda realmente utilizável provavelmente estará na casa dos quilobits.
Fico curioso para saber como soaria em comparação com G.729.
Em uma empresa em que trabalhei 20 anos atrás, havia um codec G.729 modificado que ainda soava razoavelmente bem mesmo abaixo de 8 kbps. Era usado para VoIP sobre internet discada, então era realmente baixa largura de banda.
Descobri que algumas das partes mais interessantes estavam no jitter buffer e na forma de gerenciar o buffer. Conexões instáveis entregam pacotes quando conseguem, e é preciso técnica para administrar a diferença entre a experiência da rede e a experiência do usuário. Em comunicações, é preciso gerenciar bem a experiência do usuário.