| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(agent): run edit_item and manage_effects without the browser The offline MCP executor — and therefore the occ CLI — can now run the two tools whose validators consult the GL catalogs. Shader sources: GL catalogs no longer import ./x.frag?raw. That suffix only resolves inside Vite's own client build graph; Node, the desktop esbuild bundle and the rolldown step that bundles config/vite.config.ts all fail on it, which is how reaching these modules broke npm run build. Every .frag keeps a generated .frag.ts twin next to it (scripts/sync-shader-sources.mjs), enforced by scripts/shader-sources.verify.mjs in npm test and prebuild, so the shader text is still authored once and every host resolves it identically. Whitelist: edit_item and manage_effects join the server-direct set after review — both only touch the draft's EditorCore commands plus state/doc. edit_item's template-add path degrades with an explicit error because the offline context carries no template catalog; that is a capability gap, not a silent no-op. Executor: both schemas are exposed offline and dispatched through a lazy import, so a bare tsx host that never calls them never loads the GL modules. Shared paths touched: src/gl (import form only — shader text unchanged and the twins are verified byte-for-byte equal), the external-tool-policy whitelist, the offline tool catalog and executor, package.json (two scripts, one command in test:serial, one prebuild check). Preview, export and the Remotion render path are untouched. Verification: npm test 181/181 green (including the two new verifies); npm run build; npm run desktop:build:main (51 shaders inlined into app-main.mjs); npm run verify:mcp; cli/cli.verify.ts drives edit_item through an offline session and reads the written opacity back; offline-runtime, offline-mcp and offline-mcp-process-recovery verifies; chroma-key, clipFxPreview and clipFxExport GL verifies; tsc -b; lint 0 warnings; registration and gate coverage. | 1 个月前 | |
feat(agent): run edit_item and manage_effects without the browser The offline MCP executor — and therefore the occ CLI — can now run the two tools whose validators consult the GL catalogs. Shader sources: GL catalogs no longer import ./x.frag?raw. That suffix only resolves inside Vite's own client build graph; Node, the desktop esbuild bundle and the rolldown step that bundles config/vite.config.ts all fail on it, which is how reaching these modules broke npm run build. Every .frag keeps a generated .frag.ts twin next to it (scripts/sync-shader-sources.mjs), enforced by scripts/shader-sources.verify.mjs in npm test and prebuild, so the shader text is still authored once and every host resolves it identically. Whitelist: edit_item and manage_effects join the server-direct set after review — both only touch the draft's EditorCore commands plus state/doc. edit_item's template-add path degrades with an explicit error because the offline context carries no template catalog; that is a capability gap, not a silent no-op. Executor: both schemas are exposed offline and dispatched through a lazy import, so a bare tsx host that never calls them never loads the GL modules. Shared paths touched: src/gl (import form only — shader text unchanged and the twins are verified byte-for-byte equal), the external-tool-policy whitelist, the offline tool catalog and executor, package.json (two scripts, one command in test:serial, one prebuild check). Preview, export and the Remotion render path are untouched. Verification: npm test 181/181 green (including the two new verifies); npm run build; npm run desktop:build:main (51 shaders inlined into app-main.mjs); npm run verify:mcp; cli/cli.verify.ts drives edit_item through an offline session and reads the written opacity back; offline-runtime, offline-mcp and offline-mcp-process-recovery verifies; chroma-key, clipFxPreview and clipFxExport GL verifies; tsc -b; lint 0 warnings; registration and gate coverage. | 1 个月前 | |
fix(export): decode Windows server-render video with the FFmpeg compositor On Windows a server export whose timeline holds video could sit at ~10% with no error: a frame's "Extracting frame at time ..." delayRender never cleared, so the render waited out the ten-minute per-frame budget before failing. All three reports on the issue come from Windows 10/11 machines rendering H.264 sources. RuntimeVideo discarded browserRenderer and always decoded with @remotion/media's <Video> (Mediabunny + WebCodecs inside chrome-headless-shell). With the Windows render GL backend (angle, D3D11) Chrome can give WebCodecs the D3D11 hardware decoder. Its small picture pool runs dry while Mediabunny holds decoded frames open, and it then stops producing frames without an error. The extraction never settles, so @remotion/media's own <OffthreadVideo> fallback (reached only through an error result) never runs. Remotion reports the same hang with the exact versions this app ships (4.0.509, chrome-headless-shell 149.0.7790.0) and finds <OffthreadVideo> unaffected (remotion-dev/remotion#10701). The #11020 fix only shipped in 4.0.521, and #11393 still reports stalls after it. Forcing the <OffthreadVideo> branch made the reporter's timeline export. remotion/video-decoder.mjs now picks the server render's video decoder: 'offthread' on win32, 'webcodecs' elsewhere, and CC_RENDER_VIDEO_DECODER=webcodecs|offthread overrides it on any platform. render.mjs passes it to the composition as the serverVideoDecoder input prop from renderTimeline, renderClip and renderTimelineStills. TimelineComposition provides it through context (src/editor/serverVideoDecoder.ts). RuntimeVideo (plain clips, background fills, shared runs) and ClipFx (GL effect inputs) render <OffthreadVideo> only in a headless server render. The Player and the in-browser export (isPlayer, isClientSideRendering, browserRenderer) keep @remotion/media whatever the props say. This is not the switch 5b747273 reverted. f32adad1 (PR #97) sent every server render on every platform through <OffthreadVideo>, undoing 594e122b's single frame-accurate decoder path; its removed comments and 359c6fc7 note that the two decoders skew fractional-rate sources by a frame. Here: - Only Windows changes by default. macOS and Linux renders keep the @remotion/media path, which the macOS frame-sync job still pins. - Within one render, plain and effect layers always share one decoder. - The compositor now picks the frames the Player picks. Mediabunny shows the last frame at most 1 ms after the requested time; the compositor shows the last frame at or before it. <OffthreadVideo> is therefore asked 1 ms later (offthreadTrimBefore). On 25, 30 and 60 fps sources both decoders already agreed. On a 29.97 fps source in a 30 fps timeline they differed on 30 of 36 frames (and 13 of 36 when trimmed at 2x); they now agree on every frame. - WebM sources (VP9-alpha MG bakes, the desktop's transparent-MOV proxies) extract as PNG so alpha survives. Other footage keeps the fast opaque (BMP) extraction. ClipFx hands <OffthreadVideo> a stable onVideoFrame. Its image reloads whenever that callback changes identity, which happened every frame just after <OffthreadVideo> revoked the frame's blob URL, logging one failed-load warning per effect frame. Other effects on Windows server renders: - A clip's own audio is mixed by FFmpeg, as the server Audio path already mixes audio items, so speed changes keep pitch. - Each source is copied into Remotion's temporary download directory while the render runs. - Colour conversion and chroma upsampling differ slightly from @remotion/media's. On a synthetic test pattern the two outputs are about 30 dB PSNR apart, while showing the same frames. - GLSL transition windows still read an HTML5 <video>; they did not hang in the reports. Tests: - remotion/video-decoder.verify.mjs: platform defaults, the override in both directions, and the environment read on every render. - src/editor/serverVideoDecoder.verify.ts: the decoder each environment gets, including the hook under real Remotion environment and decoder contexts. A server render follows the server; the Player, the in-browser export and browserRenderer keep @remotion/media. Also the 1 ms shift and the WebM-only transparency. - remotion/video-decoder-render.verify.mjs renders through both decoders. 29.97 fps H.264 with audio in a 30 fps timeline (plain and trimmed 2x) must show exactly the frames the Player's rule selects and keep its audio. A VP9-alpha overlay must leave the red track below it visible. ProRes, which @remotion/media refuses, must render with 'offthread' through renderTimeline (a plain and a GL-effect clip), renderClip and renderTimelineStills, and fail with 'webcodecs'. Mutation-checked: removing the provider, the input prop, either component's switch, the 1 ms shift or the WebM transparency each fails it. - src/gl/clipFxExport.offthread.verify.mjs reruns the effect and transition frame-sync fixture with 'offthread'. clipFxExport.verify.mjs now names its decoder in its output. The new verifies run in npm test, and the render ones also in the macOS frame-sync CI job, where exact frame mapping is asserted. Validation (macOS arm64): npx tsc -p tsconfig.app.json and tsconfig.node.json (both clean); npm run lint (0 warnings); the four new verifies; 44 export/render-related verify segments, including clipFxExport under both decoders; scripts/verify-gate-coverage and verify-registration. The D3D11 hang itself needs a Windows GPU and was not reproduced here. Fixes #162. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 30 天前 | |
fix(render): decode GL transition inputs with the export's video decoder The macOS frame-sync job failed intermittently in its Windows-decoder step (3 of 9 recent runs): a "Rendering <Html5Video /> ..." delayRender on a transition frame never cleared, and the render failed after 598 s. GlTransition fed its two inputs from <Video> from 'remotion', which is <Html5Video>, whatever decoder the server picked. So every GLSL transition in a Windows server export, cross-dissolve included, still depended on Chrome's HTML5 seek next to the <OffthreadVideo> layers. #162 moved every other layer off that path. A seek that hangs there holds the export on that frame until the ten-minute budget runs out, the symptom #162 reported. When those inputs did not hang, they showed the wrong frames, on every platform. The GL pass draws in a layout effect. <Html5Video> seeks in a passive effect, which runs after it. So each render tab drew whatever its <video> showed before seeking, and only the first window frame a tab mounted was current. A split-screen transition rendered with 8 tabs got all 20 window frames wrong, with both the webcodecs and the offthread decoder. Frames 43-54 showed content from about 8 frames earlier. The first 8 showed the outgoing clip one source frame later than the Player. In a server render GlTransition now decodes both inputs with the export's decoder, as the clip layers under the window do. That is <OffthreadVideo> under 'offthread', with the trim that matches the Player and WebM alpha, and @remotion/media otherwise. A stable onVideoFrame (src/gl/capturedFrame.ts) copies each decoded frame and tags it with the frame it belongs to. The GL pass draws only once both inputs hold the current frame. The Player keeps its live <video> elements. Tests: - remotion/video-decoder-render.verify.mjs: a split-screen GLSL transition must show the Player's frame on both halves of every window frame, for each server decoder. With the old inputs it fails (frame 28 showed source frames [24, 0], not [28, 4]); it passes now. It runs in the macOS frame-sync job. - clipFxExport.offthread.verify.mjs passed 15 consecutive local runs; clipFxExport.verify.mjs, the preview, transition and decoder verifies, tsc -b and lint pass. - A transition whose outgoing handle runs past the source's last frame still renders with both decoders, frozen on that last frame. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 28 天前 | |
fix(render): decode GL transition inputs with the export's video decoder The macOS frame-sync job failed intermittently in its Windows-decoder step (3 of 9 recent runs): a "Rendering <Html5Video /> ..." delayRender on a transition frame never cleared, and the render failed after 598 s. GlTransition fed its two inputs from <Video> from 'remotion', which is <Html5Video>, whatever decoder the server picked. So every GLSL transition in a Windows server export, cross-dissolve included, still depended on Chrome's HTML5 seek next to the <OffthreadVideo> layers. #162 moved every other layer off that path. A seek that hangs there holds the export on that frame until the ten-minute budget runs out, the symptom #162 reported. When those inputs did not hang, they showed the wrong frames, on every platform. The GL pass draws in a layout effect. <Html5Video> seeks in a passive effect, which runs after it. So each render tab drew whatever its <video> showed before seeking, and only the first window frame a tab mounted was current. A split-screen transition rendered with 8 tabs got all 20 window frames wrong, with both the webcodecs and the offthread decoder. Frames 43-54 showed content from about 8 frames earlier. The first 8 showed the outgoing clip one source frame later than the Player. In a server render GlTransition now decodes both inputs with the export's decoder, as the clip layers under the window do. That is <OffthreadVideo> under 'offthread', with the trim that matches the Player and WebM alpha, and @remotion/media otherwise. A stable onVideoFrame (src/gl/capturedFrame.ts) copies each decoded frame and tags it with the frame it belongs to. The GL pass draws only once both inputs hold the current frame. The Player keeps its live <video> elements. Tests: - remotion/video-decoder-render.verify.mjs: a split-screen GLSL transition must show the Player's frame on both halves of every window frame, for each server decoder. With the old inputs it fails (frame 28 showed source frames [24, 0], not [28, 4]); it passes now. It runs in the macOS frame-sync job. - clipFxExport.offthread.verify.mjs passed 15 consecutive local runs; clipFxExport.verify.mjs, the preview, transition and decoder verifies, tsc -b and lint pass. - A transition whose outgoing handle runs past the source's last frame still renders with both decoders, frozen on that last frame. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 28 天前 | |
Initial commit | 3 个月前 | |
test(render): skip the offthread frame-sync verify on Linux CI Since 0075911c added it to npm test, the Verify job has failed on every PR: under the <OffthreadVideo> decoder the GPU-less Linux runner's headless render gets no WebGL2 context ("WebGL2 not available"), so the effect never applies and the assertion fails. Linux renders never use this decoder (it is the Windows default), and the macOS frame-sync job in ci.yml already runs this file at full strength, so skip it on Linux CI the same way the base fixture gates its frame-sync assertions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 28 天前 | |
test(render): delete the serve bundle each render verify webpacks getServeUrl() webpacks the Remotion entry into a fresh remotion-webpack-bundle-* directory in the OS temp dir (about 150 MB) once per process and nothing removes it. Every render verify therefore left one behind on each run: clipFxExport.verify.mjs, and since the Windows decoder change also clipFxExport.offthread.verify.mjs and video-decoder-render.verify.mjs, about 450 MB per npm test. A morning of local runs filled 2.6 GB of temp space. serve-bundle.mjs gains disposeServeBundle(), which deletes the bundle this process built and resets the cache; a prebuilt CC_REMOTION_BUNDLE is never touched. Its media/uploads entry is a symlink (a junction on Windows) to the live uploads directory, so that link is unlinked on its own before the recursive delete. Both render verifies call it in their finally blocks, and video-decoder-render.verify.mjs asserts after its renders that the bundle is gone and the linked uploads (its fixtures) are untouched. The Windows render workflow runs that check too, where the link is a junction. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 30 天前 | |
fix: smooth video playback across clip boundaries Use the shared @remotion/media decode path for timeline and GL effect frames, avoid per-frame React state updates, and keep Player input props stable. Shared-path impact: preview and render media selection now use one frame-accurate decoder path; image rendering and effect fallback behavior remain unchanged. Verified with 7/7 affected checks, zero-warning lint, production build, ClipFx frame-accuracy export checks, and a real Chrome playback run on the 20-cut fixture with zero long tasks or gaps above 50ms. | 2 个月前 | |
feat: land professional timeline, durable jobs, and safe media flows Add slip/rate-stretch, nested sequences, multicam sync, durable generation/export recovery, media intelligence, and hardened MCP/media boundaries while keeping the implementation local-first and cross-platform. | 2 个月前 | |
feat(agent): run edit_item and manage_effects without the browser The offline MCP executor — and therefore the occ CLI — can now run the two tools whose validators consult the GL catalogs. Shader sources: GL catalogs no longer import ./x.frag?raw. That suffix only resolves inside Vite's own client build graph; Node, the desktop esbuild bundle and the rolldown step that bundles config/vite.config.ts all fail on it, which is how reaching these modules broke npm run build. Every .frag keeps a generated .frag.ts twin next to it (scripts/sync-shader-sources.mjs), enforced by scripts/shader-sources.verify.mjs in npm test and prebuild, so the shader text is still authored once and every host resolves it identically. Whitelist: edit_item and manage_effects join the server-direct set after review — both only touch the draft's EditorCore commands plus state/doc. edit_item's template-add path degrades with an explicit error because the offline context carries no template catalog; that is a capability gap, not a silent no-op. Executor: both schemas are exposed offline and dispatched through a lazy import, so a bare tsx host that never calls them never loads the GL modules. Shared paths touched: src/gl (import form only — shader text unchanged and the twins are verified byte-for-byte equal), the external-tool-policy whitelist, the offline tool catalog and executor, package.json (two scripts, one command in test:serial, one prebuild check). Preview, export and the Remotion render path are untouched. Verification: npm test 181/181 green (including the two new verifies); npm run build; npm run desktop:build:main (51 shaders inlined into app-main.mjs); npm run verify:mcp; cli/cli.verify.ts drives edit_item through an offline session and reads the written opacity back; offline-runtime, offline-mcp and offline-mcp-process-recovery verifies; chroma-key, clipFxPreview and clipFxExport GL verifies; tsc -b; lint 0 warnings; registration and gate coverage. | 1 个月前 | |
fix(quality): revive watchdogs, fix orphan checks, and unify skill count Resurrect two silent quality gateways and wire them into the test suite, catch up CHANGELOG and skill-count docs, and convert every orphaned verify/check file into a tracked, npm-wired regression. Quality watchdogs (now in pretest): - verify:shortcuts: catalog count 54->56, keymap scope, native-copy - verify:i18n: check-i18n.mjs now exempts test files; 4 real UI files wrapped in t(); 62 missing en keys added across 9 dict slices - Fixed stableOverrideKeys merging distinct legacy caption overrides when wordRef is empty (3 overrides collapsed to one key) - Fixed buildFollowupWidget silently dropping option-less choice fields (now degrades to a prompt line) - Fixed apply_script repack being silently rejected by the same-track overlap guard: reorderTrackItems now accepts explicit starts and apply_script rebuys atomically per track Docs: - CHANGELOG [Unreleased]: SQLite migration, session-recovery, chat-load-perf, Geist fonts, platform inference routing; fixed link refs - Skill count unified to 26 (README/README_ZH/AGENTS.md/tools.ts) Verify/check cleanup: - Promoted 81 .check.ts to tracked .verify.ts and deleted the originals - Fixed 20+ stale assertions (PROJECT_VERSION 3->7, sourceRevision, caption-track structure, legacy index selectors, shader hash re-pins, abort wiring refactor, stock orientation enum) - 8 new verify groups (editor/captions/agent-tools/components/ media-persist/export-gl/server-extra/sqlite-migration) wired into pretest - Orphan verify count: 158 -> 0 Full npm test, tsc -b --force, and npm run lint all pass. | 2 个月前 | |
perf: bound editor runtime and storage costs Virtualize large timeline and resource surfaces, defer Agent and media work, and bound rebuildable caches without evicting source media. | 2 个月前 | |
fix(preview): stabilize shader loading status | 2 个月前 | |
feat(editor): add blurred background fill Persist the opt-in clip field through schema v5 migration while preserving older project documents. Keep preview and export compositing aligned, including effects, fades, and spatial GLSL transition alpha. FCPXML emits an explicit loss warning because the format cannot represent the companion layer. | 2 个月前 | |
feat: land professional timeline, durable jobs, and safe media flows Add slip/rate-stretch, nested sequences, multicam sync, durable generation/export recovery, media intelligence, and hardened MCP/media boundaries while keeping the implementation local-first and cross-platform. | 2 个月前 | |
feat(editor): add blurred background fill Persist the opt-in clip field through schema v5 migration while preserving older project documents. Keep preview and export compositing aligned, including effects, fades, and spatial GLSL transition alpha. FCPXML emits an explicit loss warning because the format cannot represent the companion layer. | 2 个月前 | |
perf: bound editor runtime and storage costs Virtualize large timeline and resource surfaces, defer Agent and media work, and bound rebuildable caches without evicting source media. | 2 个月前 | |
fix(preview): stabilize shader loading status | 2 个月前 | |
fix(gl): hash shader contents, not the checkout's line endings shader-contract.verify pins nine shader files by sha256 of their raw bytes. With git's core.autocrlf=true — the Windows default — they land as CRLF and every hash mismatches, failing as "fx/ascii-rain-blur.frag content changed": it reads as someone having edited the shaders rather than as a platform artifact. Normalizing CRLF before hashing reproduces the committed digests exactly and leaves the check just as strict about real content changes. | 1 个月前 | |
feat: land professional timeline, durable jobs, and safe media flows Add slip/rate-stretch, nested sequences, multicam sync, durable generation/export recovery, media intelligence, and hardened MCP/media boundaries while keeping the implementation local-first and cross-platform. | 2 个月前 | |
feat(editor): add blurred background fill Persist the opt-in clip field through schema v5 migration while preserving older project documents. Keep preview and export compositing aligned, including effects, fades, and spatial GLSL transition alpha. FCPXML emits an explicit loss warning because the format cannot represent the companion layer. | 2 个月前 | |
perf: bound editor runtime and storage costs Virtualize large timeline and resource surfaces, defer Agent and media work, and bound rebuildable caches without evicting source media. | 2 个月前 | |
feat(agent): run edit_item and manage_effects without the browser The offline MCP executor — and therefore the occ CLI — can now run the two tools whose validators consult the GL catalogs. Shader sources: GL catalogs no longer import ./x.frag?raw. That suffix only resolves inside Vite's own client build graph; Node, the desktop esbuild bundle and the rolldown step that bundles config/vite.config.ts all fail on it, which is how reaching these modules broke npm run build. Every .frag keeps a generated .frag.ts twin next to it (scripts/sync-shader-sources.mjs), enforced by scripts/shader-sources.verify.mjs in npm test and prebuild, so the shader text is still authored once and every host resolves it identically. Whitelist: edit_item and manage_effects join the server-direct set after review — both only touch the draft's EditorCore commands plus state/doc. edit_item's template-add path degrades with an explicit error because the offline context carries no template catalog; that is a capability gap, not a silent no-op. Executor: both schemas are exposed offline and dispatched through a lazy import, so a bare tsx host that never calls them never loads the GL modules. Shared paths touched: src/gl (import form only — shader text unchanged and the twins are verified byte-for-byte equal), the external-tool-policy whitelist, the offline tool catalog and executor, package.json (two scripts, one command in test:serial, one prebuild check). Preview, export and the Remotion render path are untouched. Verification: npm test 181/181 green (including the two new verifies); npm run build; npm run desktop:build:main (51 shaders inlined into app-main.mjs); npm run verify:mcp; cli/cli.verify.ts drives edit_item through an offline session and reads the written opacity back; offline-runtime, offline-mcp and offline-mcp-process-recovery verifies; chroma-key, clipFxPreview and clipFxExport GL verifies; tsc -b; lint 0 warnings; registration and gate coverage. | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 1 个月前 | ||
| 30 天前 | ||
| 28 天前 | ||
| 28 天前 | ||
| 3 个月前 | ||
| 28 天前 | ||
| 30 天前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 1 个月前 |