HyperFrames v0.7.72 解读：Plan v2 内容寻址传输与 Agent 媒体处理

HyperFrames v0.7.72 解读Plan v2 内容寻址传输与 Agent 媒体处理【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes分布式渲染撞上PLAN_TOO_LARGE成片音频时长比视频多出一截下游毫秒级校验直接判失败。HyperFrames v0.7.722026-07-26用带版本化、内容寻址的 Plan v2 协议拆掉了这条 2 GiB 传输墙同时收口了音频时长对齐并补上 Agent 可直调的 media-treatment 命令。完整变更见 releases/v0.7.72.md。⚡ 快速判断这版改了什么关注点这版的变化你需要做什么Plan v2 内容寻址传输manifest sha256 构件绕开 v1 的 2 GiB 单体包上限存量任务不动新集成接planV2()/planV2WithPublisher()音频时长精度填充、mux、容器时长全部对齐采样时间线用同一输入对比升级前后的输出时长差值media-treatment 命令新增 CLI支持确定性调色发现、应用、清除先跑--capabilities --json再--dry-run缓动与 lint确定性关键帧缓动运行时、off_pivot_rotation新检查、删除误报规则重跑hyperframes lint看新报告 Plan v2 内容寻址传输机制先看旧方案为什么走不通。v1 把整个 plan 目录打包成一个单体文件走传输通道超过 2 GiB 直接抛不可重试的PLAN_TOO_LARGE即使没超限每个 worker 也要接收全部共享文件带宽白烧。v2 把传输和执行拆开只传一个小的 manifest构件按 sha256 寻址、按需取用。按输入 → 处理 → 输出看输入planner 拿到项目目录与渲染配置对视频依赖不再整段打包。引擎用自己的 FrameLookupTable 在每个捕获的全局帧上逐帧求值算出每个 chunk 真正需要的帧legacy 视频元数据缺失时显式退化为full-source-pack。处理文件以 sha256 命名发布为构件。本地适配器同盘用硬链接同一份数据贴两个标签不占第二份数据块跨设备回退原子拷贝远程走 publisher 批量上传并发 16任何一步失败即abort()清理。输出manifest 记录每条构件的path、sha256、sizeBytes、所属 chunk 索引或all。worker 校验 size sha256 通过后才物化到本地执行前二次复验。新旧协议对比见 planProtocol.ts对比项v1 旧布局v2 新布局描述符plan-dir-v1/hyperframes-plan-hash-v1content-addressed-plan-v2/hyperframes-plan-manifest-hash-v2形态整目录单体包2 GiB 上限manifest sha256 构件无单体归档读取旧目录无描述符可直接回放必须先物化才能走 v1 读取路径manifest 自身另带planHash与本地执行计划哈希刻意区分可用hyperframes-plan-manifest-hash-v2前缀独立校验。️ 升级路径存量任务与双协议握手存量任务不用改一行都不用动。plan.json 缺protocol描述符时按旧 v1 布局回放描述符一旦出现三个字段必须完整且被识别不做静默猜测。确认集群握手用DISTRIBUTED_RENDER_CAPABILITIES校验 planner、chunk、assembler 各角色确认两种协议都被接受。接新集成入口旧plan()已标deprecated但保留新代码走下面两个函数。const local await planV2(projectDir, config, planV2Dir); const manifest await planV2WithPublisher(projectDir, config, publisher);选 publisher本地目录用内置适配器即可对象存储只实现putBlob、commitManifest、abort三个方法。云端侧确认AWS Lambda 的 handler 与 CDK 栈已接入 v2GCP Cloud Run 把 v2 完整性错误码归一化方便按统一码做重试决策。️ media-treatment 接入 Agent 流水线hyperframes media-treatment让 LLM 能发现、应用或清除确定性媒体处理全部输出支持--json。hyperframes media-treatment --selector #hero --grading {preset:warm-daylight} --apply --dry-run --json输出关键字段ok、actionapply/clear/analyze、changed、dryRun、before/after--analyze另返回diagnosis、warnings、suggestedPatch有界的主校正建议。能力总览把处理面分成 correction、grading、presets、finishing、palettes、animation、自定义 .cube LUT 与 overlays 八个族Studio 检查器在编辑器往返时保留已编排的处理。注意事项--clear与--apply互斥--dry-run只报告不落盘。--analyze拒绝远程与内联 URL且只吃本地资产远程媒体必须先 freeze。 渲染时长与确定性修复音频时长输出音频超出视频时长、下游校验失败 → padding filter 改为可移植写法填充按采样粒度归一化mux 在最短归一化流处停止最终时长封顶到视频时长。M4A 容器priming 样本与 edit list 时序处理过宽导致时长漂移 → priming 保留限定在 trim 场景AAC 包 padding 按包精确裁剪。诊断日志长视频的 ffprobe 输出刷爆日志 → 诊断输出保持有界。手写关键帧parsers 改写你显式写出的关键帧时序 → 时长标注与手写意图均原样保留。编辑器往返Studio 里已编排的媒体处理在保存往返后丢失 → 检查器保留 composed treatments。 升级后仍会撞到的边界v1 上限不动2 GiB 只在 v1 单体包路径生效超限仍抛不可重试的PLAN_TOO_LARGE只有 v2 构件分发能绕开内部上限设为Number.MAX_SAFE_INTEGERsha256 用 1 MiB 缓冲流式哈希超 2 GiB 构件也能有界内存地算摘要。帧率仅支持整数 24/30/60fpsDen必须为 1。格式HDR mp4 在分布式模式仍被拒绝抛FormatNotSupportedInDistributedErrorassemble 的cfr: true精确 CFR 重编码仅对 mp4 生效。分析范围--analyze只吃本地资产远程媒体先 freeze。退化情形v2 下视频缺 legacy 元数据会退化为full-source-pack带宽省不下来。✅ 升级后自测清单用DISTRIBUTED_RENDER_CAPABILITIES打印 worker 能力通过标准planner 产出 v1/v2chunk 与 assembler 均接受两种协议。把此前撞过PLAN_TOO_LARGE的大合成重跑一遍通过标准超 2 GiB 构件计算摘要时内存有界、任务完成。同一输入对比升级前后成片的音频时长通过标准差值为零贴合采样时间线。Agent 流水线先跑--capabilities --json再跑--dry-run --json通过标准changed字段符合预期且未落盘。重跑hyperframes lint通过标准被删规则不再误报off_pivot_rotation无新增误报。【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考