Thoughts

2 thoughts about "video rendering" in the last 90 days

ENN Pipeline Session 35: Completed Tasks 10.1, 10.2, and 10.2b. Task 10.1 added Flux asset library integration to generate-visuals-batch (reuse lookup, tag extraction, usage tracking). Task 10.2 baked thumbnail as 1s first frame hold in Remotion ShortComposition (replaces ffmpeg post-process). Also added news ticker component (NewsTicker.tsx) to Remotion: scrolling bar at bottom of video with ENN bug, previous short headlines, and website CTA. Ticker colors: golden yellow (#f5ce20) accent lines and bug, white headline text, turquoise (#79edf7) CTA text. Fallback headlines hardcoded for first 2 videos or DB failures. Ticker also reusable in Phase 11 LongFormComposition to cover NotebookLM watermark. Video structure is now [1s thumbnail] [voiceover + visuals + ticker + captions] [1s end hold]. Dave noted he added sample scripts from each Gem to Google Docs for testing. Next up: Task 10.3 (TikTok variant rendering).

People: Dave

UFO Pipeline Session 28 (2026-03-20): Fixed Railway OOM that was killing renders for "The Maid and the Beings of Light" (8f127e42). Root cause was three compounding memory issues in remotion/src/server.ts: (1) downloadFile() buffered entire assets in RAM via Buffer.from(await res.arrayBuffer()), and Promise.all() downloaded all 9+ assets simultaneously, creating 160-220MB peak RAM usage. (2) Upload read the entire rendered MP4 into RAM via fs.readFileSync() (40-100MB per video). (3) Remotion's OffthreadVideo decodes multiple Hedra video streams during avatar-led renders, adding to baseline memory pressure. Fixes applied: (1) Streaming downloads using ReadableStreamDefaultReader piped to fs.createWriteStream(), zero RAM buffering per asset. (2) Sequential downloads via for...of loop instead of Promise.all(), only one asset streams at a time, adds ~5-10s download time but saves 150+MB peak RAM. (3) Streaming upload using fs.createReadStream() with duplex: "half" fetch option instead of readFileSync. Total peak memory reduction estimated at 200-300MB. After deploying the fix, the previously 3x-OOM-failing short rendered successfully in 102 seconds (45.5MB output). All 43 YouTube Shorts are now complete in Cloudflare R2 with updated captions. Ready for Phase 7: YouTube publishing to Project Veilgate channel. Launch date April 1, 2026.