简短回答：硬件加速可以改变受支持编码或解码路径所用的处理资源。目标编解码器兼容性和 Enhanced RTMP 信令仍须分别检查。从输出契约开始，在代表性负载下测试一个配置文件，再决定处理能力是否足够。
将加速用于可测量的处理任务
| 层级 | 决策 | 验收检查 |
|---|---|---|
| 输入 | 源能否在选定工作流中解码或直通？ | 稳定的输入画面、音频映射和源遥测 |
| 变换 | 直通、重新封装，还是新的编解码器/分辨率/码率清晰度？ | 声明的输出编解码器、配置文件、尺寸、帧率和 GOP 与接收端契约匹配 |
| 加速 | 选定配置文件是否可在所选处理资源上使用？ | 持续运行显示可用余量且接收媒体没有退化 |
| 传输 | 输出需要哪个端点和传输方式？ | 目标使用分配的 URL 和凭据连接 |
| Enhanced RTMP | 此发送端/接收端组合是否支持所需编解码器信令？ | 接收端接受实际媒体；不要仅根据连接判断 |
区分四项常被称为转码的操作
直通保持编码媒体不变。重新封装改变容器或打包方式，但不一定重新编码流。转码会解码并编码一个新表示。硬件加速是受支持处理路径的实现细节，并非第四种媒体格式。在估算基础设施前，先明确所需操作。
媒体加速实际改变什么
加速可以为选定的视频操作提供合适资源，但可用密度取决于编解码器/配置文件、分辨率、帧率、输入复杂度、其他任务以及平台/驱动组合。AWS 对 VT1 的说明是用于视频转码工作负载的 Amazon EC2 实例系列；可将其作为基础设施背景，然后测试选定的 Callaba 源、输出和部署。硬件加速控件属于 Live Video Transcoding，但配置文件在生产接受前仍需进行代表性运行。
Enhanced RTMP 是互操作性契约
Veovera 规范为 HEVC 和 AV1 等较新编解码器添加 RTMP/FLV 信令。传输仍可以是目标所规定的 RTMP 或 RTMPS。RTMPS 使用 TLS 保护连接，而 Enhanced RTMP 添加编解码器信令。请针对目标端点检查这两项能力。对于 YouTube 路由，YouTube 当前编码器文档和目标分配的接入详情是配置权威。
记录验收结果
写下目标所需的编解码器、配置文件、GOP/关键帧节奏、音频和端点，然后在代表性负载下运行选定清晰度。将接收输出结果与配置文件一起保存，使下一位操作员可以重复有效路径。
从目标反向构建一个配置文件
- 记录目标当前的传输、编解码器、音频、分辨率、帧率、码率和关键帧要求。
- 检查源。仅当完整媒体契约已经匹配时才直通。
- 如需转换，选择匹配目标契约的输出配置文件，并确定选定加速路径是否可用。
- 运行代表性的节目素材足够长时间，以观察处理行为、接收的音频/视频和恢复。
- 保留已知有效的配置文件及用于接受它的证据。
通过观察边界排障
输入正常而输出始终无法启动，首先指向目标 URL、凭据、输出启用状态或不兼容的配置文件。已连接输出但视频黑屏需要检查编解码器/配置文件和接收端。提高延迟或更换加速方式不能替代检查输出契约。当运动质量下降时，将接收的清晰度与源比较，并检查码率控制、节奏和持续处理余量。
Callaba 的作用
Live Video Transcoding是 Callaba 用于编解码器、配置文件、码率、帧率、尺寸、GOP、轨道、声道、硬件加速和叠加设置的控制界面。手动配置文件可用后，使用Restream API 文档。对于 YouTube 专用的 Enhanced RTMP 设置，请遵循YouTube 工作流；对于输入访问，请使用RTMP Server配置接入端。
