企业官网建设流程全解析

简介：这份PDF面向音视频接口开发、电视与音响产品测试人员及希望系统了解HDMI 2.1的工程师，围绕HDMI 2.1规范与CEC通用合规测试展开，并涉及eARC增强音频回传等功能，可用于方案预研、接口调试和测试要点查阅。压缩包仅含1个PDF文件，大小约1.57MB，内容为规范类文档，便于在电脑端检索条款和对照阅读。该资料已有2139人学习，说明其在HDMI 2.1与eARC相关主题上具有一定参考热度。文档围绕高带宽传输、VRR、ALLM、eARC及多种音频格式等特性组织说明，并给出CEC GCTS的测试框架与合规要求，适合读者快速建立HDMI 2.1知识脉络、定位eARC功能要点，也可作为音视频设备联调和测试准备时的查阅材料。

1. 一份 103 页的 HDMI 2.1 CEC 合规测试规范：它到底能替你回答什么问题

排查一台样机的音频回传问题，症状很怪：电视切到外接音响，十次里有两次没声音，重新插拔就好。抓了两天 CEC 日志才定位到<Initiate ARC>之后对方没回<Report ARC Initiated>。要把这类问题讲清楚、还要给出别人能复现的记录，论坛帖子不够用，最后靠的是这份 hdmi2.1 的 CEC 通用合规测试规范（GCTS）：103 页，2018 年 7 月 11 日的 Version 2.1，正文按 7.1 到 7.13 拆成十三组用例，附录给了 DUT 能力声明表和 CDF 模板。

它不教芯片设计，回答的是另一类问题——某个行为算不算合规、用什么激励去激发、判定依据落在哪一页。适合做整机、机顶盒、功放、线材和测试服务的工程师，也适合刚接手 CEC 与 eARC 联调、被「时好时坏」折磨过的人。

2. 拆开这份文档：六个分册、七次改版和十三组用例怎么对上号

拿到一份一百多页的规范，最常见的错误是从第一页开始顺序读。这份文档的组织方式决定了它更适合「当索引查」而不是「当教材看」：真正决定你该翻哪一页的，是 DUT 的产品类型和它申报支持的功能集。先把骨架拆开，后面查任何一条测试项都会快很多。

2.1 顶层文档加六个分册：CEC 这一册管的是协议行为

Version 2.1 相比之前的版本做了一次结构性调整，把原来一本大而全的 GCTS 按目标产品类型和功能拆成了顶层文档加若干附属分册。按文档里的描述，这套集合包括顶层 GCTS，以及分别面向 Source、Sink、Repeater、CEC、eARC、Cat3 Mated Connectors 的分册。这个拆分不是排版偏好，它直接改变了你的工作方式：同一个测试意图，在不同分册里的判定角度是不一样的。

从工程角度看，Source 和 Sink 分册管的是「线和信号能不能过」，CEC 分册管的是「设备之间说不说得上话」。两件事经常被混为一谈：视频通路跑得通、4K 画面正常，不代表 CEC 的消息能被正确接收。反过来，CEC 日志全绿也不能证明视频链路合规。做联调时把这两层分开看，排错范围会小很多。

还有一个容易被忽略的细节：文档引用了 HDMI 1.4b 的大量文本片段，采用双剑号标记并单独说明版权归属。这意味着你在读到某些章节时，看到的内容其实是十几年前定下的老条款，只是被搬过来避免反复跳转。判断一条要求是「HDMI 2.1 新增」还是「1.4b 沿用」，看这个标记比看正文语气可靠得多。

2.2 修订历史当成索引读：七次迭代各加了什么

文档开头的 Document Revision History 是整份文件里信息密度最高的几页，很多人的做法是直接跳过，实际它是一张「哪些测试项被改过」的变更地图。做旧项目回归、或者接手别人留下的测试报告时，先扫一遍这里，比逐条比对正文快得多。

这张表最实用的读法是反过来用：手上有一份两年前的测试报告，先看它是按哪一版做的，再对照修订历史里该版本之后被改动的测试项编号，逐个确认是否需要重测。这一步做过一次之后，你会发现很多「报告全过但现场出问题」的案子，根因就是报告用的是被修正前的步骤。

顺带一提，2.1 版把文档拆分这件事本身就是个信号：它承认了不同产品类型的合规路径差异已经大到没法用一套统一流程覆盖。如果你的团队还在用一份通用检查表应付所有产品，大概率会在分册之间漏项。

2.3 7.1 到 7.13：十三组用例的归类逻辑

正文第七章是整份文档的主体，从 7.1 排到 7.13，每一节对应一类测试意图。这个分组不是按消息类型切的，而是按「设备在系统里要完成什么行为」切的，理解了这个切法，找用例就不容易迷路。

把这张表和前面那个「症状」对照着看，就能理解为什么按现象排查比按章节顺序排查更有效：用户报的是「切音响没声音」，落在 7.11；用户报的是「待机后遥控失灵」，落在 7.6 和 7.8；用户报的是「输入源名字不对」，落在 7.9。先定位到组，再进组找具体测试项，路径短很多。

表格部分也值得单独看。7.1 到 7.4 之前先有三张总表：需求表、通用设备表、各测试组的用例清单表；后面还专门列出了 HF4-2-2、HF4-2-3、HF4-2-4 这几项测试所使用的操作码集合，并且因为内容较长拆成了两张表。这种把「测试用的激励内容」单独列表的做法很实用——写自动化脚本时，这些表就是现成的测试向量来源，不用逐条从正文里抠。

2.4 附录四张表：规范性两张决定了你测什么

很多人读到附录就停了，但这份文档里，附录 A 和附录 B 是规范性（Normative）的，也就是说它们不是参考资料，而是流程的一部分。

附录 A 是通用 DUT 能力声明，附录 B 是 CEC DUT 能力声明表，两张表合起来回答一个问题：这台设备到底申报了哪些能力。附录 C 是面向 CEC 2.0 设备的最小 CDF 1.4b，属于资料性；附录 D 是 HDMI 2.1 的附加要求，同样是资料性。规范性意味着你必须填、且填的内容会被用来决定测试范围；资料性意味着它是参考，不填也不构成缺项。

实际执行中，附录 B 的填写质量直接决定后面几天的效率。举个具体差别：一台电视申报支持 System Audio Control，7.10 整组就要跑；没申报，这一组标 N/A 并说明理由。但如果实际固件实现了这个功能却没申报，出厂后用户接上音响一试就是问题——这种「申报与实现不一致」在联调阶段极难发现，因为测试是按申报走的。

3. eARC 的音频回传链路：从一根 CEC 线到 HEAC 差分对的四个观察点

标题里提到 eARC 功能介绍，落到这份文档上需要先说清楚一件事：eARC 的完整测试内容在独立的 eARC 分册里，CEC 分册能提供的是控制侧的行为判定，也就是 7.11 那一组，加上附录 D 里与 2.1 相关的附加要求。把这两块分清楚，你在查 eARC 问题时才不会在 CEC 分册里找音频电气参数，白翻半天。

3.1 物理通道换了，控制通道没换

ARC 和 eARC 最根本的差别在线缆里走哪根线。常见说法是：ARC 复用线缆中的 Utility 线，采用类似 S/PDIF 的调制方式承载音频；eARC 则改用 HEAC+/HEAC− 这对差分线，把音频当作高速数据来传。差分传输带来的直接好处是带宽和抗干扰能力同时上去，这也是它敢接未压缩多声道的原因。

但控制侧没有跟着换。启动和终止回传这件事，仍然走 CEC 总线上的那几条消息。这解释了一个很常见的困惑：明明 eARC 握手成功了，为什么拔插之后又不行？因为音频通道建起来了，控制通道的状态机没同步——负责启停的那几条 CEC 消息没走完，eARC 侧就不知道该不该继续。

表里的带宽数字是行业里被广泛引用的量级，不是这份文档正文给出的判据。真要拿去做设计输入，还是得回 eARC 分册和芯片手册确认。这一点必须说清楚，否则很容易拿一个二手数字去卡硬件选型。

3.2 发现、能力交换、状态机：eARC 侧的三段式

eARC 的链路建立不是一步到位的，拆开看是三段：先发现对方是不是 eARC 设备，再交换双方的能力结构，最后按协商结果配置音频通路。这三段各自有独立的失败模式，混在一起看日志会很难受。

第一段是发现。设备需要在专用通道上确认对端支持 eARC，这个阶段失败的表现通常是「完全没反应」，连 ARC 都回不去。第二段是能力交换，双方把支持的音频格式、最大声道数、采样率上限报出来，取交集。这一段失败的表现是「有声音但格式不对」——比如 Atmos 片源只出 5.1，或者高采样率音轨被降頻。第三段是状态机稳定，失败表现最刁钻：短时间正常，几分钟后掉，或者切一次输入就掉。

我的习惯是把这三段在日志里用不同颜色标出来，物理上分开看。CEC 日志里能看到启停消息，专用通道上的发现与能力交换要看另一份抓包。两份日志按时间戳对齐，才能判断到底是「控制没发」「发了没回」还是「回了但配置错」。

3.3 7.11 那一组在测什么：启停消息的时序与应答

CEC 分册里 7.11 这一组，判定对象是回传通道控制消息的收发行为。核心就是几条消息的配对关系：发起方请求启动，响应方要给出明确回应；发起方请求终止，响应方同样要有回应；中间任何一步超时或者消息内容不合法，都算不合规。

这套消息的价值在于它是可观测的。音频有没有真的出来，你要靠耳朵或者分析仪；消息有没有按顺序发、有没有人应答，抓包就能看。所以现场排查我一般先看这组消息的完整性，再看音频。顺序反了的话，很容易陷进「音频链路」的深坑，最后发现是控制消息压根没发出去。

还有一个容易误判的地方：这组测试的通过不代表音质没问题。它判的是行为合规，不是音频质量。有人把 7.11 全绿当成 eARC 没问题的证据，结果被杜比全景声透传失败打脸——那属于能力协商阶段的事，不在这组用例的射程内。

3.4 音频格式与参数：拿什么去对能力协商的结果

能力交换阶段报出来的参数，最终要落到具体格式上。实际联调时我一般准备一张对照表，把「片源格式」「协商结果」「实际输出」三列并排放，一眼就能看出是哪一层降级了。

这张表的用法是排除法：先确认片源是什么格式，再看协商结果里对方报了什么，最后看实际输出被降到了哪一档。三列对不上，问题就锁定在对应环节。比一句「音频不对」去猜要快得多。

需要提醒的是，格式支持和带宽是两件事。带宽够不代表格式被正确识别，格式被识别也不代表声道映射正确。我见过协商报的是 7.1 但实际只有前左前右有声音的案子，最后查到是通道映射表配错，跟带宽一点关系没有。

4. 把规范跑成测试记录：CDF、测试编号和一条可复现的执行链

文档读懂了不等于能出报告。从「知道有这条测试」到「产出一份别人能复现的记录」，中间隔着选测、搭台、执行、记录四个环节，每个环节都有各自的坑。这一章按实际执行顺序走一遍。

4.1 先填 CDF，再谈测什么

附录 A 和附录 B 是规范性文档，必须填。填的时候有三个维度要想清楚，想不清楚后面全是返工。

第一个维度是 CEC 版本。设备是按早期版本实现的，还是按 2.x 的要求实现的，直接决定要不要套用附录 C 里的最小 CDF。这一步填错，整份测试报告的基线就错了。

第二个维度是功能集。System Audio Control、ARC、遥控透传、OSD 名称、厂商自定义消息，这几项要逐条确认「实现了没有」和「申报了没有」。这两个答案不一致就是隐患，必须在填表阶段暴露出来。

第三个维度是逻辑地址策略。设备打算占用哪类逻辑地址、冲突时怎么退让、是否支持多地址。这个填错的表现很隐蔽：测试时一切正常，量产机上跟别的设备一撞就抢地址。

我一般会把附录 B 的每一项抄成一张两列表：左列是申报值，右列是实测值，中间留一列写差异说明。填完表先做一次自测，把差异项清零再进正式测试。这一步多花半天，能省掉后面两天的扯皮。

4.2 测试编号怎么读：HF1 到 HF4 的归属

文档里的测试项都带编号，形如 HF1-53、HF2-54、HF3-21、HF4-1-6。从修订历史的描述能看出归属规律：HF1 系列对应 Source 侧，HF2 系列对应 Sink 侧，HF3 系列对应 Repeater 侧，HF4 系列对应 CEC 相关。这个规律不是明文写在某一页上，但从各版本的修改记录里能稳定推出来。

理解这个归属，直接的好处是知道哪些项该在 CEC 分册里找、哪些项要去 Source 或 Sink 分册翻。比如修订历史里提到 HF4-1-6 的文本片段被更正过，那它属于 CEC 低层这一组；而 HF1-54、HF1-55 是 E-DDC 电气与时序测试，虽然也会影响 CEC 测试的前置条件，但主体不在这一册。

还有一个实操经验：编号是稳定的，标题是会变的。做版本比对时用编号对齐，不要用标题对齐。曾经有一次两份报告的测试项标题只差一个词，实际是同一个用例的不同版本表述，按标题比对得出的结论完全是错的。

4.3 一条可复现的执行链

把上面几节串起来，一条完整的执行链是这样的：确认 DUT 类型 → 填写能力声明表 → 由申报能力推导适用测试组 → 搭建测试台 → 逐组执行并记录 → 出报告并标注版本与不适用项。

第三步可以半自动化。下面这个脚本做的事很朴素：把 CDF 里的能力位和测试组做映射，输出一张带适用性判断的检查表，避免人工漏项。

# cec_checklist.py # 用途：由 CDF 能力位推导适用的 CEC 测试组，输出 CSV 检查表 import csv # 测试组 -> 依赖的能力位；all() 语义：任一缺失则整组不适用 GROUPS = { "7.1 low level": ["cec_basic"], "7.2 general protocol": ["cec_basic"], "7.3 timing": ["cec_basic"], "7.4 polling": ["cec_basic"], "7.5 address allocation": ["cec_basic"], "7.6 power state changes": ["cec_basic"], "7.7 routing/switching": ["routing_control"], "7.8 rc pass through": ["rc_pass_through"], "7.9 osd name transfer": ["osd_name"], "7.10 system audio control": ["system_audio"], "7.11 arc control": ["arc"], "7.12 vendor specific": ["vendor_specific"], "7.13 converter cable": ["converter_cable"], } # 从附录 B 抄过来的申报值，True 表示 DUT 声明支持 cdf = { "cec_basic": True, "routing_control": True, "rc_pass_through": True, "osd_name": True, "system_audio": True, "arc": True, "vendor_specific": False, "converter_cable": False, } with open("cec_checklist.csv", "w", newline="", encoding="utf-8") as f: w = csv.writer(f) w.writerow(["测试组", "适用", "备注"]) for group, needs in GROUPS.items(): ok = all(cdf.get(n, False) for n in needs) note = "由 CDF 能力位推导" if ok else "CDF 未申报，标注 N/A 并写理由" w.writerow([group, "Y" if ok else "N", note])

逻辑说明：GROUPS是测试组到能力位的映射表，一个组可以依赖多个能力位，all()要求全部满足才判为适用；cdf是从附录 B 抄下来的申报值；输出是 UTF-8 编码的 CSV，方便直接贴进测试记录模板。

参数怎么改：cdf里的布尔值必须逐项对着申报表填，不能凭印象；GROUPS的映射关系是简化过的，实际执行中不少组是「部分适用」而不是「整组适用」——比如 7.12 只在设备确实发过厂商自定义消息时才需要测，标成 N 之后还得人工判断是跳过还是选择性执行。这个简化假设是我刻意留的，因为它正是最容易出问题的地方：把整组一刀切掉，等于把部分用例的缺失藏进了「不适用」里。

输出之后还有一步不能省：把 CSV 里所有标 N 的项单独列一遍，逐条问「为什么不做」。答不上来的，就是漏测。

4.4 测试台搭什么：波形、日志、可编程电源

设备清单取决于你要跑哪几组。低层和时序相关的组，示波器是刚需，要能稳定捕获 2.4 ms 量级的位周期，看逻辑 0 与逻辑 1 的高低电平宽度、上升沿、以及多个设备同时发送时的线与结果。CEC 是单线双向、线与结构，逻辑 0 是低电平，多个设备同时发时低电平占优，这个特性和 I2C 类似，用示波器看仲裁过程比看协议分析仪的解析结果直观。

协议分析仪负责另一件事：把位流解析成消息、给出时间戳、支持注入激励。选型时重点看两个能力，一是能不能按消息级别打时间戳（不是按秒级），二是能不能主动发消息模拟对端。第二个能力决定了你能不能在只有一台 DUT 的情况下跑完大部分用例。

电源要可编程，因为 7.6 这一组和上电时序、5V 掉电重连直接相关。手动拔插电源做这一组，重复性很差，而且很难复现「掉电 300 ms 后重连」这种边界条件。

日志记录我一般要求三要素齐全：时间戳、发起方逻辑地址、操作码加操作数。缺任何一个，后面看日志都得靠猜。

5. 避坑与排查：CEC 与 eARC 联调里五个高频翻车现场

下面这几条都是实际踩过的，按「现象 → 原因 → 解决」写。有些坑一次能记住，有些我踩过两遍。

5.1 电气与时序类：波形看着对，判定就是不过

现象：低层测试里电平判定忽高忽低，同一台设备上午过、下午不过，示波器上波形肉眼看着没什么区别。

原因：最常见的是探头接错位置。CEC 总线的上拉和端接是有明确配置的，探头挂在中间某个分支上，探头自身的容性负载会改变边沿，测出来的东西和 DUT 实际输出不是一回事。其次是测量点选在了连接器外侧，线缆和转接板引入的损耗没有算进去。

解决：测量点尽量靠近 DUT 的引脚，用高阻探头并把地线做短；先测一条已知合规的参考设备，把探头位置和示波器设置固定下来，再测 DUT。这个「先测参考件」的习惯值钱，它能帮你把测量系统的问题和设备的问题分开。

现象：连续发送多条消息时，中间某条被判定为时序违规。

原因：消息之间的间隔有下限要求，而且不同类型消息的下限不一样——新消息、重传同一消息、同一设备连续发送，三者的间隔要求不同。固件里如果用一个固定延时应付所有情况，必然在某一类上翻车。

解决：把发送队列按消息类型分类，不同类型的间隔分别配置，不要用一个全局常量。测试时专门构造连续发送场景，用分析仪看实际间隔和下限的差值。

5.2 地址与状态机类：能通信，但地址不对

现象：DUT 明明在线，其他设备却认为它不存在；或者它占了别人的地址，导致那台设备失联。

原因：地址申请流程没走完整。设备的做法应该是按顺序尝试候选逻辑地址，遇到冲突就释放并退让，全部失败才退到广播地址。常见的错误实现是「只试第一个候选地址，失败就直接用」，或者「收到冲突通知后不释放，继续占用」。

解决：把地址申请做成完整的状态机，冲突处理单独一条路径，测试时专门构造「目标地址已被占用」的场景。另外要注意，地址申请和存在性轮询是两件事，前者决定身份，后者决定别人还记不记得你，两者都要覆盖。

现象：待机唤醒后，CEC 完全无响应，重新上电才恢复。

原因：CEC 的供电依赖 5V，掉电后总线状态和软件里的状态机不同步。很多实现把 CEC 初始化放在开机流程里只做一次，待机时总线掉电、软件状态没重置，唤醒后就卡在中间态。

解决：把 5V 检测做进中断或者轮询路径，检测到恢复后重新初始化总线并重置状态机；初始化里加足够的稳定等待时间。测试时用可编程电源模拟各种掉电时长，包括很短的毛刺，比手动拔插覆盖得全。

5.3 申报与版本类：报告全绿，现场出问题

现象：System Audio Control 相关测试全过，用户接上音响后音量键控制错对象，或者出现两个音量条。

原因：申报与实现不一致，或者只在特定流程里做了一次协商。系统音频模式是状态，不是一次性动作，输入切换、待机唤醒、音响热插拔之后都要重新确认当前状态。

解决：以附录 B 的申报值为准做一次完整回归，把「状态恢复」单独作为测试场景加进去，覆盖热插拔、输入切换、待机唤醒三种触发。

现象：两份测试报告的步骤编号对不上，同一项测试结论相反。

原因：版本混用。2.1 之后文档拆成了分册，如果一份报告用的是拆分前的版本，另一份用的是 CEC 分册，步骤编号和判定依据都可能不同。更隐蔽的情况是修订历史里被修正过的项，旧报告按错误步骤做的结论已经失效。

解决：每份报告强制标注文档版本号和分册名，做回归前先查修订历史，确认该项目在目标版本之后有没有被改过。这一条看起来是流程问题，实际是技术问题——按被修正前的步骤测出来的「通过」，没有任何意义。

提示：这份文档带保密标记，使用和流转要严格限定在授权范围内，不要图方便随手转发。测试记录里引用条款时，标注章节号即可，不要把正文大段复制进对外文档。

6. 把文档用成检查表：三张对照表和一次版本比对的习惯

一百多页的规范，真正常用的其实就三张表。第一张是修订历史，用来判断手上的报告还能不能用；第二张是 7.1 到 7.13 的分组表，用来把现场症状翻译成测试项；第三张是附录 B 的能力声明表，用来确定这次到底该测什么。把这三张表打印出来贴在工位上，比在 PDF 里搜关键词快得多。

版本比对这件事我建议做成固定动作，不要靠记忆。手上同时有两版文档时，把两版的目录和测试项编号导出来做一次差分，改动项会自己浮出来。如果只有纸质或者扫描件，退一步的做法是把修订历史那一页拍照存档，每次开会前扫一眼。这个动作花不了几分钟，但能避免拿一份过期报告去支撑量产决策——这种事出一次，返工量是按周算的。

我的习惯是每接手一个带 CEC 或 eARC 的项目，第一件事不是打开代码，而是先按附录 B 把能力声明表填一遍，填完再对着 7.x 分组表把适用项圈出来，最后才去看固件里的状态机实现。这个顺序反过来试过一次，结果是代码读了两天，测试范围还没定下来，等于白读。从那以后我每次启动新项目都强制先走一遍「填表 → 圈组 → 再读代码」，哪怕项目再小也不跳。希望帮到你。

本文还有配套的精品资源，点击获取