MLow: codec âm thanh bitrate thấp của Meta
(engineering.fb.com)- Meta đã xây dựng codec âm thanh bitrate thấp mới MLow để duy trì chất lượng cuộc gọi thời gian thực trên WhatsApp, Instagram và Messenger ngay cả trên mạng chậm và thiết bị cũ
- Opus hiện tại hoạt động ở chế độ NarrowBand tại 6 kbps nên khó bao quát đầy đủ dải tần giọng nói, và khi mạng xấu trong lúc gọi video thì bitrate được phân bổ cho âm thanh còn giảm thêm
- Các codec âm thanh dựa trên ML có thể cho chất lượng tốt ở bitrate thấp, nhưng chi phí tính toán cao nên thường chỉ phù hợp với các thiết bị di động đời mới, hiệu năng cao
- Với chuẩn WideBand 6 kbps, MLow đạt POLQA MOS 3.9, cao gần gấp đôi so với 1.89 của Opus, đồng thời độ phức tạp tính toán thấp hơn 10% so với Opus
- MLow đã được áp dụng hoàn toàn cho cuộc gọi trên Instagram và Messenger, đang được triển khai cho WhatsApp, đồng thời có thể chèn FEC hiệu quả hơn ở bitrate thấp nên có lợi cho việc khôi phục âm thanh trong tình huống mất gói
Vì sao Meta tạo ra codec mới
- Các ứng dụng của Meta, gồm WhatsApp, Instagram và Messenger, cung cấp tính năng giao tiếp thời gian thực (RTC) cho hàng tỷ người dùng
- Trong RTC, codec âm thanh và video là thành phần cốt lõi giúp nén dữ liệu đã thu để truyền qua Internet và duy trì cuộc gọi theo thời gian thực
- Âm thanh thô của một cuộc gọi thông thường có tốc độ 768 kbps với chuẩn lấy mẫu 48kHz, 16-bit, mono, và các codec hiện đại có thể nén xuống 25~30 kbps
- Trong quá trình nén, chất lượng có thể suy giảm do mất thông tin, nhưng codec tốt sẽ tận dụng đặc tính của tín hiệu âm thanh và kiến thức tâm sinh lý âm học để cân bằng giữa chất lượng, bitrate và độ phức tạp
- Opus là codec mã nguồn mở nổi tiếng được công bố năm 2012, và Meta từ trước đến nay đã dùng Opus cho các yêu cầu RTC
Hạn chế của bitrate thấp và thiết bị cũ
- Trong môi trường RTC quy mô lớn của Meta, có thể trực tiếp quan sát tác động của nhiều điều kiện mạng khác nhau lên trải nghiệm cuộc gọi
- Một tỷ lệ đáng kể các cuộc gọi gặp kết nối mạng kém trong toàn bộ hoặc một phần thời gian gọi
- Mô-đun ước lượng băng thông (BWE) phát hiện chất lượng mạng
- Khi chất lượng mạng xấu đi, cần hạ bitrate của codec để tránh tắc nghẽn và duy trì luồng âm thanh
- Trong gọi video, phần dư dành cho âm thanh còn ít hơn dưới điều kiện mạng kém
- Mức hoạt động thấp nhất của Opus là 6 kbps, và ở mức này nó chạy ở chế độ NarrowBand 0~4kHz
- Dải này không thể thu đầy đủ mọi tần số do giọng người tạo ra
- Kết quả là giọng nói nghe kém rõ ràng và kém tự nhiên hơn
- Các codec âm thanh dựa trên ML như Encodec mà Meta công bố vào tháng 10/2022 có thể cung cấp chất lượng âm thanh rõ ràng ngay cả ở bitrate rất thấp
- Tuy nhiên, chi phí tính toán cao nên trong nhiều trường hợp chỉ chạy ổn định trên thiết bị di động cao cấp, hiệu năng mạnh
- Người dùng thiết bị cấu hình thấp vẫn gặp vấn đề chất lượng âm thanh trong điều kiện bitrate thấp
- Hơn 20% các cuộc gọi của Meta diễn ra trên thiết bị ARMv7, và riêng trên WhatsApp có hàng chục triệu cuộc gọi mỗi ngày trên các thiết bị hơn 10 năm tuổi
Hiệu năng và tình hình triển khai của MLow
- Meta bắt đầu phát triển codec mới vào cuối năm 2021, và sau gần 2 năm phát triển, thử nghiệm đã công bố Meta Low Bitrate audio codec, tức MLow
- Ở chuẩn WideBand 6 kbps, chất lượng đạt POLQA MOS 3.9, gần gấp đôi 1.89 của Opus
- Độ phức tạp tính toán thấp hơn 10% so với Opus
- Trong so sánh theo thang MOS (Mean Opinion Score) từ 1 đến 5, MLow vượt trội rõ rệt so với Opus ở vùng bitrate thấp và đạt trạng thái bão hòa chất lượng nhanh hơn Opus
- Đã được áp dụng cho toàn bộ cuộc gọi trên Instagram và Messenger, và đang được triển khai tích cực cho WhatsApp
- Meta cũng xác nhận chất lượng âm thanh tốt hơn giúp cải thiện mức độ tương tác của người dùng
FEC trong tình huống mất gói
- Nếu có thể mã hóa âm thanh chất lượng cao ở bitrate thấp, chiến lược Forward Error Correction(FEC) cũng có thể được sử dụng hiệu quả hơn
- So với Opus, MLow có thêm dư địa để chèn FEC ngay cả ở bitrate thấp hơn
- Đặc tính này giúp cải thiện chất lượng âm thanh trong tình huống mất gói
- Có ví dụ so sánh mẫu trong tình huống phía nhận có tỷ lệ mất gói lớn tới 30% ở 14 kbps
- Opus không thể mã hóa in-band FEC ở mức bitrate đó
- Để Opus mã hóa in-band FEC ở mức mất gói 10%, cần ít nhất 19 kbps
- Hạn chế này gây bất lợi cho việc khôi phục âm thanh
Cấu trúc bên trong của MLow
- MLow dựa trên khái niệm codec CELP(Code Excited Linear Prediction) truyền thống
- Các điểm cải tiến chính nằm ở việc tạo excitation, lượng tử hóa tham số và phương thức mã hóa
- Bộ mã hóa nhận tín hiệu đầu vào là âm thanh PCM thô rồi chia thành dải tần thấp và dải tần cao
- Mỗi dải được mã hóa riêng, nhưng sử dụng thông tin chia sẻ để nén tốt hơn
- Đầu ra tiếp tục được nén thêm qua bộ mã hóa phạm vi (range encoder), từ đó tạo payload đã mã hóa
- Bộ giải mã nhận payload và thực hiện quy trình ngược lại để tạo tín hiệu âm thanh đầu ra
- MLow có thể mã hóa dải tần cao với rất ít bit nhờ tối ưu hóa băng tần phân chia
- Nhờ cấu trúc này, nó có thể cung cấp âm thanh SuperWideBand, tức âm thanh lấy mẫu 32kHz, ngay cả ở bitrate thấp hơn
Công việc tiếp theo
- MLow giúp nâng cao đáng kể chất lượng âm thanh trên thiết bị cấu hình thấp trong khi vẫn duy trì mã hóa đầu cuối cho cuộc gọi
- Nhờ có thể chèn phần âm thanh dư hiệu quả ở bitrate thấp, Meta đang tiếp tục cải thiện khả năng khôi phục âm thanh trên các mạng có mức mất gói nghiêm trọng
1 bình luận
Ý kiến trên Hacker News
Các codec bitrate thấp mới thật đáng kinh ngạc, nhưng có vẻ chúng có thể không thực sự hữu ích lắm trong phần lớn các kịch bản mà Meta muốn dùng
Để giảm độ trễ trong truyền thông thời gian thực, tần suất gửi gói phải khá cao, và đến một lúc nào đó overhead của UDP, IP và các lớp bên dưới sẽ lấn át phần payload thực tế
Ví dụ, (S)RTP chạy trên UDP/IP có RTP tối thiểu 12 byte, UDP 8 byte, IPv4 20 byte, tức tổng cộng 40 byte overhead. Với 50 gói mỗi giây, tức độ trễ tuần tự hóa 20ms, chỉ riêng overhead đã là 16kbps
Nếu giảm xuống 25 gói mỗi giây thì overhead còn 8kbps, nhưng overhead vẫn chiếm tỷ trọng lớn trong tổng tốc độ truyền
Nơi những codec này thật sự tỏa sáng là truyền thông chuyển mạch kênh dùng quanh mức 2kbps như một số điện thoại vệ tinh, hoặc các hệ thống VoIP nhận biết giao thức có nén header, nơi phần lớn 40 byte mỗi frame là có thể dự đoán được, như LTE/5G IMS
Gói 100ms sẽ làm tăng độ trễ nhiều, nhưng ở mức đó hiệu quả tiết kiệm của codec trở nên có ý nghĩa. Các hệ thống tinh vi hơn có thể điều chỉnh codec và số mẫu trên mỗi gói tùy theo điều kiện hiện tại
Hệ thống tôi làm việc dùng codec cố định và 60ms âm thanh mỗi gói nên không lý tưởng, nhưng hoạt động tốt hơn nhiều so với gói 20ms trong điều kiện băng thông thấp
Meta có mạng lưới máy chủ chuyển tiếp phân bố rất rộng, nên cũng có dư địa để thêm một chút độ trễ lấy mẫu. Họ có thể chuyển tiếp từ thiết bị nội dung đặt trong nhiều ISP, nhờ đó giảm độ trễ mạng so với các dịch vụ cạnh tranh có năng lực hosting chuyển tiếp toàn cầu hạn chế. P2P không phải lúc nào cũng hoạt động, và cũng không phải lúc nào cũng có độ trễ thấp hơn việc đi qua một máy chủ chuyển tiếp gần đó
Đặc biệt, tin nhắn thoại và cuộc gọi WhatsApp có thị phần đáng kể ở các quốc gia có môi trường mạng chập chờn và kém tin cậy. Nếu chịu mất gói và jitter tốt hơn, họ cũng có thể dựa vào các giao thức có ít overhead hơn cho sửa lỗi, phân mảnh và phản hồi nhận gói
Có thể nói công nghệ này có khả năng giảm đáng kể tổng mức tiêu thụ băng thông phát sinh từ âm thanh, trong khi vẫn duy trì hoặc cải thiện độ tin cậy và chất lượng cảm nhận
Khi tôi xem một cuộc gọi WhatsApp đang hoạt động bằng Wireshark, trong cuộc gọi 1 phút có khoảng 380 gói UDP từ người gọi sang người nhận, và vài gói TCP tới máy chủ WhatsApp. Như vậy overhead truyền tải vào khoảng 2,2kbps
Nói thêm lý do: ở đây ptime ban đầu, tức kích thước âm thanh trên mỗi gói, được đặt là 20ms, nhưng maxptime được đặt là 150ms. Client có thể tận dụng điều này một cách tùy cơ để giảm số gói truyền đi, dựa trên độ trễ hai chiều và băng thông khả dụng
Hình ảnh: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
Các codec thoại như AMBE+2 thường dùng trong hệ thống vô tuyến có chất âm khá tệ, và cũng không xử lý mất gói một cách mềm mại như các codec mới
Có thể là thổi phồng, nhưng xét việc Meta là một trong những nhà cung cấp lớn nhất về cuộc gọi thoại và video trên thiết bị băng thông thấp, khả năng đó có vẻ thấp
Tôi không biết có cơ sở gì để cho rằng Meta đã tự đánh lừa mình suốt thời gian qua
Ví dụ, trong trường hợp máy chủ không được trộn do mã hóa đầu cuối, dữ liệu của nhiều luồng có thể được đưa vào một gói duy nhất. Cuộc gọi âm thanh mã hóa đầu cuối giờ đã khá phổ biến, và Facebook có vẻ ở vị thế tốt để triển khai ghép kênh tùy chỉnh trong sản phẩm của mình
Có phải chỉ mình tôi cảm thấy Meta lại trở nên ngầu hơn khi chia sẻ nhiều nghiên cứu và công việc mã nguồn mở, hoặc trọng số công khai không
Danh tiếng của Facebook từng chạm đáy, nhưng giờ có vẻ họ đã gỡ gạc được phần nào
Danh tiếng của Facebook với tư cách mạng xã hội có thể không sáng sủa, nhưng tôi nghĩ danh tiếng của Meta với tư cách công ty kỹ thuật thì khá cao
Cũng hơi giống IBM. Với tư cách nhà cung cấp giải pháp phần cứng hay phần mềm thì có thể trông không quá xuất sắc, nhưng mảng nghiên cứu và vi điện tử của họ vẫn khá thú vị
Microsoft Research cũng cho ra đời những thứ thật sự tuyệt vời, nhưng điều đó không có nghĩa là cùng Microsoft ấy sẽ không nhét quảng cáo vào menu Start của hệ điều hành
Vài năm trước, khi còn ở tuổi thiếu niên, tôi đã thấy sự lệch pha thú vị này ở Microsoft, và hoàn toàn không ngạc nhiên khi trong Facebook vừa có những bộ phận làm các việc hay ho như zstandard, vừa có những con người hoàn toàn tách biệt đang làm việc hướng tới những mục tiêu rất khác. Có lẽ hầu hết công ty vượt quá vài trăm người đều có kiểu lệch pha giữa các bộ phận như vậy
Nhưng tôi rất tiêu cực về thái độ của Meta đối với quyền riêng tư, bảo mật và trách nhiệm xã hội
CassandraDB và (Py)Torch là những cái tôi nghĩ đến
Hoàn toàn không có nhắc đến hay so sánh với Codec2, nên giá trị và động cơ thực tế của công trình này lập tức trở nên đáng nghi
Lĩnh vực này không cần thêm một codec âm thanh nữa bị ràng buộc bởi quyền sở hữu trí tuệ
https://jmvalin.ca/demo/lpcnet_codec/
Không rõ liệu cái này có tốt hơn so với thứ Google Meet đang dùng không
Ngay cả trên kết nối Internet chậm, giật đến mức gần như không dùng được, Google Meet vẫn đạt được mục đích gọi âm thanh, trong khi các dịch vụ cạnh tranh khác thì thất bại. Ví dụ tôi đã thử trên mạng Internet cực tệ ở một hòn đảo xa xôi tại Philippines
Tuy nhiên, theo tôi biết thì công nghệ của Google Meet không được công bố ở đâu cả
Chúng ta cũng chỉ có thể đánh giá ở mức tương tự dựa trên vài ví dụ được công bố
Cũng không so sánh với Pied Piper
Hơi lệch chủ đề một chút, nhưng tại sao các cuộc gọi điện thoại thông thường ngày nay lại khó nghe rõ hơn so với 8kHz 8-bit μ-law và ADPCM của thập niên 90
Sửa: đổi “âm thanh tệ hơn” thành “khó nghe rõ hơn”
Không hay cho nhạc, nhưng với giọng nói thì cũng tạm ổn, và quan trọng nhất là rất nhất quán. Các cuộc gọi thập niên 90 gần như toàn bộ chặng cuối đều là chuyển mạch kênh, còn trên đường dây số thì được ghép kênh theo từng mẫu. T1 trở lên là theo kiểu đó
Vì vậy độ trễ rất thấp và jitter bằng 0. So với cuộc gọi chuyển mạch kênh analog ở cả hai đầu thì có độ trễ đo được, nhưng thực tế khó cảm nhận, và vì lấy mẫu số gần hai đầu nên nhiễu ít hơn rất nhiều. Chuyển mạch kênh cũng có nghĩa là mẫu không bị mất. Hoặc kết nối được hoặc không, đôi khi có trường hợp chỉ một chiều hoạt động
Cuộc gọi hiện đại thường dùng mẫu 20ms trên mạng chuyển mạch gói, nên có thêm độ trễ lấy mẫu, jitter và bộ đệm jitter. Bản thân codec cũng làm nhiều việc hơn là chỉ ADC/DAC kèm log đơn giản, nên có độ trễ mã hóa/giải mã. Hầu hết codec dùng ít bit hơn rất nhiều cho mỗi mẫu so với μ-law, và cái giá đó không miễn phí
HD Voice (G.722.2 AMR-Wideband) có dải tần thông qua rộng hơn nhiều, nên nghe tốt hơn hẳn GSM, Opus và phần lớn codec băng thông thấp. Dù vậy độ trễ vẫn còn. Có người sẽ nói độ trễ 20~100ms là không cảm nhận được, nhưng nếu cho nghe A/B một cuộc gọi 0ms và một cuộc gọi trễ 20ms, họ sẽ nói cuộc gọi 0ms tốt hơn
Năm 2013 tôi đổi từ điện thoại nắp gập sang iPhone và khác biệt là rất lớn. Tôi lập tức chuyển sang dùng earbud hoặc loa ngoài, khi đó tôi còn là thiếu niên
Phần lớn cuộc gọi thập niên 90 không dùng ADPCM mà chỉ dùng PCM. Có lẽ bạn nhầm ở chỗ đó
Và cũng không dùng không dây. Từ micro của tôi đến ống nghe của người kia là một sợi dây đồng chắc chắn nối liền. Không dây, tức điện thoại di động, Wi‑Fi, điện thoại không dây, về bản chất là kém tin cậy hơn
Điện thoại đời cũ có sidetone, nhưng nhiều ứng dụng VoIP thì không
Cuối cùng, hiện nay việc dùng loa ngoài đã trở nên phổ biến, mà loa ngoài không hợp với sidetone và còn thêm rất nhiều hiện tượng fading đa đường âm thanh
Việc không nhắc đến NoLACE khiến các mẫu so sánh kém hữu ích hơn một chút: https://opus-codec.org/demo/opus-1.5/
https://datatracker.ietf.org/wg/mlcodec/documents/
Sẽ thật tốt nếu Meta đóng góp nó cho thế giới, giúp giảm sự cản trở từ các patent troll và đưa chúng ta đến tương lai mà đáng ra chúng ta được hưởng
Họ có công khai cái này không, hay chỉ là khoe kỹ thuật? Ngoài bài blog này, tôi không tìm được tài liệu tham khảo nào khác về MLow
Facebook/Meta AI Research làm những việc rất hay, và công khai khá nhiều trong số đó. Tôi không thích Facebook, nhưng có thể thừa nhận họ rất đổi mới trong lĩnh vực AI
Bài viết có đoạn “chúng tôi rất vui mừng về những thành quả đạt được trong hai năm qua, từ việc phát triển codec mới đến triển khai thành công cho hàng tỷ người dùng trên toàn thế giới”
Hỏi thật lòng, tại sao lại phải tối ưu cho mức dưới 10kbps?
Việc đạt được chất lượng như vậy ở 6kbps thật sự rất ấn tượng, nhưng LTE cũng đã hỗ trợ từ 32kbps trở lên, và ở khoảng đó đã có AMR-WB hoặc Opus. Opus còn có cơ chế sửa lỗi tiến trong băng ở mức bitrate này, nên mất gói không đến mức chí mạng như vậy
Có lẽ nó sẽ hữu ích cho các trường hợp như kết nối vệ tinh trực tiếp tới điện thoại
Giả định rằng có băng thông trên 32kbps là một giả định tệ
Nếu giảm bitrate của codec âm thanh đang dùng, bạn có thể gọi lâu hơn trong tháng với cùng một gói dữ liệu
Tuy nhiên trong mảng này, lợi ích sẽ giảm dần do overhead của RTP, UDP, IP. Chi tiết có trong một bình luận khác của tôi
Hiện mảng này đang bị AMBE nắm chặt, mà AMBE thì tệ hại theo mọi chỉ số có thể đo được và đáng bị thiêu trong ngọn lửa sâu nhất của địa ngục để xóa khỏi lịch sử
Nếu cần độ trễ thấp ổn định như cuộc gọi điện thoại, thông lượng bạn có thể đạt được sẽ trở nên rất nhỏ
Ví dụ như Wi-Fi ở rìa vùng phủ sóng hoặc kết nối LTE chỉ có một vạch sóng
Trong những trường hợp như vậy, bài đo tốc độ có thể nói là được vài megabit, nhưng nếu muốn độ trễ thấp ổn định thì băng thông thực sự dùng được có lẽ chỉ ở mức kilobit
Tò mò không biết so với G.729 thì nghe sẽ như thế nào
Công ty tôi làm 20 năm trước có một codec G.729 đã được chỉnh sửa, nghe vẫn khá ổn ngay cả khi xuống dưới 8kbps. Nó được dùng cho VoIP qua Internet quay số, nên đúng là băng thông rất thấp
Hóa ra một số phần thú vị hơn lại nằm ở bộ đệm jitter và cách quản lý bộ đệm. Kết nối không ổn định sẽ chuyển gói khi có thể, và cần kỹ thuật để quản lý sự khác biệt giữa trải nghiệm mạng và trải nghiệm người dùng. Trong truyền thông, phải quản lý trải nghiệm người dùng cho đúng