Hyperframes 中 VFR 屏幕录制视频的帧率冻结问题与回归测试设计【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframesmacOS ScreenCaptureKitReplayKit这类屏幕录制工具产出的视频常是可变帧率VFR, Variable Frame Rate格式素材时间戳稀疏且不均匀而r_frame_rate与avg_frame_rate严重背离。Hyperframes 的渲染引擎此前在抽取这类素材时会让画面在合成器中被冻结——fps滤镜吐出的帧数少于请求值查帧表返回空合成器便永久保持最后一帧。本文以仓库中packages/producer/tests/vfr-screen-recording/这套回归测试夹具为主线讲解该夹具的来源与构造方式、VFR 的判定阈值与归一化修复路径以及测试对渲染质量的具体校验指标帮助读者理解超帧率/低均帧率素材在 Hyperframes 中从探测到抽取、再到合成校验的完整处理链路。一、测试资产全貌一套为 VFR 冻结 bug 而生的回归夹具回归夹具位于packages/producer/tests/vfr-screen-recording/目录内包含NOTICE.md素材来源与版权属性说明即本篇文章的骨架文档详细记录了源录制、截取方式与被保留的帧率属性meta.json回归用例的描述与质量门禁minPsnr、maxFrameFailures 等src/clip.mp4核心 VFR 输入素材是 macOS ScreenCaptureKit 录制的 5 秒片段src/index.html渲染编排的 composition 页面将素材以data-media-start1定位进一条 3 秒的时间线output/compiled.html、output/output.mp4编译后的可执行页面与最终渲染产物。从meta.json的描述可以明确该夹具的定位Regression test for the VFR (variable-frame-rate) screen-recording freeze bug (PR #360). Renders a 3-second composition with a macOS ScreenCaptureKit clip (r_frame_rate120, avg≈36fps) seeked to mediaStart1. Pre-fix, the fps filter emitted long runs of duplicate frames that the compositor held as a frozen image; post-fix, VFR→CFR normalization keeps frame-accurate timing.也就是说它是一段可反复运行的回归证据只要有人重新引入 VFR 抽取缺陷这个用例的maxFrameFailures与minPsnr门禁就会被触发从而在 CI 中拦截问题。整套夹具与修复的代码位置存在明确呼应关系下文逐一拆解。二、素材溯源ReplayKit 录制的裁剪、降采样与时间戳保留NOTICE.md的核心义务是讲清楚素材从哪里来、改了什么、里面录的是什么这既是开源仓库对素材合规性的要求也直接决定了测试的有效性src/clip.mp4取自一段21 秒的 macOS ScreenCaptureKitReplayKit录制其com.apple.quicktime.authorQuickTime 标签可用于确认录制来源截取的是原录制的16s–21s 区间共 5 秒分辨率从原始的2746×1902 降采样到 480×332避免把超大素材塞进仓库重编码命令刻意保留了原始 VFR 时间戳ffmpeg -fps_mode passthrough -c:v libx264 -preset slow -crf 28 -an关键在于-fps_mode passthrough它让编码器原样透传输入帧的时间戳间隔不做任何 CFR固定帧率化从而把时间戳不均匀这一 VFR 病灶完整保留下来。-an去掉音频所以这套用例不校验音频呼应 meta.json 中minAudioCorrelation: 0的取值。同时 NOTICE 明确记录画面内容仅为公开的heygen-com/hyperframes仓库主页不含私有或可识别的个人内容——这保证了夹具可安全地随开源仓库分发。三、冻结 bug 的根因VFR 素材在 fps 滤镜下帧数不足代码注释把 bug 讲得非常直白见 videoFrameExtractor.ts 的回归说明When such inputs hitextractVideoFramesRanges-ss start -i ... -t dur -vf fpsNpipeline, the fps filter can emit fewer frames than requested — e.g. a 4-second segment at 30fps would produce ~90 frames instead of 120. FrameLookupTable.getFrameAtTime then returns null for out-of-range indices and the compositor holds the last valid frame, which the user perceives as the video freezing.故障链可以拆成四步VFR 素材的时间戳本身稀疏且不均匀旧的-vf fpsN抽取管线在遇到这些不规则时间戳时输出的帧数少于按时长 × 帧率计算出的期望帧数30fps×4s 应为 120 帧实际可能只有约 90 帧帧查找表FrameLookupTable.getFrameAtTime在索引越界时返回null合成器对null的兜底策略是保持最后一个有效帧于是画面长时间冻结直到时间线走完。这解释了为什么一个屏幕录制里画面没变化的正常场景会成为渲染事故统计性内容不动的片段在 VFR 下表现为长时间不出帧一旦抽取数量不足最终渲染就会把长时间定格当成真实画面输出。修复方案VFR→CFR 的一趟式归一化修复的核心是把 VFR 素材从-vf fpsN路径切换到 FFmpeg一趟式-fps_mode cfr -r fps归一化路径见 videoFrameExtractor.ts 的参数分支非 VFR 走原 fps 滤镜路径metadata.isVFR为真时追加-fps_mode cfr -r ffmpegFps在抽取的同时把时间轴规整为 CFR。额外好处是无需单独的归一化预编码步骤——packages/engine/src/services/extractionCache.ts中缓存版本从 v2 升到 v3 的注释也记录了这一变更one-pass VFR extraction (-fps_mode cfr) replaces the two-pass...。两套抽取路径的帧数边界语义差异由于 CFR 与 VFR 路径的结束边界舍入行为不同引擎与 producer 共享了帧数计算以避免误报。在 videoFrameExtractor.ts 中说明CFR 的 fps 滤镜在结束边界四舍五入到最近帧而 VFR 的-fps_mode cfr -r向上取整若不共享该计算完整抽取可能因两边差一帧而被误判失败。producer 侧 videoFrameCoverage.ts 的expectedFramesForClip同样实现了这一语义并在 expectedFramesForVideo 中依据entry.metadata.isVFR选择ceilVFR或nearestCFR的舍入策略确保覆盖率的期望帧数与底层抽取行为严格一致。四、夹具保留的属性与 VFR 判定实现10% 阈值NOTICE.md强调夹具保留了原录制的全部关键帧率属性这正是让 bug 可复现的前提。对照 meta.json 的说明核心指标如下表属性值含义r_frame_rate120/1标称/容器声明的最大帧率ScreenCaptureKit 以 120 采样avg_frame_rate~36.1 fps21720/601实际平均帧率按真实时间戳统计isVFRtrue两者偏差约 70%远超ffprobe.ts中的 10% 判定阈值修复前重复帧率中部 3s 片段以 30fps 抽取时约 34%与全量录制各片段观测到的 18%–44% 相符VFR 判定的源码实现producer 的packages/producer/src/utils/ffprobe.ts只是对hyperframes/engine的再导出真正的探测逻辑在 engine 的 ffprobe.ts。extractMediaMetadata中先对r_frame_rate与avg_frame_rate两个有理数字段做解析然后计算const rFps parseFrameRate(videoStream.r_frame_rate); const avgFps parseFrameRate(videoStream.avg_frame_rate); const fps avgFps || rFps; // VFR: r_frame_rate (max/nominal) differs from avg_frame_rate (actual average) by 10% const isVFR rFps 0 avgFps 0 Math.abs(rFps - avgFps) / Math.max(rFps, avgFps) 0.1;该实现位于 ffprobe.ts L745-L749对应的VideoMetadata.isVFR字段注释为 True when r_frame_rate and avg_frame_rate differ significantly (10%)。值得强调的是parseFrameRateL654-L689在解析120/1、21720/601这类有理数时做了大量防御拒绝分子分母为 0 或非有限数、拒绝超过两段的分式、拒绝符号异常避免把异常值泄漏到下游的-r编码参数与帧数运算中。对照本夹具120 vs 36.1的偏差约 70%远超 10% 阈值因此isVFR必然为 true素材会被稳定地路由进-fps_mode cfr归一化路径——这就是测试要覆盖的分支。五、编排用例的构造与质量门禁3 秒合成编排src/index.html 是一个极简 composition根元素声明data-composition-idvfr-screen-recording、data-duration3、data-width480、data-height332并带data-no-timeline无复杂时间轴仅一段静态场景。内部的video指向clip.mp4关键参数data-start0、data-duration3该片段在时间线占 3 秒data-media-start1从素材内部第 1 秒起播而非 0 秒刻意让抽取发生在素材中部因为冻结问题在素材中段 seek时最容易复现——正如 meta.json 所述 Pre-fix, the fps filter emitted long runs of duplicate frames顶层还覆盖了一个VFR标签层用于人工目检。output/compiled.html是引擎编译后内嵌字体与样式的最终页面可与src/index.html对照理解编译产物的形态。渲染参数与质量断言meta.json 同时携带了该用例的通过标准renderConfig: { fps: 30, workers: 1 }以 30fps、单 worker 确定性渲染便于逐帧比对minPsnr: 28渲染结果与参考视频的 PSNR 不低于 28dB用于防止画面出现大幅劣化例如整段冻结成同一帧maxFrameFailures: 2允许最多 2 帧级失败阈值校验对边界帧有显式容差可对比 videoFrameCoverage.test.ts 中容忍 VFR 抽取短片段边界差一帧的用例设计minAudioCorrelation: 0、maxAudioLagWindows: 1由于素材以-an编码为无音轨音频相关度要求放宽为 0但音频滞后窗口上限仍保留 1防止回归用例因渲染器对静音轨的错误处理而翻车。这些门禁直接作用于output/output.mp4把画面是否真的在动转化为可自动量化的数字而非依赖人工观看。六、更接近生产环境的 VFR 合成回归测试除真实录屏夹具外引擎还提供了用 FFmpeg 现场合成的 VFR 素材回归测试见 videoFrameExtractor.test.ts L1563 起testsrc2s320x180:d10:rate60生成 10 秒 60fps 测试图再用select表达式丢弃四段 1 秒窗口帧 30–89、180–239、330–389、480–539配合-vsync vfr编码模拟屏幕录制中画面无变化的静态段落得到声明 60fps、实际约 36fps的素材——与真机录屏的属性同构。测试同时用-g 600 -keyint_min 600强制单一关键帧确保中段 seek 不会吸附到 IDR 帧造成计数漂移。这说明仓库对 VFR 的防护是双保险既有贴近真实的 ReplayKit 录屏夹具producer 端回归又有完全可控的合成夹具engine 端回归覆盖从底层抽取到上层合成的整条链路。此外captureHdrResources.test.ts 也用sparse-vfr.mp4夹具验证了元数据层面对稀疏 VFR 素材的isVFR判定。七、编译期的 VFR 提示与建议预编码命令在用户侧如果 HTML 素材里引用了 VFR 视频producer 的编译阶段会给出非阻塞告警。见 htmlCompiler.ts 的 advisory 检查编译器对每个本地video并发执行关键帧间隔分析与媒体元数据探测若metadata.isVFR为真则向 stderr 输出类似[Compiler] Video id is variable frame rate (VFR); the engine will normalize it to CFR before frame extraction. If rendering feels slow on this video, pre-encode once with: ffmpeg -i src -c:v libx264 -r 30 -g 30 -keyint_min 30 -movflags faststart -c:a copy output.mp4几点值得注意的实现细节这些探测是fire-and-forget的且通过withMediaProbeSlot限流只产生警告、不阻塞编译返回通过isHttpUrl直接跳过远程 URL远程素材无法在编译期本地探测告警走defaultLogger.warnstderr而非console.infostdout注释明确指出这是为了不污染check --json/validate --json的 stdout 输出引擎虽然会自动把 VFR 归一化到 CFR但对于体量较大的录屏素材先手动预编码一次仍能显著缩短每次渲染的抽取耗时——这是工程上推荐的素材入库习惯。八、如何在本地复现与验证这套回归读者可在本仓库中完整走查这套回归流程阅读 NOTICE.md确认素材来源与保留属性检查 src/clip.mp4可用ffprobe验证r_frame_rate120/1、avg_frame_rate≈21720/601并运行extractMediaMetadata确认isVFRtrue用 src/index.html 作为 composition对比 output/compiled.html 观察编译产物差异以 meta.json 的renderConfig30fps、单 worker执行渲染依据minPsnr、maxFrameFailures等门禁判定通过与否修复前该用例会因 fps 滤镜的重复帧长串而冻结修复后 VFR→CFR 归一化保证逐帧时间精确。小结VFR 屏幕录制素材在 Hyperframes 中走一条完整的探测—判定—归一化—覆盖率校验链路ffprobe.ts用 10% 偏差阈值识别 VFRvideoFrameExtractor.ts用-fps_mode cfr -r一趟式归一化消除冻结缺陷videoFrameCoverage.ts针对两种抽取路径维护一致的帧数舍入语义而packages/producer/tests/vfr-screen-recording/这套夹具则以一份严格溯源、完整保留帧率属性的 ReplayKit 录屏把这条链路固化成了可持续回归的质量门槛——既是一份合规的素材来源说明更是一个可复现、可量化的渲染缺陷标本。【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hyperframes 中 VFR 屏幕录制视频的帧率冻结问题与回归测试设计
Hyperframes 中 VFR 屏幕录制视频的帧率冻结问题与回归测试设计【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframesmacOS ScreenCaptureKitReplayKit这类屏幕录制工具产出的视频常是可变帧率VFR, Variable Frame Rate格式素材时间戳稀疏且不均匀而r_frame_rate与avg_frame_rate严重背离。Hyperframes 的渲染引擎此前在抽取这类素材时会让画面在合成器中被冻结——fps滤镜吐出的帧数少于请求值查帧表返回空合成器便永久保持最后一帧。本文以仓库中packages/producer/tests/vfr-screen-recording/这套回归测试夹具为主线讲解该夹具的来源与构造方式、VFR 的判定阈值与归一化修复路径以及测试对渲染质量的具体校验指标帮助读者理解超帧率/低均帧率素材在 Hyperframes 中从探测到抽取、再到合成校验的完整处理链路。一、测试资产全貌一套为 VFR 冻结 bug 而生的回归夹具回归夹具位于packages/producer/tests/vfr-screen-recording/目录内包含NOTICE.md素材来源与版权属性说明即本篇文章的骨架文档详细记录了源录制、截取方式与被保留的帧率属性meta.json回归用例的描述与质量门禁minPsnr、maxFrameFailures 等src/clip.mp4核心 VFR 输入素材是 macOS ScreenCaptureKit 录制的 5 秒片段src/index.html渲染编排的 composition 页面将素材以data-media-start1定位进一条 3 秒的时间线output/compiled.html、output/output.mp4编译后的可执行页面与最终渲染产物。从meta.json的描述可以明确该夹具的定位Regression test for the VFR (variable-frame-rate) screen-recording freeze bug (PR #360). Renders a 3-second composition with a macOS ScreenCaptureKit clip (r_frame_rate120, avg≈36fps) seeked to mediaStart1. Pre-fix, the fps filter emitted long runs of duplicate frames that the compositor held as a frozen image; post-fix, VFR→CFR normalization keeps frame-accurate timing.也就是说它是一段可反复运行的回归证据只要有人重新引入 VFR 抽取缺陷这个用例的maxFrameFailures与minPsnr门禁就会被触发从而在 CI 中拦截问题。整套夹具与修复的代码位置存在明确呼应关系下文逐一拆解。二、素材溯源ReplayKit 录制的裁剪、降采样与时间戳保留NOTICE.md的核心义务是讲清楚素材从哪里来、改了什么、里面录的是什么这既是开源仓库对素材合规性的要求也直接决定了测试的有效性src/clip.mp4取自一段21 秒的 macOS ScreenCaptureKitReplayKit录制其com.apple.quicktime.authorQuickTime 标签可用于确认录制来源截取的是原录制的16s–21s 区间共 5 秒分辨率从原始的2746×1902 降采样到 480×332避免把超大素材塞进仓库重编码命令刻意保留了原始 VFR 时间戳ffmpeg -fps_mode passthrough -c:v libx264 -preset slow -crf 28 -an关键在于-fps_mode passthrough它让编码器原样透传输入帧的时间戳间隔不做任何 CFR固定帧率化从而把时间戳不均匀这一 VFR 病灶完整保留下来。-an去掉音频所以这套用例不校验音频呼应 meta.json 中minAudioCorrelation: 0的取值。同时 NOTICE 明确记录画面内容仅为公开的heygen-com/hyperframes仓库主页不含私有或可识别的个人内容——这保证了夹具可安全地随开源仓库分发。三、冻结 bug 的根因VFR 素材在 fps 滤镜下帧数不足代码注释把 bug 讲得非常直白见 videoFrameExtractor.ts 的回归说明When such inputs hitextractVideoFramesRanges-ss start -i ... -t dur -vf fpsNpipeline, the fps filter can emit fewer frames than requested — e.g. a 4-second segment at 30fps would produce ~90 frames instead of 120. FrameLookupTable.getFrameAtTime then returns null for out-of-range indices and the compositor holds the last valid frame, which the user perceives as the video freezing.故障链可以拆成四步VFR 素材的时间戳本身稀疏且不均匀旧的-vf fpsN抽取管线在遇到这些不规则时间戳时输出的帧数少于按时长 × 帧率计算出的期望帧数30fps×4s 应为 120 帧实际可能只有约 90 帧帧查找表FrameLookupTable.getFrameAtTime在索引越界时返回null合成器对null的兜底策略是保持最后一个有效帧于是画面长时间冻结直到时间线走完。这解释了为什么一个屏幕录制里画面没变化的正常场景会成为渲染事故统计性内容不动的片段在 VFR 下表现为长时间不出帧一旦抽取数量不足最终渲染就会把长时间定格当成真实画面输出。修复方案VFR→CFR 的一趟式归一化修复的核心是把 VFR 素材从-vf fpsN路径切换到 FFmpeg一趟式-fps_mode cfr -r fps归一化路径见 videoFrameExtractor.ts 的参数分支非 VFR 走原 fps 滤镜路径metadata.isVFR为真时追加-fps_mode cfr -r ffmpegFps在抽取的同时把时间轴规整为 CFR。额外好处是无需单独的归一化预编码步骤——packages/engine/src/services/extractionCache.ts中缓存版本从 v2 升到 v3 的注释也记录了这一变更one-pass VFR extraction (-fps_mode cfr) replaces the two-pass...。两套抽取路径的帧数边界语义差异由于 CFR 与 VFR 路径的结束边界舍入行为不同引擎与 producer 共享了帧数计算以避免误报。在 videoFrameExtractor.ts 中说明CFR 的 fps 滤镜在结束边界四舍五入到最近帧而 VFR 的-fps_mode cfr -r向上取整若不共享该计算完整抽取可能因两边差一帧而被误判失败。producer 侧 videoFrameCoverage.ts 的expectedFramesForClip同样实现了这一语义并在 expectedFramesForVideo 中依据entry.metadata.isVFR选择ceilVFR或nearestCFR的舍入策略确保覆盖率的期望帧数与底层抽取行为严格一致。四、夹具保留的属性与 VFR 判定实现10% 阈值NOTICE.md强调夹具保留了原录制的全部关键帧率属性这正是让 bug 可复现的前提。对照 meta.json 的说明核心指标如下表属性值含义r_frame_rate120/1标称/容器声明的最大帧率ScreenCaptureKit 以 120 采样avg_frame_rate~36.1 fps21720/601实际平均帧率按真实时间戳统计isVFRtrue两者偏差约 70%远超ffprobe.ts中的 10% 判定阈值修复前重复帧率中部 3s 片段以 30fps 抽取时约 34%与全量录制各片段观测到的 18%–44% 相符VFR 判定的源码实现producer 的packages/producer/src/utils/ffprobe.ts只是对hyperframes/engine的再导出真正的探测逻辑在 engine 的 ffprobe.ts。extractMediaMetadata中先对r_frame_rate与avg_frame_rate两个有理数字段做解析然后计算const rFps parseFrameRate(videoStream.r_frame_rate); const avgFps parseFrameRate(videoStream.avg_frame_rate); const fps avgFps || rFps; // VFR: r_frame_rate (max/nominal) differs from avg_frame_rate (actual average) by 10% const isVFR rFps 0 avgFps 0 Math.abs(rFps - avgFps) / Math.max(rFps, avgFps) 0.1;该实现位于 ffprobe.ts L745-L749对应的VideoMetadata.isVFR字段注释为 True when r_frame_rate and avg_frame_rate differ significantly (10%)。值得强调的是parseFrameRateL654-L689在解析120/1、21720/601这类有理数时做了大量防御拒绝分子分母为 0 或非有限数、拒绝超过两段的分式、拒绝符号异常避免把异常值泄漏到下游的-r编码参数与帧数运算中。对照本夹具120 vs 36.1的偏差约 70%远超 10% 阈值因此isVFR必然为 true素材会被稳定地路由进-fps_mode cfr归一化路径——这就是测试要覆盖的分支。五、编排用例的构造与质量门禁3 秒合成编排src/index.html 是一个极简 composition根元素声明data-composition-idvfr-screen-recording、data-duration3、data-width480、data-height332并带data-no-timeline无复杂时间轴仅一段静态场景。内部的video指向clip.mp4关键参数data-start0、data-duration3该片段在时间线占 3 秒data-media-start1从素材内部第 1 秒起播而非 0 秒刻意让抽取发生在素材中部因为冻结问题在素材中段 seek时最容易复现——正如 meta.json 所述 Pre-fix, the fps filter emitted long runs of duplicate frames顶层还覆盖了一个VFR标签层用于人工目检。output/compiled.html是引擎编译后内嵌字体与样式的最终页面可与src/index.html对照理解编译产物的形态。渲染参数与质量断言meta.json 同时携带了该用例的通过标准renderConfig: { fps: 30, workers: 1 }以 30fps、单 worker 确定性渲染便于逐帧比对minPsnr: 28渲染结果与参考视频的 PSNR 不低于 28dB用于防止画面出现大幅劣化例如整段冻结成同一帧maxFrameFailures: 2允许最多 2 帧级失败阈值校验对边界帧有显式容差可对比 videoFrameCoverage.test.ts 中容忍 VFR 抽取短片段边界差一帧的用例设计minAudioCorrelation: 0、maxAudioLagWindows: 1由于素材以-an编码为无音轨音频相关度要求放宽为 0但音频滞后窗口上限仍保留 1防止回归用例因渲染器对静音轨的错误处理而翻车。这些门禁直接作用于output/output.mp4把画面是否真的在动转化为可自动量化的数字而非依赖人工观看。六、更接近生产环境的 VFR 合成回归测试除真实录屏夹具外引擎还提供了用 FFmpeg 现场合成的 VFR 素材回归测试见 videoFrameExtractor.test.ts L1563 起testsrc2s320x180:d10:rate60生成 10 秒 60fps 测试图再用select表达式丢弃四段 1 秒窗口帧 30–89、180–239、330–389、480–539配合-vsync vfr编码模拟屏幕录制中画面无变化的静态段落得到声明 60fps、实际约 36fps的素材——与真机录屏的属性同构。测试同时用-g 600 -keyint_min 600强制单一关键帧确保中段 seek 不会吸附到 IDR 帧造成计数漂移。这说明仓库对 VFR 的防护是双保险既有贴近真实的 ReplayKit 录屏夹具producer 端回归又有完全可控的合成夹具engine 端回归覆盖从底层抽取到上层合成的整条链路。此外captureHdrResources.test.ts 也用sparse-vfr.mp4夹具验证了元数据层面对稀疏 VFR 素材的isVFR判定。七、编译期的 VFR 提示与建议预编码命令在用户侧如果 HTML 素材里引用了 VFR 视频producer 的编译阶段会给出非阻塞告警。见 htmlCompiler.ts 的 advisory 检查编译器对每个本地video并发执行关键帧间隔分析与媒体元数据探测若metadata.isVFR为真则向 stderr 输出类似[Compiler] Video id is variable frame rate (VFR); the engine will normalize it to CFR before frame extraction. If rendering feels slow on this video, pre-encode once with: ffmpeg -i src -c:v libx264 -r 30 -g 30 -keyint_min 30 -movflags faststart -c:a copy output.mp4几点值得注意的实现细节这些探测是fire-and-forget的且通过withMediaProbeSlot限流只产生警告、不阻塞编译返回通过isHttpUrl直接跳过远程 URL远程素材无法在编译期本地探测告警走defaultLogger.warnstderr而非console.infostdout注释明确指出这是为了不污染check --json/validate --json的 stdout 输出引擎虽然会自动把 VFR 归一化到 CFR但对于体量较大的录屏素材先手动预编码一次仍能显著缩短每次渲染的抽取耗时——这是工程上推荐的素材入库习惯。八、如何在本地复现与验证这套回归读者可在本仓库中完整走查这套回归流程阅读 NOTICE.md确认素材来源与保留属性检查 src/clip.mp4可用ffprobe验证r_frame_rate120/1、avg_frame_rate≈21720/601并运行extractMediaMetadata确认isVFRtrue用 src/index.html 作为 composition对比 output/compiled.html 观察编译产物差异以 meta.json 的renderConfig30fps、单 worker执行渲染依据minPsnr、maxFrameFailures等门禁判定通过与否修复前该用例会因 fps 滤镜的重复帧长串而冻结修复后 VFR→CFR 归一化保证逐帧时间精确。小结VFR 屏幕录制素材在 Hyperframes 中走一条完整的探测—判定—归一化—覆盖率校验链路ffprobe.ts用 10% 偏差阈值识别 VFRvideoFrameExtractor.ts用-fps_mode cfr -r一趟式归一化消除冻结缺陷videoFrameCoverage.ts针对两种抽取路径维护一致的帧数舍入语义而packages/producer/tests/vfr-screen-recording/这套夹具则以一份严格溯源、完整保留帧率属性的 ReplayKit 录屏把这条链路固化成了可持续回归的质量门槛——既是一份合规的素材来源说明更是一个可复现、可量化的渲染缺陷标本。【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考