跳到正文

内容形态

评测基准 最新动态

到底谁更强：编解码器与媒体的客观质量、速度、压缩率对比，以及评测方法的讨论。

19 条精选近 30 天 3 条共收录 50 条

更新

评测基准的精选

10月8日周四第 1–19 条
  1. webrtcHacks74

    实测：Chrome 新回声消除器把语音代理自问自答率降到 Edge 的五分之一

    Chrome 新的 ML 残差回声估计器把语音代理的单词错误率减半，也减少了代理应答自己问候语的情况。作者用 Hugging Face speech-to-speech 搭建语音代理，在相同房间、麦克风和服务器下交替使用 Edge 与 Chrome 各跑一百多次：回声被 STT 当成用户语音的比例为 Edge 21%、Chrome 4%，失败都发生在会话开始后 1.0 到 2.2 秒之间。dump 显示问候语第一段被抑制 51 到 58 dB，约一秒后的第二段却以高于播放 7 到 13 dB 的电平上行，增益控制器在此期间把自适应数字增益从 15 dB 调高，放大了漏出的回声。作者还指出 min_speech_ms 从 500 ms 降到 384 ms 后，三次失败落在 384 到 500 ms 之间，而 smart-turn-v3 以 0.954 的置信度判定回声已说完，说明问题出在流水线看不到的浏览器组件。

    推荐理由：作者用 AEC dump 对比 Chrome 与 Edge 的语音代理自问自答率，并给出 VAD 阈值取舍的实测依据。

10月6日周二
  1. webrtcHacks80

    Chrome 静默上线神经回声消除器，实测回声抑制提升 5.4 dB

    Google Chrome 桌面版在用户不知情的情况下下载了一个 425 KB 的 TFLite 模型，接管 AEC3 中残差回声估计部分，默认开启且无开关，仅 Chrome 可用，Edge、Electron、Firefox 和 Safari 都拿不到。作者用 Microsoft AEC Challenge 合成语料的约 500 个文件跑 audioproc_f 对比，远端单讲帧的中位回声抑制从 19.8 dB 升到 27.0 dB，每文件中位提升 5.4 dB，80% 文件更好，双讲时近端电平基本不变（中位 +0.04 dB）。在 125 个文件上用 Whisper small.en 测试语音代理场景，中位词错率从 0.500 降到 0.235。

    推荐理由：作者用 AEC Challenge 语料实测 Chrome 神经回声消除器，给出回声抑制与语音识别词错率的对照结果。

9月17日周四
  1. Hume AI Blog62

    Hume 发布语音可控性排行榜，评测 17 个 TTS 模型

    Hume 发布 Voice Controllability Leaderboard，从语音设计、语音指令和角色契合三个维度评测 17 个 TTS 模型，采用数万条人工评分而非 LLM 评委，理由是后者可能因数据泄漏抬高分数。结果显示没有单一模型在所有可控性维度领先：Google 与 ElevenLabs 总体领先但各有短板，开源模型在语音设计上仍有竞争力；性别平均准确率 97.87%，年龄仅 51.8%，讽刺是最难传达的语气。

    推荐理由：榜单用数万条人工评分对比 17 个语音模型的可控性，并指出 LLM 评委可能因数据泄漏抬高分数。

9月14日周一
  1. Tavus Blog71

    Tavus 发布 Sparrow-2 对话理解模型，在 TurnBench 轮次切换两项任务上领先

    Tavus 发布音频原生、流式优先的多语言对话理解模型 Sparrow-2，不再依赖降噪和静音计时器，而是保留并分类背景语音、噪声、反馈语和打断等信号，联合建模语义、韵律与说话人身份。在独立基准 TurnBench 的公开 dev split（38 段对话、7.3 小时音频）上，它取得 92.4% 的轮次结束召回和 97.4% 的打断召回，是唯一同时领先两项任务的系统，中位决策延迟 632 ms，7.6% 的轮次结束未被响应。模型以 10 ms 帧率运行，处理 80 ms 音频约需 7 ms，可容忍 6 至 8 秒的思考停顿，现已通过 Tavus API 和平台正式可用。

    推荐理由：Sparrow-2 把轮次切换从端点检测改为整体对话状态建模，并给出与十四套系统的基准对比，可据此判断语音智能体在嘈杂环境中的可用边界。

9月10日周四
  1. Hume AI Blog62

    Hume 发布语音复刻排行榜，评测 11 个 TTS 模型的克隆效果

    Hume 发布 Voice Replication Leaderboard，作为 Real World VoiceEQ Benchmark 的新组件，用 25 条参考语音和 7 条提示词评测 11 个 TTS 模型的语音复刻能力，评分维度包括同一说话人、音质、自然度和 TitaNet 说话人嵌入余弦相似度。结果显示没有模型在所有维度领先：Cartesia sonic-3.6-beta 自然度最高（4.36）但同一说话人仅排第八（3.63），OpenBMB VoxCPM2 同一说话人第一（4.21）而自然度第五（3.96）；音质分数集中在 3.85 至 4.61，同一说话人分数跨度更大，为 2.91 至 4.21。

    推荐理由：榜单把说话人相似度、自然度、音质和客观相似度分开评测，并给出按口音与情绪拆分的对比，可供选型时参考。

8月28日周五
  1. Inworld AI Blog62

    Inworld 开源 TTS 评测工具包：配置随结果存档、分数可溯源到样例与 ASR 转写

    Inworld 开源 TTS Open Evaluation Toolkit：离线采样各 TTS 系统并生成可对比报告，每次运行把配置与逐样例测量一起存档，用户可从分数回溯到源文本、音频、ASR 转写与所用阈值；首发包含常见指标与一套专门的英语对话压力测试集。针对同模型不同团队测出不同 WER（因 ASR 选择、文本归一化、失败样例取舍）这一评测不可复现问题。

    推荐理由：直击 TTS 评测不可复现的痛点，把协议与测量绑定存档的做法对建立可比基准有实际价值。

7月22日周三
  1. AWS Media Blog62

    AWS 对比 NDI SpeedHQ 与 JPEG XS 的编解码画质基准

    AWS 对 NDI SpeedHQ 和 JPEG XS 两种中间编解码器做了独立画质基准测试，测量 PSNR、码率和多代编解码损失。测试用 Netflix Sparks 素材的 600–1200 帧、4:2:2 色度采样、60 fps，在 Amazon EC2 C6id.12xlarge 上运行，NDI 用 Advanced SDK 6.3.1，JPEG XS 用 IntroPix CPU Codec 2.40.1。结果显示 JPEG XS 在低压缩比下绝对画质更高但码率更大，NDI SpeedHQ 在低码率下略优且存在质量上限；两者在连续八代编解码中 PSNR 损失均低于 0.5 dB。

    推荐理由：AWS 用统一流程对比 NDI SpeedHQ 与 JPEG XS 的画质、码率和代际损失，可据此判断长信号链下选哪种中间编解码器。

7月15日周三
  1. 声网博客74

    声网首测 GPT-Live：响应延迟中位数 1099ms、波动缩 5 倍

    Agora 实验室用 iPhone 13 加人工发声设备、可控网络模拟丢包、双轨录音逐帧取时、每项 n=30 的方法测试三代 ChatGPT 语音模式：GPT-Live-1 正常网络中位响应 1099ms（P90 1203ms、SD 104ms），Advanced Voice Mode 为 1304ms（P90 2318ms、SD 489ms），Standard 级联模式 5197ms；10% 上行丢包下 GPT-Live 仅增 314ms，同级丢包的 P90 仍优于零丢包的上一代；插话停止延迟中位数 1399ms 比上一代慢 498ms，但背景人声误触发从 22 次降到 1 次。

    推荐理由：方法论透明、样本量与局限都交代清楚的端到端延迟实测，弱网下的对比尤其有信息量。

  2. 海外技术动态58

    Phoronix 99 项基准对比三系统：SVT-AV1/OpenAPV 编码 Linux 领先 Windows 11

    Phoronix 在 Core Ultra 9 290HX + RTX 5090 的 Razer Blade 18 上对比 Ubuntu 26.04 LTS、Windows 11 与 CachyOS 共 99 项测试：视频编码方面 Linux 明显占优，Ubuntu/CachyOS 在 OpenAPV 编码的全部设置下压制 Windows 11，AV1（SVT-AV1）编码同样领先，而 Kvazaar H.265 的 1080p 档位下 Windows 11 反而最快；综合几何平均 Windows 11 与 CachyOS 基本持平，但本地 AI/LLM 负载 Windows 11 有约 3 倍的性能优势场景。

    推荐理由：覆盖 SVT-AV1、OpenAPV、Kvazaar 三类编码器的受控系统级实测，为编码农场操作系统选型提供量化依据。

7月10日周五
7月2日周四
  1. 中文技术动态60

    腾讯云 Tencent-RTC 云游戏实践：稳定网络端到端 50-70ms

    腾讯云游戏用自研 Tencent-RTC 做抗抖动与网络自适应：发送端缓存视频帧、接收端按网络动态调缓冲深度，并用预测算法生成中间帧补偿丢包；传输上基于 UDP 并叠加 FEC 与 ARQ，按数据类型（游戏指令、视频帧、音频）设差异化优先级；量化表现为稳定网络下端到端 50-70ms，盛趣游戏案例做到 1080P/60 帧下延迟小于 40ms，全球部署 2000+ 边缘节点。

    推荐理由：云游戏这一延迟最敏感场景的厂商实测数据与机制说明，40ms/1080P60 的案例有参考价值。

6月20日周六
  1. Netflix Technology Blog78

    Netflix 开源 VMAF v1：修正压缩伪影偏置与色带盲区，NEG 默认开启

    Netflix 发布 VMAF v1（模型随 libvmaf v3.2.0 于 2026-06-20 上线）：在 DLM 基础上加入 AIM 分量以修正 v0 低码率下偏向切高分辨率、偏爱压缩伪影的系统性偏差；以基于归一化观看距离的特征调整取代 v0 手机模型的二阶多项式映射，避免手机端画质高估；整合 CAMBI 色带检测与色度特征，并将 NEG（抑制增强处理虚增分数）默认开启。v1 提供 1080p、phone、4K 近距/常规观看距离模型，HDR 版本在开发中。

    推荐理由：VMAF 是行业事实上的编码评估标准，v1 对系统误差的修正会改变各家的码率梯设计与编码器对比结论。

6月4日周四
  1. Daily.co Blog74

    NVIDIA 发布开源多语言语音识别模型 Nemotron 3.5 ASR

    NVIDIA 发布多语言语音转文字模型 Nemotron 3.5 ASR，同时提供多语言版和仅英文版 Nemotron 3 ASR 检查点，完全开源、可微调并支持自托管。作者在 Pipecat stt-benchmark 中测得该多语言模型速度超过基准中其他模型且准确率尚可，仅英文版速度相当、准确率接近当前最高分模型。延迟可通过音频处理 chunk size 调节，在 NVIDIA L40S 上以最低延迟配置可安全承载约 96 路并发转写，作者估算企业自托管成本约 $0.05/小时，而主流转写 API 通常为 $0.10-$1.00/小时。

    推荐理由：作者用开源基准给出 Nemotron 3.5 ASR 的延迟与准确率位置，并附自托管成本与并发配置，便于评估语音代理选型。

5月20日周三
  1. LiveKit Blog64

    LiveKit 实测：叠加摄像头与屏幕共享后音频质量是否劣化

    针对“开视频会拖累音频”的外部说法，作者在 LiveKit Cloud 上做三组 60 秒对照测试：纯音频时约 50kbps、0% 丢包、约 7ms 抖动、约 27ms RTT；加入 720p 摄像头（2.3Mbps）和屏幕共享（合计 3.9Mbps）后音频的码率、丢包、抖动、RTT 均无变化，视频侧则自动降码率；作者同时列明局限：单设备、单地点、理想网络、仅测音频带宽/丢包/抖动。

    推荐理由：用可复现的对照实验回应具体性能质疑并如实标注测试边界，是少见的音频质量实证。

5月19日周二
  1. 海外技术动态70

    H.264/HEVC/VP9/AV1 对比评测：从 BD-rate 到按观众分布的盈亏平衡点

    Jan Ozer 的编码器对比研究引入盈亏平衡与上下文 ROI 分析：在 1080p60 体育等内容上，AV1 对 H.264 的 BD-rate 达 -59.83%、HEVC 为 -31.48%，但按真实观众分布加权后节省缩水——高端观众为主的分布约剩 51%，移动端为主的分布 AV1 对 H.264 仅 -23.16%（对应 VMAF +6.96 的画质提升）；测得各编解码器的盈亏平衡观看时长（如移动分布下 VP9 为 3188 小时、AV1 为 4099 小时），并给出 25 万观看小时下的净节省金额。

    推荐理由：把编解码对比从单一 BD-rate 数字推进到按观众分布的 ROI 建模，方法与数据对部署决策都有直接用处。

4月8日周三
  1. 声网博客66

    声网泛 IPC 弱网方案：80% 丢包下保画面与 5 秒连通率 99.5%

    针对家庭摄像头、割草机等天然弱网部署场景，声网以 SD-RTN 为骨架做四层对抗：秒级网络感知与动态路由、秒级降码率加渐进恢复、FEC+NACK 双保险（称音频可抗 80% 丢包、视频 40%）、以及首帧关键帧优化；对外指标包括 80% 丢包下音视频流畅、设备 5 秒连通率 99.5%、出海首次激活成功率 >99.9%，SD-RTN 全球延时中位数 <76ms。

    推荐理由：厂商披露的极端弱网量化指标与全链路对抗逻辑，对 IPC/IoT 类产品选型有直接参考。

3月30日周一
  1. 声网博客64

    声网 IPC 秒开实践：Chrome 端首帧压到 300ms 以内

    声网把首帧定义为“视频第一帧在本地渲染显示”的结果指标，从关键帧触发、建链协商、路径选择、终端渲染四处下手：建议引擎提前创建初始化、enableVideo 前设好编码配置，参考最佳实践后 Windows/macOS Chrome 首帧最低可降到 300ms 以内；方案整体给出 99.9% 连通成功率、SD-RTN 覆盖 200+ 国家、全球延时中位数 <76ms、80% 丢包下仍流畅。

    推荐理由：有明确数字的首帧优化案例，且强调弱网与跨国条件下的首帧成立概率。

2月13日周五
  1. Daily.co Blog71

    Pipecat 发布语音智能体 STT 基准：对比 10 家服务的延迟与语义准确率

    Pipecat 团队发布面向实时语音智能体的 STT 基准，在 1000 条真实人类语音样本上测试 10 家 STT 服务，同时衡量转写延迟（TTFS）与语义准确率。中位延迟上 Deepgram Nova 3（247ms，1.62% WER）、Soniox（249ms，1.29% WER）、Speechmatics（495ms，1.07% WER）位于帕累托前沿。基准用 Claude 做语义 WER 评估，只统计会导致 LLM 理解不同的错误，并强调 P95 延迟与 finalization 支持比中位数更影响对话体验；代码已在 GitHub 开源，Pipecat 0.0.102 起可设置 ttfs_p99_latency 参数。

    推荐理由：Pipecat 团队用 1000 条真实语音对比 10 家 STT 服务的延迟与语义准确率，并给出可自行复现的基准工具。

2月2日周一
  1. Daily.co Blog60

    Daily 发布语音智能体 LLM 基准 aiwf_medium_context，测试长多轮工具调用与延迟

    Daily 发布语音智能体基准 aiwf_medium_context，测试文本模式 LLM 与语音到语音模型在约 30 轮长对话中的工具调用、指令遵循和知识引用，源码已在 GitHub 开源。结果显示已有三个模型在该基准上各项指标达到 100%，但都太慢，无法满足语音智能体所需的 1500ms 以内语音到语音响应（约对应文本模型 700ms TTFT）；生产中最常用的仍是 GPT-4.1 和 Gemini 2.5 Flash，AWS Nova 2 Pro 在性能与延迟上与之持平。语音到语音模型中 Ultravox 0.7 表现突出，GPT Realtime 通过率为 86.7%，低于 GPT-4.1 的 94.9%。

    推荐理由：Daily 公开语音智能体基准的源码与结果，可看到长多轮对话下模型能力与延迟之间的取舍。