跳到正文
#Google
  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 阈值取舍的实测依据。

  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 神经回声消除器，给出回声抑制与语音识别词错率的对照结果。

  1. Google AI Blog58

    Made on YouTube 2026：直播粉丝赞助、配音等新工具发布

    YouTube 在 Made on YouTube 2026 活动中宣布一批直播工具更新，聚焦粉丝赞助与自动配音等方向，延续其在直播互动与多语言能力上的投入。

    推荐理由：YouTube 年度创作者大会的直播相关产品发布，代表其直播产品路线。

  1. Hume AI Blog62

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

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

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

  1. Google AI Blog62

    Google 发布 Gemini 3.8 Live 与 3.5 转写模型

    Google 在 Gemini API 与 AI Studio 上线 Gemini 3.8 Live、3.8 Live Extended Thinking 与 3.5 Transcribe：3.8 Live 为原生语音到语音模型，支持异步函数调用（后台执行工具调用同时继续流式输出音频）、视觉上下文与 97+ 语言；3.8 Live Extended Thinking 在 Artificial Analysis 的 Speech-to-Speech 榜单排名第一；3.5 Transcribe 覆盖 85+ 语言，官方给出平均 WER 4.0%（流式）与 2.6%（非流式）。

    推荐理由：实时语音链路上游模型的关键更新，直接影响语音 Agent 与实时转写方案的选型。

  1. Google AI Blog66

    Chrome 153 新增摄像头/麦克风专用 HTML 元素并支持 IAMF 沉浸式音频解码

    Chrome 153 加入摄像头与麦克风专用 HTML 元素（浏览器托管 UI，需显式点击授权），并通过 MSE 在 HTML 媒体元素中支持开放免版税空间音频格式 IAMF 的解码播放。

    推荐理由：浏览器媒体采集与沉浸式音频格式的双重进展，直接影响 Web 音视频应用形态。

  1. Google AI Blog56

    Google 扩展 SynthID 与内容凭证的媒体溯源覆盖

    Google 公布内容透明度工具进展：SynthID 不可见水印已用于 AI 生成的图像、视频与音频，累计标注超过 1000 亿张图像/视频与 6 万年时长的音频；C2PA Content Credentials 从 Pixel 10 相机扩展到 Pixel 8/9/10 的视频拍摄。SynthID 验证已在 Gemini App 使用 5000 万次，并扩展到 Search 与 Chrome 的“Is this made with AI?”查询；OpenAI、Kakao、ElevenLabs 将引入 SynthID，Google Cloud 上线 AI Content Detection API。

    推荐理由：AI 生成媒体的水印与溯源正在成为音视频平台的合规基础设施，该更新给出规模化数据。

  1. Google AI Blog76

    Google 等三方联合发布 HDR 标准 SMPTE ST 2094-50

    为解决 HDR 与 SDR 内容同屏混排时高光裁切、画面发灰，以及环境光变化导致显示亮度漂移的问题，Google 联合 Apple、NBCUniversal 制定 SMPTE ST 2094-50：一是用 Reference White Anchor 把普通内容的最亮部分映射到固定基线、把额外亮度留给 HDR；二是 Headroom-Adaptive Gain Curves，把适配指令写进视频文件，屏幕余量不足时按创作者意图压缩暗部与中间调以保留高光细节。

    推荐理由：跨厂商的新 HDR 元数据标准，直接决定 HDR 视频在不同亮度屏幕与光照环境下的呈现。

  1. Google AI Blog57

    Chrome 148 为视频与音频元素引入延迟加载

    Chrome 148 将视频与音频元素的延迟加载纳入默认功能集，此外还包含 CSS 名称限定容器查询、Prompt API、WebRTC 数据通道始终协商等更新。

    推荐理由：媒体元素 lazy loading 进入稳定版，影响视频站点的加载策略与带宽优化。

  1. Google AI Blog62

    YouTube Live 四项更新：横竖屏同播共享聊天、礼物扩展与互动高峰自动避广告

    YouTube Live 更新四项能力：横屏直播也可收礼物并扩展至加拿大、韩国等更多市场，Super Chat/礼物触发个人无广告窗口，互动高峰自动暂停广告，并支持横竖屏同时开播且共用一个聊天室——官方披露 2025 年美国 30% 以上直播观看时长来自联网电视。

    推荐理由：YouTube 直播形态与变现机制的重要调整，CTV 占比数据对行业有参考意义。

  1. Google AI Blog60

    Chrome 推出浏览器发起的自动画中画：未注册媒体会话处理程序的网站也可自动 PiP

    Chrome 引入浏览器发起的自动画中画：对未注册媒体会话操作处理程序的网站，切标签页时也可自动弹出视频 PiP；触发条件严格限定，包括媒体两秒内有声、未使用摄像头/麦克风、用户媒体互动指数超阈值等。

    推荐理由：浏览器播放器行为的重要变化，视频/音乐类 Web 应用需关注触发条件与隐私设定。

  1. Google AI Blog68

    YouTube 自动作配音扩展至 27 种语言：Expressive Speech 八语种上线并试点唇形同步

    YouTube 宣布自动配音面向所有创作者开放并扩展至 27 种语言：2025 年 12 月日均超 600 万观众观看 10 分钟以上自动配音内容；Expressive Speech 在英法德等 8 种语言上线以保留情绪表达，同时新增观众偏好语言设置与音乐/静音视频智能过滤，唇形同步处于试点阶段。

    推荐理由：全球最大视频平台的 AI 配音规模化数据与功能边界，是配音行业与 AI 增强的风向标。

  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 公开语音智能体基准的源码与结果，可看到长多轮对话下模型能力与延迟之间的取舍。

已经到底了