How to Build an AI-Video Scroll Animation Page

Scroll the box below.

Assembled. Start scrolling.

849 KB · 192 frames · generated for $0.64

Why the footage is the wall

The scroll part is old and well documented. You pin a tall section of the page, work out how far the reader has scrolled through it as a number between 0 and 1, and use that number to pick what to show. It is about fifteen lines of code and a dozen sites explain it well.

Every one of those explanations begins the same way: first, load your image sequence. Or: first, import your 3D model.

Both of those assume you already own something expensive. An image sequence is a folder of numbered still pictures, one per frame, and video runs at 24 frames a second, so eight seconds means 192 separate photographs of the same product, in the same light, from the same angle, each one slightly further through the motion. A 3D model, the .glb file those tutorials tell you to import, is a digital sculpture of the product that a 3D artist builds over days.

That is the wall. A solo builder has neither. Getting the asset was always the expensive part, and the code was never the problem.

That is what changed. You can now generate the footage, and it costs less than a coffee. What follows is the exact path, including the parts where I got it wrong, which turned out to be the useful parts. Working like this, where you test a thing and let the measurement decide, is the method I teach in Build With AI 1.0.

Step 1: make the product exist

Generate one still photograph first. Not a video. One image, and make it good, because everything after this inherits from it.

I call it a plate: one reference image that every later step is built from. The idea comes from my guide on keeping AI characters consistent across scenes, and the problem is identical. An image model has no memory of the last picture it made, so if you want the same product twice you have to give it a reference to work from.

The product is invented on purpose. It carries no logo and no brand marks, which keeps a published page out of trademark territory and costs nothing editorially.

Here is the whole thing. Everything that follows in this guide came out of these words:

Widescreen studio product photograph, tight hero framing. A pair of matte black over-ear headphones fills the frame, occupying roughly 80 percent of the frame height, centred, floating. Large deep circular ear cups with thick dark grey memory-foam ear pads, visible brushed aluminium yokes and hinge hardware, a slim padded headband, fine panel seams and small visible screws on the cup housings. Clean generic industrial design with no logos, no text and no brand marks anywhere. Seamless light grey studio background. Soft large softbox key light from the upper left, gentle fill from the right, soft contact shadow beneath. Razor sharp focus, high mechanical detail, neutral colour, three-quarter view, landscape orientation.

from google import genai
from google.genai import types

client = genai.Client(api_key="YOUR_KEY")

PROMPT = "...the plate prompt above..."

resp = client.models.generate_content(
    model="gemini-2.5-flash-image",
    contents=PROMPT,
    config=types.GenerateContentConfig(
        image_config=types.ImageConfig(aspect_ratio="16:9")
    ),
)

for part in resp.candidates[0].content.parts:
    if part.inline_data and part.inline_data.data:
        open("plate.png", "wb").write(part.inline_data.data)
        break

Either route costs $0.039 and returns a 1344x768 image. This is the one I kept, and every clip, frame and number in the rest of this guide comes from it:

Framing decides how much comes apart

This one surprised me, and it changes more than anything else in this guide.

My second plate was correct 16:9, but composed wide. The headphones occupy 53% of the frame height, with a lot of empty studio around them. My third plate is the same product, same lighting, same everything, framed so it fills 86%.

I sent both to Veo with an identical prompt. Press play and watch how differently they come apart:

Nothing changed but the framing. The model can only take apart what it can see, and a product sitting small in a wide frame simply has fewer legible parts to work with. If your clip comes back lazy, this is the first thing to fix. Fill the frame.

Step 2: make it come apart

Now hand the plate to Veo as the first frame. This is the whole trick, and the reason it works is worth a minute.

Most people's instinct is to describe the product to the video model and let it generate. That is called text-to-video. The alternative, image-to-video, hands the model a starting picture and asks it to animate that. It sounds like a small distinction. It is the difference between this technique working and not working.

I ran the same motion prompt twice. Once with no image, text only. Once with the plate as the first frame. Same words, same model, same settings.

Anchored against not anchored

Identical prompt and model. The only difference is whether the plate was passed as the first frame.

Text-to-video does not make a worse version of your product. It makes a different product. For a landscape that does not matter. For something a customer is supposed to recognise, it is the whole game.

Those are single frames. The clips make it plainer:

Here is the motion prompt. It is doing two jobs: naming every component that should separate, and saying when the motion starts and ends.

The disassembly begins immediately in the very first frame and continues without pause until the final frame. The headphones separate into a full exploded view: the ear pads lift away as rings, the ear cups split open and separate outward from the yokes, the internal driver units emerge and float free, the hinge hardware drifts apart, and the headband rises. Each component drifts apart along its own axis and hangs suspended in mid-air, and by the final frame all components are fully separated and widely spaced. The camera holds a slow steady orbit. Every component keeps its exact shape, colour and material as it separates. Clean seamless light grey studio background, soft studio lighting, precision product visualisation.

import time
from pathlib import Path
from google import genai
from google.genai import types

client = genai.Client(api_key="YOUR_KEY")

MOTION = "...the motion prompt above..."

op = client.models.generate_videos(
    model="veo-3.1-lite-generate-preview",
    prompt=MOTION,
    image=types.Image(
        image_bytes=Path("plate.png").read_bytes(),
        mime_type="image/png",
    ),
    config=types.GenerateVideosConfig(
        duration_seconds=8,
        resolution="1080p",
    ),
)

while not op.done:
    time.sleep(10)
    op = client.operations.get(op)

video = op.response.generated_videos[0]
client.files.download(file=video.video)
video.video.save("hero.mp4")

About 45 seconds of waiting for 8 seconds of video.

Four settings that look available and are not

The Python SDK exposes a rich config object. Most of it is rejected by the Gemini Developer API, and the errors only arrive when you call. Rejections are not billed, so mapping this cost me nothing, but it is worth knowing before you design around a field.

The seed line has a consequence that shapes the rest of this guide, so it is worth sitting with. When you get a roll you love, that file is the only copy that will ever exist. You cannot regenerate it at a higher resolution afterwards. Generate at the resolution you intend to ship.

Step 3: the cheap tier probably wins

Veo 3.1 comes in three tiers and the price gap is large: $0.05, $0.10 and $0.40 per second of output at 720p. The obvious assumption is that hero footage deserves the top one. So I ran the same plate and the same prompt through all three and looked at the same frame.

Standard looks the most coherent. Fast produced more parts but duplicated some of them. Lite is the sparsest. Read that quickly and you conclude the expensive tier is worth it.

Then I ran the control that actually mattered. Three runs of Lite. Same plate, same prompt, same settings, nothing changed between them.

Three runs of the same model, same everything

Veo 3.1 Lite, 8s, 1080p, identical plate and prompt. Frame 185 of 192 in each.

Run 3 came off the $0.05 tier and is better than the $3.20 Standard clip. Run 2 is a write-off. The spread between two runs of the same model is wider than the spread between models, which means the tier is not the variable that matters. The roll is.

Put that together with the missing seed and the strategy falls out on its own. You cannot re-roll a good result and you cannot avoid a bad one, so buy more rolls instead of more model. Three Lite rolls cost $1.20 and produced the asset on this page. One Standard roll costs $3.20 and is still one roll.

Step 4: the keyframe trap

You have a clip. Two things need fixing before it goes near a page.

Both are done with ffmpeg, a free command-line tool for video. If you have never used a terminal, this is the one place in this guide where you will need one. The commands are copy-paste, and if any of them puzzle you, paste it into an AI assistant and ask what each flag does. That is how I read unfamiliar ffmpeg lines too.

First, the audio. Veo hands you an AAC track whether you want one or not, and a scroll hero is silent by definition. This command copies the picture across untouched and drops the sound:

ffmpeg -i hero.mp4 -an -c:v copy hero-silent.mp4

That took my clip from 4,850 KB to 4,695 KB. A free 155 KB, and it costs nothing because the picture is copied across untouched rather than re-encoded.

Second, and this is the one that decides whether the whole approach feels good or terrible: count your keyframes.

ffprobe -v error -select_streams v -show_entries frame=key_frame -of csv=p=0 hero.mp4 | grep -c '^1'

That asks the file how many of its frames are keyframes, and counts them.

My eight second clip came back with one. One keyframe, 192 frames.

A keyframe is a frame stored in full. Every other frame only stores the difference from the one before it. So when you jump to frame 150 and there is no keyframe behind it, the decoder has to walk all the way from frame 0 to build the picture. Every scroll seek pays that.

That is the theory. I have not seen anyone put a number on it, so here is one. Both files fully downloaded first, so nothing but decoding is being timed, then 40 seek positions visited once each in random order on a CPU throttled to a quarter of its speed:

That is the whole argument for spending the bytes. The 379 KB you save by skipping this step buys you a scrub that cannot keep up with the display.

You fix it by forcing keyframes. It costs bytes, and not in a straight line:

This is the command that produced the file running at the top of this page. It scales the clip to 720p, compresses it, and forces a keyframe every eight frames:

ffmpeg -i hero-silent.mp4 -an -vf scale=1280:-2 -c:v libx264 -crf 28 -preset slow -g 8 -keyint_min 8 -sc_threshold 0 -movflags +faststart -pix_fmt yuv420p hero.mp4

-movflags +faststart matters more than it looks. It moves the index to the front of the file so the browser can start seeking before the whole thing has arrived.

Step 5: wire it to the scrollbar

Now the easy half. A tall track, a sticky stage inside it, and scroll position mapped onto currentTime. You do not have to write any of it by hand.

But you cannot just ask for it either, and this is the part worth slowing down for.

The obvious way to write this is one line: work out how far down the page you are, multiply by the video's duration, assign it to currentTime. Almost every tutorial does exactly that, so it is what an AI assistant will hand you by default. That version is broken. It looks fine while you test it slowly and falls apart the moment a real person scrolls at a real speed, for a reason I measured and put below.

So the useful thing here is not the code. It is knowing what to insist on. Give your assistant this:

Build me a scroll-scrubbed video hero as a single HTML file.

Structure: a tall section (400vh) containing a sticky stage that is 100vh tall and pins to the top of the viewport. Inside the stage, a video element holding my clip, scaled to fit without cropping.

Behaviour: as the reader scrolls through the tall section, map scroll progress to a number from 0 to 1 and set the video's currentTime to that fraction of its duration. The video must never play on its own. Scroll position drives it entirely.

These five requirements are not optional, and most examples online get the first one wrong:

1. Do NOT assign currentTime directly inside the scroll handler. A video element services one seek at a time and silently discards any currentTime you write while its `seeking` property is true. Instead, store the latest target position in a variable; if a seek is already in flight, do nothing, and re-apply the stored target from the video's `seeked` event.

2. Throttle the scroll handler with requestAnimationFrame behind a boolean gate, so you never queue more seeks than the screen can actually draw.

3. Register the scroll listener with { passive: true }.

4. The video element must carry the `muted` and `playsinline` attributes, or mobile browsers will refuse to decode it without a tap.

5. Give the video a `poster` image, so there is something on screen in the milliseconds before the clip is drawable.

Finally, respect prefers-reduced-motion: if the reader has it set, skip the scrubbing entirely and show a single static frame instead.

<section id="track" style="height: 400vh">
  <div id="stage" style="position: sticky; top: 0; height: 100vh;
                         display: grid; place-items: center; overflow: hidden">
    <video id="hero" src="hero.mp4" poster="poster.jpg"
           muted playsinline preload="auto"
           style="width: 100%; height: auto; max-height: 100vh"></video>
  </div>
</section>

<script>
  const v = document.getElementById('hero');
  const track = document.getElementById('track');
  let ticking = false;

  // A video services one seek at a time. Keep the latest target and re-apply it
  // when the current seek finishes, or fast scrolling throws most of them away.
  let target = 0, queued = false;

  function seek() {
    if (!v.duration) return;
    if (v.seeking) { queued = true; return; }
    queued = false;
    v.currentTime = target;
  }
  v.addEventListener('seeked', () => { if (queued) seek(); });

  addEventListener('scroll', () => {
    if (ticking) return;
    ticking = true;
    requestAnimationFrame(() => {
      const r = track.getBoundingClientRect();
      const p = Math.min(1, Math.max(0, -r.top / (r.height - innerHeight)));
      if (v.duration) { target = p * v.duration; seek(); }
      ticking = false;
    });
  }, { passive: true });
</script>

Checking what it gives you

Five things are doing real work in that file. Read whatever your assistant produces and confirm each one is present, because four of the five fail silently:

• The seek queue. Look for a stored target and a seeked listener. If currentTime is assigned straight from the scroll handler, you have the broken version. Symptom: the picture freezes while everything else on the page keeps moving.
• The requestAnimationFrame gate. Scroll events fire far more often than the screen redraws. Without the ticking flag you queue up seeks the browser will never show. Symptom: heat and battery drain, no visible fault.
• { passive: true }. Tells the browser this listener will never call preventDefault, so it can keep scrolling smoothly instead of waiting to find out. Symptom: scrolling feels slightly sticky.
• muted and playsinline. Without both, mobile browsers refuse to load or decode the video without a tap. Symptom: works on your laptop, blank on a phone.
• The poster. What people see in the milliseconds before the video is drawable. Use the assembled first frame, never an exploded one. Symptom: a black rectangle on first paint.

That list is the real deliverable of this step. The code is fifteen lines and any assistant can write it. Knowing which fifteen lines are wrong is the part that took me a day.

curl -s -D - -o /dev/null -r 1000-2000 http://localhost:8000/static/your-hero.mp4 | head -1

The frame budget nobody mentions

Your clip has a fixed number of frames. Veo returns 24 frames per second, so eight seconds is 192 frames. That is every distinct picture the reader can ever see, and it has to cover the whole scroll distance you gave the track.

At height: 400vh on a 900px viewport, that is roughly 2,700 pixels of scrolling spread across 192 frames: about 14 pixels of scroll per frame. Comfortable. Push the track to 1000vh and you get one new frame every 35 pixels, and the animation visibly steps. Track height and clip length are one decision, not two.

The measurement, on a throttled phone

The alternative approach is to export the clip as stills and draw them into a canvas. It is the technique most people reach for. I built both against the same clip and measured them with Playwright: desktop, then an emulated mid-range phone at 412x915 with a 4x CPU throttle, driving an identical 60 step scroll through the pinned track. Every timing below is the median of five runs, because a single run of this cannot tell a real difference from noise.

The weight and the time to first picture are the clear wins. The scroll time is the interesting one, and the median undersells it.

Across those five runs the video's scroll time stayed inside a 43 ms band, from 1,848 to 1,891. The canvas swung 626 ms, from 1,982 to 2,608. That spread is the number that matters, because nobody perceives an average. What a reader notices is the run where it stutters, and the sequence has one of those and the video does not.

Be straight about the other half of this: on desktop the two are a dead heat. Scroll times came out within 1% of each other, and there the canvas was marginally the steadier. This is a mobile advantage, not a universal one. It is also the half that matters, because the phone is where these pages fall over.

What the whole thing cost

Every generation, including the mistakes and the ones that failed:

If you already know what you are doing, which you now roughly do, the cost of one hero is the plate plus three rolls: $1.24 at 720p, or $1.96 at 1080p. The $11.74 is what it cost to find the path, and most of it went on the tier comparison that turned out not to matter.

Six of my findings cost nothing at all, because rejected and failed generations are not billed. Every unsupported setting in that table earlier was discovered for free.

Where this breaks

I would not use this technique for everything, and it is worth being straight about the edges I hit.

• Text on the product. Anything with a model number, a logo or a label will come apart into gibberish. Video models cannot hold small type. If your product has words on it, render those in HTML over the video instead, which is the generate it with code, not diffusion rule applied to a different surface.
• Engineering accuracy. This is a plausible teardown, not a true one. The driver units are convincing and they are invented. Do not use it for documentation, repair guides or anything a customer might take literally.
• An existing real product. If you need your product, you need your product in the plate, and a generated photo of a real item is a different problem with trademark attached. Photograph the real thing and use that as the plate.
• Long clips. Everything here is 8 seconds. Longer means more frames, more keyframes, more bytes, and the model back-loads the motion more the longer it runs.
• Reproducibility. Worth repeating because it is genuinely unusual. With no seed, your good clip cannot be regenerated. Back it up like a photograph you cannot retake.

Questions people actually ask

Can AI video really generate a product exploded view?

Yes, if you anchor it with a first frame. Text-to-video invented a different pair of headphones from the one I described. The same prompt with the plate attached kept the shape, the materials and the softbox reflection, and separated it into pads, drivers and hinge hardware.

Which Veo tier do I need?

Probably the cheapest. Three runs of Lite at $0.05 per second produced one unusable clip, one moderate one, and the best asset in the project, which beat a single Standard run at eight times the price. Buy more rolls, not more model. The real reason to pay for Fast or Standard is negative_prompt support, which Lite does not have.

Image sequence or video scrubbing?

Video, provided you re-encode with dense keyframes. On a CPU-throttled phone the sequence was 4,010 KB across 193 requests and took 585 ms to become drawable. The video was 849 KB across 2 requests and took 117 ms. Across five runs the video's scroll time stayed inside a 43 ms band while the sequence swung 626 ms.

Why does scrubbing a video feel janky?

Keyframe spacing, almost always. A default encode of an 8 second clip can contain a single keyframe, so every seek decodes from the start. On a throttled CPU that measured 57 ms per seek against 14 ms for the same clip at -g 8, and a display refreshes every 16.7 ms. Re-encode with -g 8.

Can I get the same clip twice?

No. The SDK has a seed field and the Gemini Developer API rejects it. Generate at the resolution you plan to ship, because you cannot go back for a bigger version.

Does this work on iPhone?

Unmeasured. I tested Chromium only. WebKit handles video seeking differently and I would test on a real device before shipping this to an audience that skews iOS.

Related

• Consistent AI characters where the reference-plate idea comes from, applied to people instead of products
• Generate real images with pure code the other half of the rule: anything with words in it should be code
• Free AI images with Cloudflare for the plate stage when you are experimenting and do not want a bill
• Solo Builder Hub every building guide on the site

Now go build something worth scrolling.

Hasan Aboul Hasan builds open-source tools and teaches solo developers how to build, host, and sell AI-powered products. Founder of LearnWithHasan.com, creator of SimplerLLM and PyRunner.