摘要

  • IESG 于 9 月 10 日批准“时空分辨率请求与通知”规范进入 Proposed Standard。截稿时它仍是第 17 版 Internet-Draft，尚无最终 RFC 编号，IANA 工作也未完成。
  • 接收端可请求帧率、宽度和高度；发送端则回报自己将采用的值。两组数可以不同，混流器、多方需求、本地策略和拥塞控制还会继续影响结果。
  • TSRR 与 TSRN 记录的是控制对话，不测量实际到达的视频、接收端耗电、续航、排放或体验。凡是宣称节能，都需要另一条从请求走到实测效果的证据链。

被批准的是一种说法，不是一只电表

IESG 的 9 月 10 日公告批准了 RTP Control Protocol Messages for Temporal-Spatial Resolution，目标状态为 Proposed Standard。Datatracker 当前记录显示批准公告已经发出，但公开对象仍是第 17 版 Internet-Draft，IANA 状态仍在处理中。因此，可以报道批准已经发生，却不能抢先写出尚未存在的最终 RFC 编号或已完成的注册表值。

批准过程也留下了可核验的轨迹。批准说明写明，2024 年第一次工作组最后征求意见收到的回应不足以宣布共识；随后增加评审，第二次征求意见后才形成“良好共识”的判断。这段历史不是瑕疵标签，而是在提醒读者：IETF 的权威来自一连串可指认的程序动作，不是把机构名称放进一句话就有了确定性。

这项规范解决的是通信问题。接收端掌握自己的电池、解码负载和显示环境，发送端却控制编码参数。此前，两端缺少一组专门的 RTCP 消息来表达所需的帧率与画面尺寸，并明确回应将采用什么值。新规范在 RFC 4585 的 RTCP 反馈框架和 RFC 5104 的编解码控制消息基础上补上了这条窄通道。

TSRR 是有边界的建议

第 17 版草案把接收端发出的消息称为 TSRR，即时空分辨率请求。它带有目标媒体源、序列号、每秒帧数、画面宽度和高度。请求值不得为零，也不得超过会话通过 SDP 已经协商的时空上限。

这里最重要的是权限分配。解码端可以提出建议；有能力调整的编码端可以把它纳入后续编码；发送端随后必须用 TSRN 通知将采用的帧率和尺寸。接收端表达约束，并没有获得远程改写编码器的绝对命令权。

通知值不同于请求值，并不等于违规。预录内容可能无法改变，编码器可能没有相应档位，多名参与者的要求可能互相冲突，服务策略可能设置最低画质，拥塞控制也可能压低最终传输。在多方会话里，混流器可自行处理请求，也可向原始发送端转发；它还必须考虑所有参与者的共同需要。

能力本身也要经过协商。SDP offer 中出现 tsrr，而 answer 没有保留它，便意味着本次会话没有启用这项机制。草案的操作说明还明确指出：只在一端实现不会改变 RTP 服务。产品宣称支持、双方协商成功、请求抵达和画面真的改变，是四个不同状态。

TSRN 证明已回应，不证明已节电

TSRN 让发送端不能保持沉默。它用请求序列号把回应和原请求对应起来，告诉每一个请求者：消息已经收到，以及接下来计划使用哪组帧率、宽度和高度。这是有价值的协议证据。

然而，“将采用”仍是声明，不是对抵达画面的采样。回应之后，混流、拥塞或策略更新都可能继续改变媒体流。通知字段中也没有瓦特、焦耳、电池剩余时长、处理器占用或碳排测量。同样的分辨率，在不同编码器、硬件加速、屏幕亮度和后台负载下，接收端能耗可以完全不同。

规范引用的能源语境来自 ISO/IEC 23001-11:2023，即 Energy Efficient Media Consumption。IETF 这份草案承担的是其中一部分反馈信息的传送，并没有声称提供完整能耗核算方法。文件名里的 green-metadata 不能扩大字段本身的证明力。

正确的状态链应当是：

TSRR 请求 → TSRN 所报选择 → 实际媒体观测 → 接收端能耗测量 → 画质与服务影响。

把第二步直接改写成第四步，会把一个合规消息变成没有测量支撑的绿色宣传。

画质不是可以藏掉的成本

草案的操作部分主动警告：若接受不恰当的建议，体验质量可能下降并引发用户投诉。运营者可校准可接受范围，服务等级保障工具也应考虑这一风险。少一些像素也许能让通话延续，却可能让白板文字无法阅读、损害无障碍需求，或迫使用户重新发起更长的会话。

多方会话尤其容易转移成本。提出省电需求的人，未必是最依赖高清图像的人。若混流器只留下最终三项数值，事后便难以判断哪一方的需要被优先处理、谁制定了规则、是否允许例外。标准化格式没有必要替每个服务决定优先级，但运营者必须让本地裁量可追溯。

这正是最小协调的价值：协议只规定各方如何表达，不把所有部署决定集中到标准组织手里。风险不在于保留本地选择，而在于借“绿色元数据”之名把选择者和受影响者藏起来。

认证保护消息，不替政策背书

伪造的 TSRR 可能把帧率或画面压到极低，也可能反复提交异常请求造成负载。草案要求考虑认证与完整性保护，并指向 RFC 5124 的安全反馈配置；遇到异常报告行为时，实现还应保守处理。

密码学能说明消息来自受保护会话中的谁，以及传输途中有没有被修改。它不能说明请求者的电池估计准确，不能自动授予降低他人画质的政策权限，更不能证明改变之后真的节电。经过认证的坏建议依然是坏建议，完整无误的通知依然不是电表读数。

采用者还应看到公开的权利信息。Qualcomm 的 IPR 5764 声明关联前身草案，列出合理、非歧视且可能收取许可费的立场；InterDigital 的 IPR 6159 声明关联工作组草案早期版本，并在其条件下表示愿意按合理、互惠、非歧视条款谈判。它们是尽职调查材料，不是 IETF 对专利有效性、必要性、侵权、价格或实际许可义务的裁定。

建立“分辨率变化证据链”

服务若要公开声称节能，应当保存一条隐私受限的分辨率变化证据链。起点记录两端软件版本、tsrr 能力协商和安全上下文；随后记录请求者与目标角色、序列号、时间以及所求帧率、宽度和高度。

决策段要指出究竟是发送端还是混流器采用了哪版策略，可接受范围是什么，多方请求如何合并。TSRN 值和时间作为“宣布将采用的设置”单独保存，不能悄悄改名为交付结果。下一段用明确时间窗观测真正到达的帧率、尺寸和码率。

只有当报告提出能耗结论时，才把设备、解码路径、硬件加速、屏幕状态、基线、测量窗口、单位与不确定性加入记录。画面冻结、可读性、无障碍影响、投诉、人工覆盖、回滚和纠正必须并列出现。公开版本应删去参与者身份、会话秘密和可被滥用的阈值；受保护证据可供运营、安全调查和争议处理。

这条证据链是我的编辑建议，不是 IETF、ISO、IANA 或专利声明人的要求。它沿用 Heng Lu 在 The Policy Mirror 中的权威追踪：谁能决定，哪项证据支持当前状态。他的 Minimum Initial Specification说明，窄而通用的协调可以与本地、自愿采用并存。Why BTW Media Exists则要求把已经观察到的现实置于机构愿景和产品标签之前。

TSRR 让接收端的约束可见，TSRN 让发送端的回应可见。真正的节能是否发生，还必须由下一段证据回答。

Sources

  1. IETF 协议行动公告
  2. IETF Datatracker 文件记录
  3. Internet-Draft 第 17 版
  4. IETF 批准说明
  5. RFC 4585
  6. RFC 5104
  7. RFC 5124
  8. IETF IPR 声明 5764
  9. IETF IPR 声明 6159
  10. ISO/IEC 23001-11:2023
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists