WebCodecs 浏览器能力与隐私
了解 WebCodecs 暴露的媒体处理支持、浏览器与平台差异，以及如何在不过度收集数据的前提下检查兼容性。
WebCodecs 为网页应用提供较低层级的音视频编码与解码接口（参见 W3C 定义）。VideoFrame 也接受受支持的图像源，因此可将图像生成的帧送入视频处理流程（参见 W3C VideoFrame）；它并不是通用静态图像编解码 API。支持情况有助于选择媒体处理路径，但不是设备的完整描述，也不应被当成设备身份。结果可能随浏览器、操作系统、可用编解码器和执行上下文而变化。
WebCodecs 暴露什么
API 用编码数据块和编解码器配置表示媒体工作。应用可以在开始处理前询问某种配置是否受支持，避免启动当前浏览器无法完成的工作。这个回答有助于路径选择，但不承诺具体速度或画质。查询显示配置受支持，也不保证后续异步编解码成功；规范会通过错误回调单独报告处理错误（配置支持检查、编解码处理模型、错误回调）。
这与文件类型声明或实时通话协商的范围不同。W3C 规范说明 WebCodecs 中的编码媒体不封装在容器内（参见 codec string）；它也不定义网络传输，因此封装和传输属于应用的其他处理层。相关背景见 MIME 与编解码器支持 和 WebRTC 编解码器行为。
支持查询不等于处理已具备运行条件。创建编解码器对象仍可能因资源压力或执行上下文变化而失败。查询结果只针对提交的完整配置，可能涉及 profile、尺寸、帧率、采样率及其他格式参数；应查询当前用户任务所需的配置，而非积累无关组合清单（配置支持）。
处理过程包含异步工作，因此应用要管理队列、输出完成、错误和资源。规范提供编码与解码队列大小及 dequeue 事件；实现饱和时，工作可能继续排队（处理模型）。限制未完成的工作并实施背压：下游跟不上时暂停新输入，不要静默丢弃用户期望保留的帧。不再需要时关闭 VideoFrame 和 AudioData（系统资源、VideoFrame.close()）。界面应显示任务是在等待、处理中、暂停还是就绪，因为支持结果并不描述运行中的任务。预览可以采用低于源质量导出的表示，但要让用户看清此差别。应用取消时，停止接收输入、释放任务资源并保留源媒体，以便用户选择其他路径。
VideoFrame.timestamp 和 duration 的单位是微秒；应保留媒体时间线，而不是用回调到达时间替代。
转换和导出时还要检查色彩空间、可见矩形、旋转和翻转。VideoFrame 与 AudioData 可能占用 CPU/GPU 内存或专用编解码硬件资源；规范建议不再使用时及时释放。消费者完成后再关闭对象，并明确它被渲染器、队列或复用器持有期间的所有权（系统资源、VideoFrame）。
队列饱和时，新请求会被缓冲并使队列继续增长；饱和阈值由具体实现决定，也可能没有上限，因此不存在能跨实现预测速度或保证完成的通用队列计数。
dequeue 可用于控制后续输入，但不代表输出回调或容器写入已经完成，应分别跟踪这些后续环节。
编解码器可能等到更多输入后才交付内部输出，而 flush() 要求输出待处理结果；任务结束前也要检查最后的帧和数据块。
队列状态、回调状态和文件状态是应用流程中的不同指标，不是设备属性。队列缩短不代表导出完成，回调到达时间也不能替代媒体时间戳。
取消时应关闭尚未交给消费者的帧，但不能关闭仍由流水线其他部分负责处理的对象。对象被渲染器、队列或复用器持有期间，要明确其所有权。
支持差异的来源
WebCodecs 是接口，并不保证所有平台都提供全部编解码器。可用性取决于浏览器版本实现的功能，以及操作系统或媒体栈提供的编解码器。硬件加速也可能影响某种配置能否使用，但“受支持”并不表示“一定由硬件加速”。
标准与浏览器实现会持续变化：浏览器版本可能新增能力、修复实现或调整与操作系统的集成；操作系统也可能独立更新媒体服务，管理员还可能因策略限制受管理设备的功能。记录浏览器版本、操作系统系列、应用版本及媒体任务要求，让兼容性报告有用而不推测未观察到的硬件。相同的版本号不一定代表相同的媒体环境：某些浏览器发行版依赖系统库或平台编解码器，并随这些组件的发布节奏变化。两个系统可能对支持查询给出同样回答，但性能不同；支持情况描述兼容性，不是性能基准。
若加速效果很重要，应在有代表性的系统上测量实际任务，并与隐私或身份结论分开。浏览器更新可能在标准不变时改变能力可用性；应用需要选择路径时应重新检查，不能把旧回答当成永久设备元数据。受管理的工作站可能因政策禁用媒体功能，而个人安装可能开放；两者在各自支持范围内都可能正确。不要把单次结果推广为平台通则。如果浏览器使用系统媒体服务，系统更新也可能改变可用路径，即使应用本身没有明显变化。
浏览器更新后的兼容性信息会列出重新测试的媒体任务和仍可用的回退路径，但不保证所有机器都达到相同画质。查阅兼容性表时，可确认已测试项目、观察结果及用户可采取的下一步。测试记录也会区分导入文件、实时来源和生成样本，因为它们的权限和数据处理不同。短样本不一定覆盖长时间导出、可变帧率、多音轨或中断的下载；对用户说明这些支持边界和可用路径即可，无须介绍底层实现细节。
若任务不受支持，应在用户投入时间或数据前提供其他格式、本地替代方式或明确的服务上传选项。测试首次使用的完整流程：选择文件、授予所需权限、选择输出并等待完成。任何步骤失败都应保留源文件并说明下一步，不要要求重复授予无关权限。重复使用的流程可以记住格式偏好，但不必保留完整能力记录；浏览器更新改变路径时，用户应能轻松修改偏好。用户选择与浏览器观测不是一回事。
隐私与兼容性边界
W3C 指出，编解码能力配置单独使用时“极不可能”唯一识别用户，但仍可与其他指标组合形成指纹（参见 隐私考量）。因此不能绝对保证某个回答永远不会帮助识别个人或设备。若应用保留不必要的观察结果，或将其与其他信息关联，隐私风险会增加。只查询媒体任务真正需要的配置；若简单的播放选择已足够，就不要保存详细结果。
WebCodecs 本身不提供摄像头、麦克风或文件；这些输入各有独立权限与用户预期。只在需要时请求输入，在具体情境中说明原因，并区分导入文件和实时采集。兼容性检查应符合任务范围：音频编辑器可能需要解码导入内容并编码导出内容，却无须查询无关的视频设置。有限检查更简单，也让数据收集与功能相称。还应把能力选择与账户身份分离，避免将媒体路径选择暗中写入用户画像。
若遥测有助于支持问题，优先使用已完成、不可用或采用回退等汇总结果，并说明记录目的和保留期限。简单状态足够时不要保留完整配置对象。源媒体可能含有声音、人脸、位置或私人文档，需要单独的访问与删除规则。如果原始文件随后会上传用于导出，就不要把本地预览称为私密；远程转换必须在上传开始前说明服务边界。这些区别有助于用户作出知情选择，也让支持团队能清楚解释浏览器行为。
检查浏览器版本
兼容性工作应在受支持的浏览器版本中对比同一应用和媒体任务。记录用户流程是否完成、是否使用回退以及更新是否改变结果。先明确用户可见要求、输入、预期输出、受支持的回退和代表性媒体，测试至输出处理，并将功能验收与画面保真度、同步、延迟、内存和文件大小分开。
测试应围绕用户任务，而不是遍历每种编解码组合：打开录制、剪辑、导出后再播放。记录输入容器与轨道、预期输出及取消入口。优先使用合成样本；较长样本可暴露队列增长、时间戳缺口与内存压力，而不含个人媒体。文件选择和摄像头/麦克风权限应分开测试，并确认拒绝实时采集不影响导入文件。页面跳转、切到后台或设备休眠都不能造成虚假成功。记录中断后的部分导出是被删除、可恢复还是从未展示。重试必须使用已知输入，不能将用户选择的本地操作悄悄切换到远程服务。
检查容器元数据、轨道顺序与时长、帧顺序、旋转、字幕和色彩解释；音频要听开头截断、声道缺失以及跳转后的漂移。分别测试不受支持配置、格式错误输入、资源失败、取消和不完整输出。复现差异只保留所需的应用修订、浏览器构建、操作系统版本、输入类型、请求配置及观察结果，不收集无关环境细节。浏览器版本审查 将浏览器和测试配置视为同一版本单元。检查跳转后的时间戳连续性，确认预览中有意丢弃的帧仍出现在归档导出中。这些检查可验证用户任务，而无需建立宽泛的能力清单。
编解码器方法不能等同于应用取消。flush() 会完成排队的编解码控制消息并输出待处理结果，但不会封装容器，也不能证明文件写入完成（AudioEncoder.flush()）。应等待其 Promise、处理所有输出回调，并完成复用与存储后再显示“导出就绪”。reset() 会立即重置状态，包括配置、排队消息和待处理回调；复用对象前须重新配置（AudioEncoder.reset()）。close() 会中止待处理工作并释放系统资源，且不可恢复（AudioEncoder.close()）。应用取消属于工作流决策：停止新输入，根据任务生命周期选择 reset 或 close，保留源媒体，并明确显示已取消或输出不完整，不能报成功。实时预览可以丢弃过时帧，归档导出则可能必须保留全部所需输入；应明确相应策略。开始媒体任务前，先确认当前浏览器版本是否受支持，以及编解码配置不可用时可选哪条回退路径。本地处理和远程转换的数据路径不同，发送内容前必须说明上传选择。只有在同一用户任务验证通过且支持政策允许后，才能移除旧路径。支持记录只保留浏览器、系统、应用版本、媒体任务及可见结果等复现所需字段；尽量用合成样本，且不应超出已说明的支持目的长期保存源媒体或详细能力记录。只有编解码结果、文件输出和应用状态一致时，任务才算就绪：API 已完成，不代表文件已经完整、同步或封装。执行 VideoDecoder.flush() 后，下一个输入必须是关键块，因此跳转或重新开始解码时应提供关键帧（VideoDecoder.flush()）。
reset() 或 close() 无法撤销应用已经写入文件的字节。
断言与来源对应
- 支持情况针对提交的完整编解码配置，依据是 配置支持，不是设备能力清单。
- 编码数据块不包含容器封装；队列和输出行为依据 codec string 与 处理模型。
VideoFrame元数据和资源所有权依据 VideoFrame 与 系统资源。- 关于指纹风险的限定性表述见 隐私考量；应用上传和遥测属于独立的数据流选择。
flush()、reset()和close()的生命周期说明依据编码器方法及解码器 flush。