Hệ thống che giấu mất gói tin bằng nơ-ron tốt nhất trong INTERSPEECH 2022 Audio Deep PLC Challenge của Microsoft đạt PLCMOS 4,28 trên thang từ 1 đến 5, so với 2,90 khi chỉ chèn im lặng và 4,51 của bản gốc sạch (Microsoft, bài báo INTERSPEECH 2022 Audio Deep PLC Challenge). Hai năm sau, khi cùng cuộc thi chuyển sang âm thanh băng thông đầy đủ và chuỗi mất gói liên tiếp lên đến 3 giây, các hệ thống đồng thắng cuộc chỉ nâng được chất lượng tổng thể từ 2,37 lên 3,49, vẫn thấp hơn nhiều so với mức 4,01 của giọng nói sạch (Microsoft, bài báo ICASSP 2024 Audio Deep PLC Challenge). Vấn đề này không hiếm: Google báo cáo rằng 99% cuộc gọi Duo phải xử lý tình trạng mất gói tin, jitter hoặc độ trễ, và cứ mười cuộc gọi thì có một cuộc mất hơn 8% âm thanh (Google Research, blog WaveNetEQ 2020). Che giấu là lớp thầm lặng bên dưới các xu hướng kinh doanh trong thống kê VoIP và UCaaS của chúng tôi, và bổ sung cho bức tranh từ phía nhà mạng trong thống kê chất lượng thoại di động (MOS) của chúng tôi. Chúng tôi tổng hợp dữ liệu từ các bài báo thử thách của Microsoft Research, IETF và ITU-T, W3C, Google Research, các nhà phát triển Opus của Xiph.Org, Meta Engineering, tài liệu của Microsoft Learn và Twilio, cùng các nghiên cứu PLC đã qua bình duyệt được liệt kê trong phần phương pháp luận.
Tóm tắt nhanh
- 99% cuộc gọi Google Duo phải xử lý tình trạng mất gói tin, jitter hoặc độ trễ; 10% mất hơn 8% tổng lượng âm thanh (Google Research, blog WaveNetEQ 2020).
- Microsoft Teams đánh dấu một luồng âm thanh là Poor khi tỷ lệ mất gói tin trung bình vượt 0,1, tức 10% (Microsoft Learn, CQD Stream Classification 2026).
- G.711 với cơ chế che giấu Appendix I có hệ số chống chịu mất gói tin là 25,1, so với 4,3 khi không có che giấu (ITU-T G.113, 09/2024).
- Hệ thống PLC nơ-ron thắng cuộc: PLCMOS 4,28 so với 2,90 của phương pháp điền số không và 4,51 của giọng nói sạch (Microsoft, bài báo INTERSPEECH 2022 Deep PLC Challenge).
- PLC lai của nhóm Opus xếp thứ nhất về độ chính xác từ (0,882) và thứ hai về tổng thể trong cuộc thi năm 2022 (Valin và cs., Real-Time PLC with Mixed Generative and Predictive Model 2022).
- Với chuỗi mất gói liên tiếp lên đến 3 giây, 2 trong 8 hệ thống đủ điều kiện có điểm thấp hơn âm thanh bị mất gói chưa xử lý về chất lượng tổng thể P.804 (Microsoft, bài báo ICASSP 2024 Deep PLC Challenge).
- PLCMOS đạt hệ số tương quan Pearson theo từng mô hình khoảng 0,97 với đánh giá của con người; trên dữ liệu căn chỉnh theo tham chiếu, PESQ chỉ đạt 0,52 (Diener và cs., bài báo PLCMOS 2023).
- FEC trong băng LBRR của Opus bao phủ 1 khung ở mức khoảng 2/3 tốc độ bit thông thường; DRED bao phủ tới 1 giây ở mức khoảng 1/50 (IETF draft-ietf-mlcodec-opus-dred-07, tháng 8 năm 2026).
- Opus cần tối thiểu 19 kbps để mã hóa FEC trong băng khi mất gói tin 10%, theo chính so sánh MLow của Meta (Meta Engineering, MLow 2024).
- Opus 1.6 thu nhỏ các mô hình DRED khoảng 3 lần, xuống còn 600 kB từ 1.800 kB (Xiph.Org, bản demo Opus 1.6, tháng 12 năm 2025).
1. Bao Nhiêu Âm Thanh Bị Mất và Các Nền Tảng Vạch Ranh Giới Ở Đâu
Trong bối cảnh này, một gói tin là một lát cắt âm thanh nhỏ (thường là 20 ms) được gửi qua mạng. Khi nó đến quá trễ hoặc không đến, bên nhận có hai lựa chọn: phát im lặng, hoặc che giấu khoảng trống bằng cách tổng hợp thứ gì đó nghe giống lời nói bị thiếu. Dữ liệu của chính Google cho thấy 99% cuộc gọi Duo phải xử lý tình trạng mất gói tin, jitter hoặc độ trễ (Google Research, Improving Audio Quality in Duo with WaveNetEQ 2020). Vì vậy che giấu không phải là trường hợp ngoại lệ: nó chạy trong hầu hết mọi cuộc gọi.
Các nền tảng không thống nhất về điểm mà tại đó mất gói tin chuyển từ tiếng ồn nền thành một vấn đề. Microsoft Teams vạch ngưỡng Poor ở mức mất gói trung bình 10%, Twilio ở mức 5%, và Microsoft cảnh báo rõ ràng rằng nhãn Poor không có nghĩa là người dùng thực sự nhận thấy vấn đề về chất lượng, vì nền tảng truyền thông của họ có hiệu chỉnh việc mất gói tin (Microsoft Learn, Stream Classification in CQD 2026). Lời lưu ý đó chính là toàn bộ lập luận cho việc che giấu tốt hơn: PLC càng đi xa, nền tảng càng có thể đặt ngưỡng báo động cao hơn.
| Chỉ số | Giá trị | Nguồn |
|---|---|---|
| Tỷ lệ cuộc gọi Google Duo phải xử lý tình trạng mất gói tin, jitter hoặc độ trễ | 99% | Google Research, blog WaveNetEQ 2020 |
| Tỷ lệ cuộc gọi Duo mất hơn 3% tổng thời lượng âm thanh | 20% | Google Research, blog WaveNetEQ 2020 |
| Tỷ lệ cuộc gọi Duo mất hơn 8% tổng thời lượng âm thanh | 10% | Google Research, blog WaveNetEQ 2020 |
| Tỷ lệ mất gói tin trung bình mà trên mức đó Teams phân loại một luồng âm thanh là Poor | Trên 0,1 (10%), chỉ áp dụng cho các luồng có hơn 500 gói tin | Microsoft Learn, CQD Stream Classification 2026 |
| Mức mất gói tin kích hoạt thẻ cuộc gọi high_packet_loss của Twilio | Trên 5% | Twilio Voice Insights, Details: Call Tags |
| MOS ước tính mà dưới mức đó Twilio gắn thẻ low_mos cho cuộc gọi qua trình duyệt hoặc SDK di động | Dưới 3,5 | Twilio Voice Insights, Details: Call Tags |
| Tỷ lệ mất gói trung bình trong bộ kiểm thử Deep PLC Challenge dùng để đánh giá Opus DRED | 18,4%, với chuỗi mất gói liên tiếp lên đến một giây | Valin và cs., bài báo DRED (arXiv 2212.04453 v3, 2024) |
Dữ liệu mới nhất hiện có: Google Research, 2020. Chưa có nền tảng lớn nào công bố phân bố mất gói ở cấp độ cuộc gọi mới hơn. Teams báo cáo chỉ số liên quan “Ratio Concealed Samples Avg” cho mỗi luồng, trong đó 0,1 nghĩa là 10% khung âm thanh chứa mẫu bị che giấu (Microsoft Learn, CQD dimensions and measures 2026), nhưng Microsoft không công bố giá trị trên toàn hệ thống. Các chỉ số tương đương phía trình duyệt, concealedSamples và concealmentEvents, được định nghĩa trong API thống kê WebRTC của W3C (Candidate Recommendation Draft, ngày 25 tháng 9 năm 2025).
2. Che Giấu Của Codec Cổ Điển Theo Mô Hình E Của ITU-T
Trước khi có mạng nơ-ron, che giấu có nghĩa là lặp lại hoặc ngoại suy chu kỳ cao độ tốt cuối cùng. Mô hình lập kế hoạch của ITU-T (mô hình E) chấm điểm khả năng một codec chịu đựng mất gói bằng hệ số chống chịu mất gói tin, Bpl: một con số thông thường, trong đó giá trị càng cao nghĩa là chất lượng suy giảm càng chậm khi gói tin biến mất. G.711 với thuật toán che giấu từ Appendix I có Bpl là 25,1, gần gấp sáu lần mức 4,3 của G.711 không có che giấu (ITU-T G.113 09/2024, Bảng I.4).
Khoảng chênh lệch đó có ý nghĩa gì trong thực tế sẽ rõ hơn khi nhìn vào con số. Dùng Phương trình 7-29 của ITU-T G.107 (06/2015), Ie-eff = Ie + (95 - Ie) x Ppl / (Ppl/BurstR + Bpl), G.711 (Ie = 0) với mất gói ngẫu nhiên 5% (BurstR = 1) cho ra 95 x 5 / (5 + 4,3) = 51,1 điểm suy giảm khi không có che giấu, và 95 x 5 / (5 + 25,1) = 15,8 khi có che giấu. Trừ vào điểm mặc định R = 93,2, ta có R 42,1 so với R 77,4, được công thức Annex B của G.107 quy đổi thành MOS ước tính khoảng 2,2 so với 3,9 (phép tính của chúng tôi; mọi đầu vào khác của mô hình E giữ ở giá trị mặc định). Chỉ riêng che giấu đã đưa một cuộc gọi mất gói 5% từ mức kém lên mức chấp nhận được.
| Chỉ số | Giá trị | Nguồn |
|---|---|---|
| G.711 (64 kbit/s, gói tin 10 ms) không có che giấu: hệ số chống chịu mất gói tin Bpl khi mất gói ngẫu nhiên | 4,3 | ITU-T G.113 (09/2024), Bảng I.4 |
| G.711 với thuật toán che giấu G.711 Appendix I: Bpl khi mất gói ngẫu nhiên | 25,1 | ITU-T G.113 (09/2024), Bảng I.4 |
| G.729 Annex A với phát hiện hoạt động giọng nói (8 kbit/s, gói tin 20 ms, che giấu gốc): Ie và Bpl | Ie 11, Bpl 19,0 | ITU-T G.113 (09/2024), Bảng I.4 |
| G.711 với gói tin 20 ms, 8 gói bị mất trong một chuỗi liên tiếp ở mức mất gói 2% (tỷ lệ chuỗi 7,84): suy giảm hiệu dụng Ie-eff | 10 | ITU-T G.113 (09/2024), Bảng I.6 |
| G.722 ở 64 kbit/s với che giấu chất lượng cao của G.722 Appendix III: Bpl băng rộng (nghe bằng cả hai tai) | 7,1 | ITU-T G.113 (09/2024), Appendix IV |
| EVS ở chế độ siêu băng rộng 24,4 kbit/s: Bpl băng thông đầy đủ | 11,4 | ITU-T G.113 (09/2024), Appendix V |
| Hệ số xếp hạng R của mô hình E khi mọi đầu vào đều ở giá trị mặc định | 93,2 | ITU-T G.107 (06/2015) |
Bối cảnh: các giá trị Bpl chỉ so sánh được trong cùng một thang (băng hẹp, băng rộng hoặc băng thông đầy đủ). G.113 không liệt kê giá trị Opus nào, nên âm thanh WebRTC dựa trên Opus phải được đánh giá bằng các công cụ khác (xem phần 5).
3. Che Giấu Bằng Nơ-ron So Với Im Lặng: Deep PLC Challenge 2022
Cuộc thi INTERSPEECH 2022 đã đánh giá PLC nơ-ron trên các mẫu mất gói thực tế, dùng dữ liệu ghi lại từ các cuộc gọi Microsoft Teams và quy tắc thời gian thực nghiêm ngặt: tổng độ trễ thuật toán tối đa 20 ms. Kết quả nổi bật của nó là quy mô khoảng cách giữa hệ thống thắng cuộc và việc không làm gì cả. Hệ thống thắng cuộc đạt -0,55 trên thang so sánh (CMOS, trong đó 0 nghĩa là không phân biệt được với bản gốc sạch), so với -1,23 của phương pháp điền số không (Microsoft, bài báo INTERSPEECH 2022 Audio Deep PLC Challenge).
Khả năng nghe hiểu cho thấy một câu chuyện khiêm tốn hơn. Độ chính xác từ, đo bằng 1 trừ đi tỷ lệ lỗi từ của một bộ nhận dạng giọng nói, chỉ tăng từ 0,86 với im lặng lên 0,88 với hệ thống thắng cuộc, so với 0,97 của giọng nói sạch. Người nghe cảm nhận che giấu là một cải thiện lớn, nhưng bộ nhận dạng vẫn bỏ sót 12% số từ với hệ thống thắng cuộc, so với 3% ở giọng nói sạch, một quy luật đáng ghi nhớ khi đặt cạnh thống kê tỷ lệ lỗi từ của nhận dạng giọng nói của chúng tôi.
| Chỉ số | Giá trị | Nguồn |
|---|---|---|
| Giọng nói tham chiếu sạch: PLCMOS (1 đến 5) và độ chính xác từ | 4,51 và 0,97 | Microsoft, bài báo INTERSPEECH 2022 Deep PLC Challenge |
| Mốc điền số không (im lặng thay cho gói tin bị mất): PLCMOS, CMOS và độ chính xác từ | 2,90, -1,23 và 0,86 | Microsoft, bài báo INTERSPEECH 2022 Deep PLC Challenge |
| Hệ thống thắng cuộc (nhóm #12, U-Net miền thời gian, khoảng 2,36M tham số): PLCMOS, CMOS và độ chính xác từ | 4,28, -0,55 và 0,88 | Microsoft, bài báo INTERSPEECH 2022 Deep PLC Challenge |
| Hệ thống đủ điều kiện xếp thấp nhất (nhóm #6) so với mốc điền số không: CMOS | -1,31 so với -1,23 | Microsoft, bài báo INTERSPEECH 2022 Deep PLC Challenge |
| PLC lai sinh và dự đoán của nhóm Opus: độ chính xác từ và thứ hạng theo chỉ số đó | 0,882, thứ nhất; thứ hai về CMOS và tổng thể | Valin và cs., Real-Time PLC with Mixed Generative and Predictive Model 2022 |
| Cùng hệ thống đó: chi phí tính toán cho mỗi 10 ms giọng nói trên CPU laptop (Intel i7-10810U) | 1,3 đến 1,4 ms, khoảng 13% đến 14% của một nhân | Valin và cs. 2022 |
Ghi chú về giá trị ngoại lệ: một hệ thống được xếp hạng có điểm CMOS thấp hơn mốc im lặng, nhắc rằng một bộ sinh được tinh chỉnh kém có thể nghe tệ hơn một khoảng trống. Bộ kiểm thử mù thiên về các chuỗi mất gói ngắn: 504 trong 966 đoạn có chuỗi mất gói tối đa lên đến 120 ms. Số liệu của hệ thống lai đến từ Valin và cs., mà cơ chế che giấu của nó sau đó đã được phát hành trong Opus 1.5 (xem phần 7).
4. Chuỗi Mất Gói Liên Tiếp Dài: Nơi Che Giấu Vẫn Thất Bại (ICASSP 2024)
Phiên bản 2024 cố ý làm nhiệm vụ khó hơn: âm thanh 48 kHz băng thông đầy đủ, được chấm điểm bằng phương pháp đa chiều ITU-T P.804 (Microsoft Research, ICASSP 2024 Audio Deep PLC Challenge), và chuỗi mất gói liên tiếp lên đến 3 giây. Ngay cả hệ thống tốt nhất cũng chỉ thu hẹp được khoảng hai phần ba khoảng cách giữa âm thanh bị mất gói và âm thanh sạch: chất lượng tổng thể tăng từ 2,37 lên 3,49, so với 4,01 của giọng nói sạch ((3,49 - 2,37) / (4,01 - 2,37) = 68%) (Microsoft, bài báo ICASSP 2024 Audio Deep PLC Challenge).
Cột nói lên nhiều nhất là tính gián đoạn, điểm P.804 cho các đứt quãng và trục trặc nghe thấy được (càng cao nghĩa là càng mượt). Nó tăng từ 2,47 lên 3,90 với hệ thống tốt nhất, một bước nhảy lớn hơn bất kỳ chiều nào khác. Che giấu sửa những lỗ hổng mà người nghe nhận ra đầu tiên, trong khi lời nói được tổng hợp vẫn làm giảm tính tự nhiên. Độ chính xác từ cũng cho thấy sự đánh đổi này: một hệ thống đồng thắng cuộc nhận dạng được 0,81 số từ, hơi thấp hơn mức 0,83 của âm thanh bị mất gói còn nguyên, một dấu hiệu cho thấy lời nói bịa ra có thể đánh lạc hướng bộ nhận dạng nhiều hơn im lặng.
| Chỉ số | Giá trị | Nguồn |
|---|---|---|
| Chất lượng tổng thể P.804 (1 đến 5): giọng nói sạch so với âm thanh bị mất gói chưa xử lý so với các hệ thống đồng thắng cuộc (1024K và NWPU & ByteAudio) | 4,01 so với 2,37 so với 3,49 và 3,44 | Microsoft, bài báo ICASSP 2024 Deep PLC Challenge |
| Điểm gián đoạn P.804: sạch so với bị mất gói so với hệ thống tốt nhất (1024K) | 4,55 so với 2,47 so với 3,90 | Microsoft, bài báo ICASSP 2024 Deep PLC Challenge |
| Độ chính xác từ: sạch so với bị mất gói so với 1024K so với NWPU & ByteAudio | 0,98 so với 0,83 so với 0,81 so với 0,84 | Microsoft, bài báo ICASSP 2024 Deep PLC Challenge |
| Hệ thống đủ điều kiện có điểm thấp hơn âm thanh bị mất gói chưa xử lý về chất lượng tổng thể P.804 | 2 trong 8 (2,11 và 2,17) | Microsoft, bài báo ICASSP 2024 Deep PLC Challenge |
| Băng thông âm thanh và phương pháp nghe thử của phiên bản 2024 | Băng thông đầy đủ, 48.000 Hz; chấm điểm đa chiều ITU-T P.804 cùng tỷ lệ lỗi từ | Microsoft Research, trang ICASSP 2024 Deep PLC Challenge |
Bối cảnh: một hệ thống thứ chín đạt điểm tổng thể 2,91 nhưng vượt giới hạn độ trễ và bị liệt kê là chưa hoàn thành. Ban tổ chức lưu ý rằng các hệ thống thời 2022 “có thể không hoạt động tốt với các chuỗi mất gói dài hơn”, và đó chính xác là nơi mã hóa dự phòng (phần 6) tiếp quản.
5. Chấm Điểm Che Giấu: Vì Sao Các Chỉ Số Chất Lượng Chung Bỏ Sót
Lỗi che giấu thì ngắn, ngắt quãng và thường hợp lý, đúng là những thứ mà các chỉ số chất lượng đa dụng không được thiết kế để bắt. Trên dữ liệu căn chỉnh theo tham chiếu, PESQ chỉ đạt hệ số tương quan Pearson theo từng mô hình là 0,52 với đánh giá của con người về các hệ thống PLC, và STOI chỉ đạt 0,21, trong khi PLCMOS đạt 0,98 (Diener và cs., bài báo PLCMOS, Microsoft, Interspeech 2023). Một chỉ số xếp hạng sai các hệ thống có thể dẫn cả một lĩnh vực nghiên cứu đi sai hướng.
PLCMOS hoạt động không cần bản tham chiếu sạch, điều quan trọng với các cuộc gọi thực, nơi âm thanh gốc không bao giờ có ở bên nhận. Điểm yếu của nó là độ chính xác ở mức tệp: 0,85 cho mỗi đoạn so với 0,97 cho mỗi hệ thống, nên nó xếp hạng các thuật toán tốt hơn nhiều so với việc đánh giá một cuộc gọi đơn lẻ. Sự giằng co tương tự xuất hiện trong việc chấm điểm giọng nói tổng hợp, được đề cập trong thống kê MOS về độ tự nhiên của giọng nói tổng hợp của chúng tôi.
| Chỉ số | Giá trị | Nguồn |
|---|---|---|
| PLCMOS so với đánh giá của con người: tương quan Pearson và tương quan hạng theo từng mô hình | Khoảng 0,97 và khoảng 0,95 | Diener và cs., bài báo PLCMOS 2023 |
| DNSMOS (chỉ số chung về khử nhiễu): tương quan Pearson theo từng tệp so với theo từng mô hình | 0,52 so với 0,85 | Diener và cs., bài báo PLCMOS 2023 |
| PESQ so với PLCMOS trên dữ liệu căn chỉnh theo tham chiếu: tương quan Pearson theo từng mô hình | 0,52 so với 0,98 | Diener và cs., bài báo PLCMOS 2023 |
| STOI (chỉ số về khả năng nghe hiểu): tương quan Pearson theo từng mô hình | 0,21 | Diener và cs., bài báo PLCMOS 2023 |
| Số phiếu bầu của con người trong bộ huấn luyện chính của PLCMOS (LibriSpeech Basic) | 333.740 | Diener và cs., bài báo PLCMOS 2023 |
| Số tệp kiểm thử trong bộ kiểm thử nghe codec học máy của IETF | 100 giọng nói sạch, 90 có nhiễu hoặc vang, 20 có nhiều người nói chồng lấn | IETF draft-ietf-mlcodec-test-battery-00, tháng 6 năm 2026 |
Bối cảnh: điểm đánh giá từ cộng đồng có tương quan với điểm của chuyên gia khoảng 0,83 PCC (khoảng tin cậy 95%: [0,78, 0,87]) trong nghiên cứu sơ bộ gán nhãn của PLCMOS. Bản thảo bộ kiểm thử của IETF vẫn liệt kê các kịch bản mất gói tin của nó là “Chi tiết sẽ xác định sau (TBD)”, nên hiện chưa có bài kiểm thử mất gói chuẩn cho các codec nơ-ron.
6. Mã Hóa Dự Phòng: Trả Thêm Bit Để Tránh Phải Che Giấu
Che giấu thì đoán; dự phòng thì gửi bản sao lưu. Sửa lỗi chuyển tiếp (FEC) nghĩa là gắn một bản sao chất lượng thấp hơn của âm thanh trước đó vào các gói tin sau, để gói bị mất có thể được dựng lại thay vì bịa ra. Cái giá phải trả là băng thông. FEC trong băng cổ điển của Opus (LBRR) chỉ bao phủ một khung ở mức khoảng 2/3 tốc độ bit thông thường, trong khi Deep REDundancy (DRED) mang tới một giây hoặc hơn ở mức khoảng 1/50 tốc độ bit thông thường (IETF draft-ietf-mlcodec-opus-dred-07, tháng 8 năm 2026).
Cách tiếp cận RED cũ hơn cho thấy quy mô của hiệu ứng. Trong một bài thử trên Chrome ở mức mất gói 20%, việc gửi một khung trước đó trong mỗi gói tin đã giảm tỷ lệ âm thanh bị che giấu từ 18% xuống 4%, và hai khung trước đó giảm nó xuống 0,7% (webrtcHacks, RED: Improving Audio Quality with Redundancy 2020). Chi phí: âm thanh tăng từ khoảng 30 kbps lên 60 kbps với một bản sao và 90 kbps với hai bản. DRED ra đời để có sự bảo vệ tương tự mà không nhân đôi tốc độ bit.
| Chỉ số | Giá trị | Nguồn |
|---|---|---|
| FEC trong băng LBRR của Opus: độ sâu dự phòng và chi phí tốc độ bit | 1 khung; khoảng 2/3 tốc độ bit Opus thông thường | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Opus DRED: độ sâu dự phòng và chi phí tốc độ bit | Tới một giây hoặc hơn cho mỗi gói tin; khoảng 1/50 tốc độ bit thông thường | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Đánh giá DRED: lượng dự phòng mang theo mỗi gói tin và số lần mỗi khung được gửi | 1,04 giây; 52 bản sao | Valin và cs., bài báo DRED (arXiv 2212.04453 v3, 2024) |
| Tốc độ bit của điều kiện thử LBRR trong đánh giá DRED (nền 24 kb/s cộng LBRR) | Tổng 40 kb/s, LBRR trung bình khoảng 16 kb/s | Valin và cs., bài báo DRED 2024 |
| Tỷ lệ âm thanh bị che giấu ở mức mất gói 20% trên Chrome: không RED so với một khung trước đó so với hai khung trước đó | 18% so với 4% so với 0,7% | webrtcHacks, bài thử RED của Hancke 2020 |
| Tỷ lệ âm thanh bị che giấu ở mức mất gói ngẫu nhiên 60%: không RED so với một so với hai khung trước đó | 60% so với 32% so với 18% | webrtcHacks, bài thử RED của Hancke 2020 |
| Tốc độ bit Opus tối thiểu để mã hóa FEC trong băng ở mức mất gói tin 10% | 19 kbps (so sánh của chính nhà cung cấp) | Meta Engineering, blog codec MLow 2024 |
| Tốc độ bit của các mẫu MLow của Meta khi mất gói tin 30% phía bên nhận | 14 kbps (tuyên bố của chính nhà cung cấp) | Meta Engineering, blog codec MLow 2024 |
Bối cảnh: các số liệu của webrtcHacks đến từ một bài thử nghiệm phòng thí nghiệm của một tác giả năm 2020 (phép đo công khai mới nhất hiện có về RED trên Chrome). Số liệu của Meta đến từ thông báo MLow của chính họ và chưa được tái lập độc lập. Mọi khác biệt của DRED trong bài nghe thử P.808 của bài báo (966 câu nói, mỗi câu 10 người nghe) đều được báo cáo là có ý nghĩa ở mức p < 0,05.
7. Triển Khai Che Giấu: Tính Toán, Dung Lượng và Tiêu Chuẩn
Một mô hình che giấu chỉ có ý nghĩa nếu nó chạy được trên chiếc điện thoại rẻ nhất trong cuộc gọi. Deep PLC của Opus 1.5 tốn khoảng 1% của một nhân CPU laptop ở mức mất gói cao và thêm khoảng 1 MB vào thư viện (Xiph.Org, bản demo Opus 1.5, tháng 3 năm 2024, số liệu do chính các nhà phát triển cung cấp). Bài dự thi năm 2022 của cùng nhóm cần 13% đến 14% của một nhân (phần 3), dù hai con số được đo theo cách khác nhau và không phải là phép so sánh tương đương hoàn toàn.
Ngược lại, tầng tiêu chuẩn gần như không nhúc nhích. Các quy tắc âm thanh của WebRTC (RFC 7874, 2016) bắt buộc dùng Opus và G.711 nhưng không đặt yêu cầu nào về che giấu hay FEC, để chất lượng khi mất gói hoàn toàn tùy thuộc vào từng bản triển khai. Opus 1.6 tiếp tục thu nhỏ các mô hình: mạng DRED của nó nhỏ hơn khoảng 3 lần so với trong 1.5 (Xiph.Org, bản demo Opus 1.6, tháng 12 năm 2025).
| Chỉ số | Giá trị | Nguồn |
|---|---|---|
| Deep PLC của Opus 1.5: dung lượng thư viện tăng thêm và chi phí CPU | Khoảng 1 MB; khoảng 1% của một nhân laptop khi mất gói cao; cần độ phức tạp bộ giải mã từ 5 trở lên | Xiph.Org, bản demo Opus 1.5 2024 (số liệu do chính nhà phát triển cung cấp) |
| DRED của Opus 1.5: dung lượng thư viện tăng thêm, chi phí khi chạy và chi phí phụ trội tốc độ bit | Khoảng 2 MB; khoảng 1%; khoảng 12 đến 32 kb/s | Xiph.Org, bản demo Opus 1.5 2024 (số liệu do chính nhà phát triển cung cấp) |
| Bộ mã hóa giọng nói nơ-ron FARGAN dùng để tổng hợp lời nói được che giấu và dự phòng: độ phức tạp | 600 MFLOPS, 1/5 của LPCNet | Xiph.Org, bản demo Opus 1.5 2024 |
| Tỷ lệ mất gói trong các bài thử WebRTC của Opus 1.5 (PLCMOS v2) | 0% đến 90% theo bước 10%; DRED được báo cáo giữ được chất lượng ở mức mất gói 90% | Xiph.Org, bản demo Opus 1.5 2024 (tuyên bố của chính nhà phát triển) |
| Kích thước mô hình DRED của Opus 1.6 so với Opus 1.5 | 600 kB so với 1.800 kB | Xiph.Org, bản demo Opus 1.6, tháng 12 năm 2025 |
| Kích thước khung Opus, độ dài gói tin và dải tốc độ bit | Khung 2,5 đến 60 ms; gói tin lên đến 120 ms; 6 đến 510 kbit/s | IETF RFC 6716 (2012) |
| Độ trễ thuật toán của Opus | 5 ms đến 65,2 ms | IETF RFC 6716 (2012) |
| Các codec mà điểm cuối WebRTC phải hỗ trợ | Opus và G.711 (PCMA và PCMU); không có yêu cầu về PLC hay FEC | IETF RFC 7874 (2016) |
Bối cảnh: RFC 6716 và RFC 7874 đã hơn ba năm tuổi nhưng vẫn là các tiêu chuẩn hiện hành (RFC 6716, RFC 7874). Bản thảo DRED, nếu được phê duyệt, sẽ cập nhật RFC 6716 bằng một lớp dự phòng nơ-ron.
Tổng kết: Che Giấu Mất Gói Tin Âm Thanh WebRTC Qua Các Con Số
| Chỉ số | Giá trị | Nguồn |
|---|---|---|
| Cuộc gọi Google Duo phải xử lý tình trạng mất gói tin, jitter hoặc độ trễ | 99% | Google Research, blog WaveNetEQ 2020 |
| Cuộc gọi Duo mất hơn 8% âm thanh | 10% | Google Research, blog WaveNetEQ 2020 |
| Ngưỡng Poor của Teams cho tỷ lệ mất gói âm thanh trung bình | Trên 0,1 (10%) | Microsoft Learn, CQD Stream Classification 2026 |
| Ngưỡng thẻ high_packet_loss của Twilio | Trên 5% | Twilio Voice Insights, Details: Call Tags |
| Hệ số chống chịu Bpl của G.711: không che giấu so với che giấu Appendix I | 4,3 so với 25,1 | ITU-T G.113 (09/2024) |
| G.729 Annex A với phát hiện hoạt động giọng nói: Bpl | 19,0 | ITU-T G.113 (09/2024) |
| PLCMOS cuộc thi 2022: điền số không so với hệ thống thắng cuộc so với sạch | 2,90 so với 4,28 so với 4,51 | Microsoft, bài báo INTERSPEECH 2022 Deep PLC Challenge |
| Độ chính xác từ cuộc thi 2022: điền số không so với hệ thống thắng cuộc so với sạch | 0,86 so với 0,88 so với 0,97 | Microsoft, bài báo INTERSPEECH 2022 Deep PLC Challenge |
| Chi phí tính toán của PLC lai nhóm Opus cho mỗi 10 ms giọng nói | 1,3 đến 1,4 ms (13% đến 14% của một nhân) | Valin và cs. 2022 |
| Chất lượng tổng thể P.804 cuộc thi 2024: bị mất gói so với tốt nhất so với sạch | 2,37 so với 3,49 so với 4,01 | Microsoft, bài báo ICASSP 2024 Deep PLC Challenge |
| Hệ thống cuộc thi 2024 có điểm thấp hơn âm thanh bị mất gói chưa xử lý | 2 trong 8 | Microsoft, bài báo ICASSP 2024 Deep PLC Challenge |
| Tương quan Pearson theo từng mô hình của PLCMOS với đánh giá của con người | Khoảng 0,97 | Diener và cs., bài báo PLCMOS 2023 |
| Tương quan Pearson theo từng mô hình của PESQ so với STOI trên các hệ thống PLC | 0,52 so với 0,21 | Diener và cs., bài báo PLCMOS 2023 |
| Độ sâu dự phòng của LBRR so với DRED | 1 khung so với tới một giây hoặc hơn | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Tốc độ bit dự phòng của DRED so với Opus thông thường | Khoảng 1/50 | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Âm thanh bị che giấu ở mức mất gói 20%: không RED so với RED hai khung | 18% so với 0,7% | webrtcHacks, bài thử RED của Hancke 2020 |
| Tốc độ bit FEC trong băng tối thiểu của Opus ở mức mất gói 10% | 19 kbps (so sánh của chính nhà cung cấp) | Meta Engineering, blog codec MLow 2024 |
| Chi phí CPU của Deep PLC Opus 1.5 | Khoảng 1% của một nhân laptop | Xiph.Org, bản demo Opus 1.5 2024 |
| Kích thước mô hình DRED của Opus 1.6 so với 1.5 | 600 kB so với 1.800 kB | Xiph.Org, bản demo Opus 1.6 2025 |
Phương pháp luận và Nguồn
- Microsoft Research, bài báo INTERSPEECH 2022 Audio Deep Packet Loss Concealment Challenge (Diener và cs., 2022): arxiv.org/pdf/2204.05222
- Microsoft Research, bài báo ICASSP 2024 Audio Deep Packet Loss Concealment Challenge (2024): arxiv.org/html/2402.16927v1
- Microsoft Research, trang chương trình ICASSP 2024 Audio Deep PLC Challenge: microsoft.com
- Diener và cs., PLCMOS: a data-driven non-intrusive metric for the evaluation of packet loss concealment algorithms (Interspeech 2023): arxiv.org/pdf/2305.15127
- Valin và cs., Real-Time Packet Loss Concealment With Mixed Generative and Predictive Model (2022): arxiv.org/pdf/2205.05785
- Valin và cs., 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 (tháng 8 năm 2026): ietf.org
- IETF, ML codec listening test battery, draft-ietf-mlcodec-test-battery-00 (tháng 6 năm 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 (Candidate Recommendation Draft, ngày 25 tháng 9 năm 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 (tháng 4 năm 2020): research.google
- Microsoft Learn, Stream Classification in Call Quality Dashboard (cập nhật tháng 6 năm 2026): learn.microsoft.com
- Microsoft Learn, Dimensions and measures available in Call Quality Dashboard (cập nhật tháng 7 năm 2026): learn.microsoft.com
- Twilio, Voice Insights Details: Call Tags: twilio.com
- Meta Engineering, MLow: Meta’s low bitrate audio codec (tháng 6 năm 2024): engineering.fb.com
- Xiph.Org, bản demo Opus 1.5 (tháng 3 năm 2024) và bản demo Opus 1.6 (tháng 12 năm 2025): opus-codec.org/demo/opus-1.5, opus-codec.org/demo/opus-1.6
- webrtcHacks, RED: Improving Audio Quality with Redundancy (Philipp Hancke, tháng 8 năm 2020): webrtchacks.com
- Lưu ý về dữ liệu: phân bố mất gói ở cấp độ cuộc gọi duy nhất từ một nền tảng lớn là số liệu Duo năm 2020 của Google, và các phép đo che giấu RED là một bài thử của một tác giả năm 2020, nên cả hai đều được đánh dấu là dữ liệu mới nhất hiện có. Ví dụ mô hình E ở phần 2 là phép tính của chính chúng tôi từ Phương trình 7-29 và Annex B của ITU-T G.107 với các giá trị Bpl của G.113, giữ mọi đầu vào khác ở giá trị mặc định; đó là ước tính chứ không phải phép đo. Điểm số các cuộc thi không thể so sánh giữa các phiên bản: năm 2022 dùng âm thanh băng rộng, PLCMOS và CMOS với chuỗi mất gói liên tiếp lên đến 1 giây, còn năm 2024 dùng âm thanh băng thông đầy đủ, P.804 và chuỗi mất gói liên tiếp lên đến 3 giây. Trong bài báo năm 2022, PLCMOS tương quan với CMOS ở mức khoảng 0,95 Pearson, trong khi bản phát hành PLCMOS sau đó báo cáo khoảng 0,97 trên một bộ đánh giá khác. Số liệu của Xiph.Org và Meta là tuyên bố của chính các nhà phát triển. Các ngưỡng của Teams (10%) và Twilio (5%) mâu thuẫn nhau theo thiết kế vì mỗi nhà cung cấp điều chỉnh chúng theo nền tảng truyền thông của riêng mình. Bản thảo DRED (hết hạn tháng 2 năm 2027) và bản thảo bộ kiểm thử của IETF, vốn có các kịch bản mất gói tin vẫn chưa được xác định, có thể thay đổi trước khi được công bố thành RFC.
Cập nhật lần cuối: ngày 24 tháng 10 năm 2026. Chúng tôi cập nhật bài tổng hợp này hàng quý, và lần làm mới tiếp theo dự kiến diễn ra khi nhóm làm việc mlcodec của IETF công bố bản sửa đổi tiếp theo của bản thảo Opus DRED và các kịch bản mất gói tin của bộ kiểm thử.