NMOS中 EDID 元数据交换

来源：IP Oktoberfest 2021 主讲人：Nikita Nagorniy 内容整理：张志宇 本次演讲中， Nikita Nagorniy 介绍了 NMOS 在组播流中处理元数据交换的应用。

目录

• 前言
• NMOS 工作流程
• IS-11 示范
• Nmos 存在的问题和解决方案

前言

当我们将视频源连接到视频显示器时，我们对视频设备有一些期望。

1. 视频以可用的最佳格式显示在显示器上。
2. 默认情况下，视频源不会发送超出显示器范围的视频。
3. 如果笔记本电脑（视频源）进入睡眠状态，显示器也会进入睡眠状态。当笔记本电脑唤醒时，显示器也同时唤醒。
4. 如果更改视频源上的视频/音频设置，显示器内容也随之改变。

从用户的角度看，上述的这些工作是自动完成的。这要归功于元数据交换技术 —— EDID 和 InfoFrames 。

EDID 工作原理

当一台显示器连接到视频源时，显示器会向视频源传输信息，例如显示器支持的一系列分辨率和帧率，以及该显示器最适合的分辨率和帧率。承载这些信息的元数据格式就是 EDID ( Extended Display Identification Data ) 。

InfoFrames 工作原理

当视频源接收到 EDID 后，同样会向显示器传输信息，例如即将发送给显示器的视频的分辨率和帧率。承载这些信息的元数据格式是 InfoFrames 。

元数据交换让视频源知道显示器的需求，也让显示器知道视频源正在传输的是什么。但实际上仍会有一些与 EDID 相关的问题存在。通常显示设备会有很多不同的 EDID 实现，这有时会导致源和显示器的不兼容。由于存在这种不兼容性，当源接收到新的 EDID 时，显示器有很大的可能会无法显示。

EDID 存在的问题

图中展示的是，当电视机（显示器）与笔记本电脑（源）连接时，电视机正常显示。而当电视机（显示器）与台式电脑（源）连接时，电视机就无法显示了。

EDID 模拟器

这时我们需要调整 EDID ，事实上我们可以用 EDID 模拟器来解决这个问题。从图中可以看到，EDID 模拟器负责解决 EDID 协商修复问题。使用者可以通过 EDID 模拟器选择显示器支持的视频模式（内省的）。如果使用者知道台式电脑支持的格式，那么他甚至可以在 EDID 传输到源之前对 EDID 进行编辑。尽管有很多创新的方法可以解决这类问题，但是没有一个方法可以被整合进 AV over IP 的标准中。

组播流存在的问题

Basement world 和 IP world 最显著的区别就是组播流。在组播流的情况下，会有很多显示器，事情会变得复杂很多。从图中可以看到，每台显示器支持的视频格式都不相同。当多个不同的 EDID 传到源时，源该如何去传输视频？它应该传输一个 VGA 视频然后期待 FullHD 的显示器可以兼容它吗？还是应该什么都不做，直到多个显示器传出相同的 EDID 呢？这些问题并不是 EDID 旨在解决的，但确是我们在组播的世界中不得不考虑的。

总结一下我们需要解决的问题：

1. 用于组播流的“智能” EDID 管理。
2. 为 Pro AV 集成商调整工具，以防它在默认情况下无法正常工作。

两个规范

NMOS（Networked Media Open Specifications）该如何提供帮助呢？答案是有两个正在开发的 NOMS 规范可以用来解决上述的问题。

AMWA BCP-005-01 NMOS EDID to Receiver Capabilities Mapping，描述了 EDID 二进制文件如何通过 NMOS 接收器功能来表达。

AMWA IS-11 NMOS Sink Metadata Processing，描述了提供物理设备（被称为 Sink ）信息的 Http API，并允许用户根据我们从接收方收集到的信息配置发送方。

NMOS 工作流程

NMOS resources

让我们看看 NMOS 是如何工作的。图中从左到右是一台 HDMI 输出的笔记本电脑， HDMI 到以太网网关，一台网络交换机，两个以太网到 HDMI 网关，还有两台显示器。它们在 NMOS 术语中的角色分别是：笔记本电脑是 Source，HDMI 到以太网网关是 Sender ，以太网到 HDMI 网关是 Receiver ，显示器是 Sink 。网关和 IP 之间的所有操作是通过 NMOS API 实现的。而一些 low-level 的部分例如 EDID 和 InfoFrame 是在网关外实现的。

Step 1

首先， Controller 会从 Receiver 中获取 Receiver Capabilities ， Receiver Capabilities 是从 EDID 中产生的。网关并不直接传输 Receiver Capabilities ，因为处理来自网络的视频流时， EDID 可能会有自身的限制，这些限制在 Receiver Capabilities 中需要被考虑到。在这一步中，Receiver Capabilities 中最重要的部分是 Receiver 支持的视频模式。

Step 2

当 Controller 取得 Receiver Capabilities 后，它开始处理这些 Receiver Capabilities 。假设 Controller 取得的两个 Receiver Capabilities 不相同， 在大多数情况下，应该计算它们的重叠部分以确保我们得到的一系列视频模式可以同时被两台显示器支持。Controller 会把这些重叠部分展示给用户看，让用户可以在有需要时调整视频模式。

例如，当 Controller 从两个 Sink 中得到两个 Receiver Capabilities ，计算它们重叠的部分并展示给用户看。此时用户知道网络交换机是低带宽的，而 Sink 可以支持 8K 的视频（在两个 Receiver Capabilities 的重叠范围中），但低带宽的交换机显然难以处理 8K 的视频，在这种情况下用户可以人为地删除 8K 这个视频模式。完成处理后， Controller 将这些支持的视频模式写入 Media Profile 中。

Step 3

接着， Controller 把 Media Profile 传给 Sender 。HDMI 到以太网网关（ Sender ）将视频模式写入 EDID 中传给笔记本电脑（ Source ）。这个转换也不是直接的， HDMI 到以太网网关可能也会有自己的限制，可能会限制一些视频模式。

Step 4

再之后，Source 读取 EDID 并开始传输带有 InfoFrame 的视频。

Step 5

一切准备就绪后， Controller 通知 Sender 开始传输视频，通知 Receiver 开始根据网络参数接收视频。

IS-11 示范

为了演示 NOMS 的工作流程，Nagorniy 播放了一段视频。

controller 界面

图中展示的是 Controller 的界面，可以在该界面中选择 Sender 的 Media Profile 。左边的两个紫色按钮表示 Macn Sender ，右边的四个蓝色按钮表示 Receiver ，其中两个是 Macn ，两个是 Mon 。

result 1

当把 Macn 01 Sender 和 Macn 01 Receiver 连接时，可以看到，此时 Controller 显示可以支持的 Media Profile 有 44 种。

result 2

当把 Macn 02 Receiver 也与 Macn 01 Sender 连接时，这个情况就跟组播流一样了。可以看到， Controller 计算两个 Receiver 的重叠部分，最后显示出的可支持的 Media Profile 只有 36 种。

result 3

当把 Mon 01 Receiver 也接入时，可以得到重叠更小的 Media Profile 。可以看到，此时显示课支持的 Media Profile 只有 1 种了。

Nmos 存在的问题和解决方案

连接流程

图中展示的是使用 NMOS 的流程。用户首先选择 Sender 和 Receiver ，之后 Controller 获取 Receiver Capabilities 并计算重叠部分，然后把 Media Profile 送至 Sender ，再之后开始传输视频流。

但这个流程并没有包括一个重要的情况，我们知道 EDID 可能会在 Source 端出现问题，就是没人知道 Source 端在读取 EDID 后，需要花多长时间才开始传输视频，甚至有可能 Source 端并不传输视频。这个情况意味着 Sender 并没有准备好传输视频流，它停在了图中的第 4 步，并没有执行第 5 步。也有可能是因为用户把 Source 从网关中断开，导致视频无法传输。

解决方案

现在 IS-11 团队正在想办法处理这种情况。我们知道 IS-11 通过 HTTP API 得到 Media Profile 。如图所示， GET/media-profiles 操作会返回空数组或实际的 Media Profile 数组。而 GET/status 操作会返回各种状态。当加入 GET/status 操作后，有两种解决的方案。

异步方案

第一种是异步的方案，Controller 得到 Media Profile 后，开始循环接收 IS-11 的 Status ，直到 Source 端准备好后才将 Media Profile 传出。这个方案的问题是难以定义 Controller 将 Media Profile 传出前后的行为。需要花费多长时间等待以及等待时什么操作是允许的都复杂。

同步方案

第二种是同步的方案，同步的方案解决了异步方案存在的一些问题。这个方案下，等待 Source 端响应的操作从 Controller端 移到了 Sender 端。所以 Controller 不用考虑这种决策问题，它只要把 Media Profile 传给 Sender 就行了。如果 Source 端准备好了，那么 Sender 回复 OK 然后开始传输视频。如果 Source 端还没准备好，而预设的等待时间已经到了，那么 Sender 会回复等待时间已到，然后开始处理下一个 Media Profile 。

最后附上演讲视频：

http://mpvideo.qpic.cn/0b2eiuaawaaaeyaagr6irzqvarodbncqacya.f10002.mp4?dis_k=52fc9f7745b05e22070c5c07a1b41a2d&dis_t=1640593501&vid=wxv_2196255484154871812&format_id=10002&support_redirect=0&mmversion=false