EmbeddingGemma 2 takes 58 video frames: sample them with Sume

EmbeddingGemma 2 fits 58 video frames in its 8K window. Sume's video inspect returns 24 stills per call, so three calls with explicit times cover it.

4 min readSume
All posts

Google says EmbeddingGemma 2's 8,000-token window holds up to 58 video frames, 29 images, or 5.5 minutes of audio, or a mix. Sume's video inspect returns at most 24 stills per call, so to feed an external embedder 58 frames from one clip you send three calls with explicit timestamps (24, 24 and 10) and merge the results.

Sume does not sell an embeddings endpoint. What it does give you is durable frame images from a clip your workspace already owns, which you then pass to the embedder you run yourself.

What does EmbeddingGemma 2 accept per video?

Google's post (release date 2026-10-06) describes one model that puts text, code, images, audio and video into a shared 768-dimension space, truncatable to 512, 256 or 128 dimensions. The 8,000-token context is the budget you split between frames, images and audio.

That makes the frame count a design choice, not a fixed input. Fewer frames leave room for an audio clip or a caption in the same embedding call.

Limits from Google's EmbeddingGemma 2 post and the Sume docs pages linked in Sources, read 2026-10-11.
LimitValueSource
Context window, all modalities8,000 tokensGoogle
Video frames that fitup to 58Google
Audio that fitsup to 5.5 minutesGoogle
Stills per Sume video inspect call24Sume video inspect
Source clip length on video inspect1,800 secondsSume video inspect
Default still size on video inspect768 px long edgeSume video inspect

How do I get more than 24 frames out of Sume?

Video inspect takes a frames program: either at (1 to 24 explicit timestamps) or fps (above 0, up to 2), never both. Explicit times are the safer choice for a fixed budget because you decide exactly which instants are embedded. Import the clip first with POST /v1/media-imports, since the API does not fetch from the open internet, and send an Idempotency-Key on each call.

For 58 frames, split the timestamp list into chunks of at most 24. The helper below prints the three request bodies for a 58-second clip at one frame per second.

import json

def frame_chunks(duration_s, frames=58, per_call=24):
    step = duration_s / frames
    times = [round(step * (i + 0.5), 2) for i in range(frames)]
    return [times[i:i + per_call] for i in range(0, len(times), per_call)]

clip = "https://media.sume.com/artifacts/artf_demo/talk.mp4"
for n, at in enumerate(frame_chunks(58), start=1):
    body = {"video_url": clip, "frames": {"at": at, "max_edge": 512}}
    print(n, len(at), json.dumps(body)[:80])

What does the sampling cost and return?

Each call returns frames[{t,url,width,height}] as durable media.sume.com image artifacts. Sume bills probe and stills by their Modal compute and does not publish a flat per-frame price, so read the amount from the response or GET /v1/catalog rather than assuming one. Any at value outside [0, duration) is refused with frame_time_out_of_range, which also tells you the duration.

If you need frames at the source resolution rather than a downscaled long edge, use video frames instead; it extracts stills at times you name and keeps the source frame size unless you set a clamp.

When should I use fewer frames?

Spend the 8,000 tokens where your search needs them. A talking-head clip rarely needs 58 near-identical frames; 8 to 12 spread evenly plus the transcript is usually enough to tell clips apart, and it leaves room for an audio segment. Check your own retrieval quality before settling, because no vendor page I read fixes the right count.

Keep the original timestamps with each embedding so a hit can link back to the second it came from. The t value on every returned still is the number to store next to the vector, and the artifact URL lets a reviewer open the exact frame behind a match without decoding the video again. Retried calls with the same Idempotency-Key do not queue a second extraction, so a crashed indexing job can resume safely.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume