Feature Request: Data-Bound Video (Watch-Time Data Compositing)

[mattmadonna]

Problem

Feature Request: Data-Bound Video (Watch-Time Data Compositing)

Summary

Let a HyperFrames composition mark on-screen regions as data-bound and emit, alongside the baked render, a small manifest that maps each region to a live data source. A thin web player draws the baked footage every frame and composites current values into those regions on top, frame-synced to the render — so a promo never goes stale and never needs a re-export.

Problem

A product promo is out of date the moment it renders. The price is whatever it was on export day; stock counts, launch offers, and countdowns are all frozen into the file. Today the only fixes are to re-export for every change, or to carefully compose around ever showing a live number. Both are expensive, and neither scales past a handful of variants — one render is one snapshot in time.

Proposed solution

Proposed Behavior

• A composition can tag any region (text block, badge, lower-third) as data-bound instead of baking its value into the footage.
• One render job outputs the baked footage plus a manifest.json describing the bound regions — the footage layer carries everything expensive (motion, lighting, brand), the manifest carries only what changes.
• Regions are positioned in fractional coordinates (0–1 of the frame), so a binding survives any export size — 1080p, a 9:16 crop, a retina still — without per-size rework.
• Each region declares a bind path into a polled source, a format (usd / count / text / time), and a visual kind (headline / pill / badge / caption), so values render correctly with no per-video code.
• The baked render still stands alone: with no player, or in stale mode, it shows the values baked at export — a normal video. The player is purely additive.

Manifest shape

{
  "render": { "width": 1280, "height": 720, "fps": 30, "bakedAt": "2026-06-28T14:02:00Z" },
  "sources": [
    { "id": "inventory", "url": "https://api.example-store.com/v1/product/AC-118/inventory", "pollMs": 2000 }
  ],
  "regions": [
    { "id": "price",   "bind": "inventory.price",     "format": "usd",   "kind": "headline", "box": { "x": 0.06, "y": 0.63, "w": 0.34, "h": 0.18 } },
    { "id": "stock",   "bind": "inventory.stock",     "format": "count", "kind": "pill",     "box": { "x": 0.06, "y": 0.83, "w": 0.30, "h": 0.08 } },
    { "id": "offer",   "bind": "inventory.offer",     "format": "text",  "kind": "badge",    "box": { "x": 0.70, "y": 0.08, "w": 0.24, "h": 0.10 } },
    { "id": "updated", "bind": "inventory.updatedAt", "format": "time",  "kind": "caption",  "box": { "x": 0.62, "y": 0.90, "w": 0.32, "h": 0.06 } }
  ]
}

Requirements for the Output

1. Region metadata travels with the render. Export emits the baked footage plus a manifest listing each bound region's box, bind path, format, and kind.
2. Fractional coordinates. Region boxes are stored as 0–1 fractions of the frame so one manifest works across every export size and crop.
3. bakedAt timestamp. The manifest records when the footage was baked, so a player can flag stale when composited data diverges from the baked snapshot.
4. Baked fallback values. Each bound region's baked value is recorded, so the render is a valid standalone video when no live source is reachable.
5. Stable region IDs. IDs are consistent across re-renders of the same composition, so a player or config keyed to a region survives a re-export.

Player Side (out of scope, but for context)

A lightweight web player draws the baked footage each frame, resolves each region's bind path against its polled source, formats the value, and paints it into the region's box — frame-synced to the render. A live/stale toggle switches between polled data and the baked snapshot. HyperFrames owns the render + manifest contract; the player is a thin consumer of it. Working proof-of-concept: mattmadonna.com/the-bench/data-bound-video

Alternatives considered

• Re-export per data change — today's default. One render is one snapshot; it can't reflect anything that changes after export, and variant count explodes.
• Server-side render on request — generate a fresh video per view with current numbers. Heavy, slow, and expensive per impression; loses the "bake once" economics entirely.
• HTML overlay with no video-side contract — position live values over the video at the embed site. Works, but pushes all box/format/timing logic into every embedding page with nothing tying the overlay to the render's size or fps. The manifest is exactly what makes it portable.

Additional context

https://mattmadonna.com/the-bench/data-bound-video

[kishansinghifs1]

Hiii can I work on this ?