jetson-video-pipeline

Jetson Video Pipeline

用途

构建并运行 NVIDIA 官方示例命令，然后证明每个使用者都使用了前一阶段生成的确切字节。本技能负责编解码工作流和证据策略；不负责环境安装或产品支持声明。

终端门槛

在检查目标、其他技能或命令之前，先应用以下规则：

1. 对于仅请求 PSNR/SSIM 的情况，说明客观质量测量不属于本技能范围，需要单独授权的工作流；返回状态 not_evaluated，原因 out_of_scope，然后停止。不要提及工具，也不要索要媒体。对于仅限采集、传输、AI、显示或玻璃到玻璃延迟的请求，也执行相同处理。对于编解码加质量的混合请求，仅继续处理编解码部分，并将质量部分报告为状态 not_evaluated、原因 out_of_scope，不要悄然省略。

2. 应用媒体门槛之前，先对所有其他请求进行分类：

   • 对架构和路线问题返回 planned；这类问题不需要媒体。说明假设以及执行将验证的内容，然后停止；不要检查目标、检索内容、进行身份验证、分派配方或创建工作区。
   • 需要具体命令的试运行必须提供用户指定的路径或占位符，以及这些命令所需的元数据。媒体不必实际存在。通过 jetson-video-recipe 获取配方选项，报告状态 planned，不要进行检查、身份验证或启动任何操作。
   • 执行、验证和性能请求必须提供一个目标本地的确切媒体路径或一个用户提供的 HTTP(S) URL。若未提供，返回 input_required，简要说明预期路线，且只能使用本技能允许的示例所能表达的阶段；索要这一个项目，然后停止；不要检查目标、检索内容、进行身份验证、分派配方或创建工作区。将其他所有请求的转换标记为未解决，而不要编造可执行路线。

   绝不选择目录中的媒体或合成媒体。确定性设置冒烟测试素材仅允许用于范围受限的能力操作，绝不能作为流水线或性能的代表性证据。

选择并验证执行环境

步骤 3–4 适用于执行；步骤 5 也适用于包含配方的试运行。 对于其他规划，应保留明确指定的环境，但不要声称其当前可用；委托式的特定环境试运行会返回 selection_required，且不会对选项进行排序。

3. 保留明确指定的 native、pynvc 和 both。将“任选其一”、“最佳 可用选项”、“替我选择”或其他委托选择映射为 auto，而非 both。对于 auto：没有可用环境时返回 blocked，有一个时运行，有两个时返回 selection_required；不要对它们进行排序，也不要查询旧结果。

4. 通过公开技能调度，从 jetson-video-setup 获取新的只读就绪状态结果。对于 Python，传入用户提供的确切解释器，或当前对话中指定的解释器。否则，应在 调度前选择配置：解码性能工作可使用 pynvc-smoke；编码、分割、 advanced/decode.py、流水线和编码基准测试工作需要 full-samples。设置 检查该配置的常规路径；绝不要扫描查找 venv。如果只有 smoke 配置可用于 full-samples 工作，则在创建工作区之前返回 dependency_required，并指示用户 配置一个单独的 full-samples venv；绝不要原地升级 smoke venv。原生环境 可用的条件是存在一个已安装且经软件包验证的 SDK，以及一个由软件包提供的 Samples 根目录。Python 环境可用的条件是使用该确切解释器、可导入的 PyNvVideoCodec 发行包从其环境加载，并且 pip check 无异常。结果必须与请求的 Jetson 和 GPU 相符。如果候选环境不可用，应保留设置检查给出的原因。请求的流水线会提供 自身的操作证明。

5. 包含配方的编码和转码工作需要 jetson-video-recipe；包含性能阶段的验收请求 也需要 jetson-video-benchmark。通过公开技能调度调用任一技能，并将其结果 作为数据传入。如果缺少必需的配套技能，应保留已完成的阶段，并说明：我可以运行<stage>，但这需要<skill>，而该技能尚未安装。请安装<skill>后重试此阶段。

   “保留”意味着在面向用户的部分结果中，保留每个已完成阶段的状态以及当前 路径／大小／SHA-256 标识；这不会创建隐藏的可恢复状态。在同一请求中重试时，应 重新打开并重新计算这些工件的哈希，仅跳过身份未变的 complete 阶段。如果 标识已更改或缺失，或者后续请求未提供先前的证据，则使用新的工作区并重新运行 该阶段。

执行

1. 选择最小路由：encode_decode、native_transcode、 pynvc_segments、container_triage、av1_verify 或 acceptance。
2. 阅读 pipeline-workflow.md，了解阶段顺序、 内容处理、重试策略和报告要求。完整阅读一次 official-sample-contract.md，了解样例白名单、直接参数、标记 语法和帧布局检查。完整阅读一次 buffer-sharing-and-synchronization.md，了解文件系统边界。对于自定义的进程内 CUVID/CUDA/NVENC 图，还要完整阅读一次 in-process-codec-boundaries.md。
3. 执行时，将确切媒体规范化，记录其来源和身份，并使用全新的 0700 模式工作区及全新输出。试运行时，只使用提供的身份和元数据，说明假设，并展示计划执行的命令和交接过程；不得打开媒体或对启动器进行身份验证。
4. 执行时，对每个选定的原生样例或 wheel 成员进行身份验证，直接启动其原样参数列表，并保留未经编辑的日志。必须通过参考文档要求的退出、标记、计数、错误、新鲜度和布局检查。
5. 在每个生产者输出经过独立使用者处理之前和之后，重新打开并重新计算哈希。保留成功分支，将失败的对等分支报告为 partial，并遵循参考文档中的单次重试规则。
6. 在每个计划、结果以及生产者/使用者边界中直接提供适用的 io_contract。不得依赖契约模块，也不得根据设备内存模式推断外部共享。

路由要求

路由	必需证明
encode_decode	一种经过验证的配方；直接执行 AppEncCuda→AppDec，或由 wheel 管理的基本编码→高级解码；精确的原始和解码后字节数。
native_transcode	H.264 输入、精确的 HEVC 原生投影、AppTrans 输出、恰好一个已接受的转码标记，然后由 AppDec 处理同一哈希对应的数据；要求 AppTrans 和 AppDec 的帧数相等且大于零，并且在已知输入帧数时与其相等。
pynvc_segments	由 wheel 管理的计划/配置；每个声明的分段都是全新的且非空；独立解码每个分段并重新计算哈希。
container_triage	符合条件的 Jetson、确切的本地/已检索容器、在 AppDec 中进行内置 libavformat 解复用，或由 wheel 管理的高级解码，以及全新的解码输出。
av1_verify	精确的 AV1 原生配方；主机和视频内存模式；AppDec 使用每个确切的 IVF 输出，并报告预期帧数。
acceptance	简洁且可复现的报告，涵盖请求的就绪状态、能力、配方、编解码器和基准测试阶段，并提供每个阶段的状态和身份信息。

报告

使用 pipeline-workflow.md 中定义的状态和简洁报告格式。包含选定的 运行时、确切的媒体和配方身份、原样命令、生产者和使用者结果、解码布局/大小验证、 日志、限制和重试原因。必要时或按要求添加精简 JSON 或校验和清单。

限制

• 编解码器工作不能证明采集、传输、推理、显示、质量或端到端延迟。
• API 字段和清单不等同于操作证明或产品支持。
• 仅允许在经过身份验证的 NVIDIA 已发布样例内进行容器解复用。
• 执行参考文档中的所有确定性验收检查。
• 编解码器/API 能力和基准测试结果不能证明缓冲区互操作性、零拷贝或同步兼容性。