Research-backed calculator guide

Video Input Billing: Calculate Cost per Analyzed Minute from Frames, Duration and Resolution

Calculate video input cost per analyzed minute from duration, sampled frames, resolution, token rate, and provider price while keeping estimates separate from live usage.

The calculator inputs that matter

A useful video input token cost calculator needs more than a duration field. Record each input that can change the meter.

Duration is the source clip length in seconds. Use the duration actually sent for analysis, not the duration of a larger file if you trim it first. If the provider analyzes only selected segments, enter the sum of those segments or calculate each segment separately and add the costs.

Sampling FPS is the number of frames presented to the model per second. A 60-second clip at 1 FPS contributes about 60 sampled frames. The source video may contain 24, 30, or 60 original frames per second, but those original frames are not automatically the billed analysis count. For a provider that samples at 1 FPS, use 1. For a custom 2 FPS request, use 2 only when the provider says that the meter scales with the configured rate.

Token rate can be expressed as tokens per second, tokens per frame, or a more complex resolution formula. Keep the unit explicit. If the documentation gives 100 tokens per second at 1 FPS, then the equivalent estimate is about 100 tokens per sampled second. If it gives 263 tokens per second for a particular static video-tokenization surface, use 263 rather than silently substituting a different rate. ^[3]

Resolution or quality tier is a billing input when the provider documents separate low- and high-resolution behavior. In the simple model, define a resolution multiplier: 1.0 for the documented low tier and 3.0 when the documentation explicitly says high resolution uses 300 tokens per second versus 100. Do not invent a multiplier for a provider that publishes a tile or patch formula instead. Some systems resize or cap frames, so source pixels alone may not predict billed tokens.

Price is the provider’s input price in USD per million tokens for the exact model, tier, endpoint, and date. A price such as $0.15 / 1M tokens is a unit rate, not a per-minute quote. Google’s published tables show that rates vary by model and may differ for standard, batch, flex, priority, cached, long-context, or regional paths. ^{[1] [2]}

Processing mode must be recorded. Static processing is usually estimable from duration, FPS, and resolution. Agentic processing may load a transcript, frames, or audio on demand based on the prompt, so the estimate should be a planning range and the final bill should come from the usage fields returned by the request. ^[3]

Core formulas

Use these formulas when the provider exposes a predictable sampled-frame meter:

1. sampled frames = duration seconds × sampling FPS
2. tokens = sampled frames × tokens per sampled frame
3. input cost = tokens ÷ 1,000,000 × price per 1M input tokens
4. cost per analyzed minute = input cost ÷ (duration seconds ÷ 60)

If the provider gives a token rate per second instead, use the equivalent shortcut:

tokens = duration seconds × tokens per second × resolution multiplier

At 1 FPS, a rate of 100 tokens per second also means approximately 100 tokens per sampled frame. At 2 FPS, do not multiply again unless the provider’s rate is defined per frame rather than per second. The safest approach is to name the unit in the input field and use one formula only.

The term “per analyzed minute” can describe two different denominators. Wall-clock minute divides by the source duration, such as 10 minutes. Sampled-analysis minute can be used when you are comparing workloads with different sampling schedules, but then state the frame budget too. A 10-minute clip sampled at 0.5 FPS and a 10-minute clip sampled at 2 FPS are both 10 wall-clock minutes, but the latter presents four times as many sampled frames under a linear meter.

For a frame-based provider, resolution may enter through a documented formula such as a patch grid, tile count, or frame cap. Use the provider’s formula before applying a price. Do not use file size, bitrate, or original FPS as a proxy for tokens unless the provider explicitly defines billing that way.

Worked cost example

Assume a 10-minute video is sent once for static analysis. The planning assumptions are:

• Duration: 600 seconds
• Sampling: 1 FPS, so 600 sampled frames
• Resolution tier: low-resolution static estimate
• Token rate: 100 input tokens per second, equivalent to 100 tokens per sampled second at 1 FPS
• Input price: $0.15 per 1,000,000 tokens
• Scope: input video only; output text and other request charges excluded

The calculation is 600 seconds × 100 tokens/second = 60,000 input tokens. The cost is 60,000 ÷ 1,000,000 × $0.15 = $0.009. Dividing by 10 wall-clock minutes gives $0.0009 per analyzed minute, or 0.09 cents per minute.

The table makes the unit changes inspectable rather than hiding them in a single result.

Now change only the documented resolution tier. If high-resolution static processing uses approximately 300 tokens per second, the same 600-second clip produces 180,000 tokens. At the same illustrative price, cost is $0.027 total, or $0.0027 per minute. The resolution change triples the estimate because the stated token rate triples; it is not because the video file became three times larger.

As a separate sensitivity check, if a provider documents 263 tokens per second for its static video surface, 600 seconds produces 157,800 tokens. At $0.15 / 1M, the estimate is $0.02367, or about $0.002367 per minute. That row should be labeled with the provider and model surface. It must not be blended with the 100- and 300-token rows into a generic industry average. Google’s token page itself presents different processing descriptions, including a 263-token-per-second statement and a static low/high-resolution table, so the exact API surface and request mode need verification before a budget is approved. ^[3]

For a monthly workload, multiply the request estimate by the number of analyzed clips, then add separately measured output and operational costs. If 2,000 ten-minute clips use the low-resolution assumption, the video-input estimate is 2,000 × $0.009 = $18. That is a planning subtotal, not an invoice prediction. Retries, duplicated submissions, cache behavior, request minimums, and other billed features can move the actual total.

How to reconcile an estimate with actual usage

Start with the provider’s usage response for a small test batch. For Gemini agentic interactions, the token guide identifies separate usage fields for the initial prompt, navigation thinking, tool-use content such as transcript and frames, and the final answer. ^[3] For an input-only calculator, record only the input fields that correspond to video and clearly exclude thought, output, tool, grounding, or audio quantities unless your bill includes them in the same meter.

Next, compare the observed video tokens with the model’s documented assumptions. A mismatch can result from custom FPS, a provider-side frame cap, dynamic resizing, an audio track, transcript extraction, a different endpoint, or a request that was not actually static. Keep a variance column in your ledger: actual input tokens − estimated input tokens. A percentage variance is useful for planning, but it does not prove the cause.

Finally, preserve the pricing snapshot. Record the checked date, model ID, region or endpoint, service tier, input unit, and whether the rate is a vendor quote or a working estimate. Google Cloud’s pricing page, for example, distinguishes global and non-global prices and includes context-size thresholds on some model tables. ^[2] A calculator result without those labels is difficult to reconcile later.

What this estimate excludes

This method estimates input video token cost. It does not automatically include output text tokens, reasoning or thought tokens, audio tokens, transcription, grounding requests, tool calls, context-cache storage, file storage, upload or egress charges, taxes, minimum charges, provider credits, or application infrastructure. Google’s pricing tables show separate input, output, and caching rows, and some model surfaces price audio differently from video. ^{[1] [2]}

It also excludes quality and business costs. Lowering FPS may reduce input tokens but miss scene changes. Lowering resolution may reduce tokens but weaken OCR or small-object recognition. A cheap analyzed minute is not necessarily a cheap successful answer. Track a quality acceptance rate beside cost if the video is used for moderation, compliance, search, or customer-facing automation.

For provider comparison, keep a common test clip, prompt, duration, sampled FPS, resolution policy, and output requirement. Compare both cost per wall-clock minute and cost per accepted result. The first is a meter normalization; the second includes the operational outcome and should use measured data.

Related calculators and planning guides

Use the AI token cost calculator when the video request also contains a large text prompt, system instruction, or cached context. The LLM cost calculator is better for combining input and output tokens across a workflow rather than isolating video input. If you are comparing provider-specific units, open the Mistral and Groq API cost calculator and confirm whether its meter is token-, request-, or media-based before comparing it with a video-token estimate.

FAQ

Is video input billed by minutes or by frames?

It depends on the provider and endpoint. A provider may publish a per-second token approximation, which is effectively a duration meter under a specified sampling policy. Another may publish a frame, tile, patch, or dynamic-resolution formula. Convert the documented meter into a common cost-per-minute view only after recording the sampling and resolution assumptions. “Per minute” is a normalization for comparison, not proof that the vendor invoices by the minute.

How do I calculate tokens from FPS and duration?

Multiply duration in seconds by sampled FPS to get sampled frames. Then multiply by tokens per frame, if that unit is documented. If the documentation gives tokens per second, multiply duration by that rate instead. For example, 90 seconds at 2 FPS is 180 sampled frames. If each sampled frame is estimated at 120 tokens, the total is 21,600 tokens. Do not multiply by FPS a second time when 120 is already a per-second rate.

Does higher resolution always cost more?

No universal rule applies, but it can. Some providers publish separate low- and high-resolution video rates; Google’s static description gives approximately 100 versus 300 tokens per second for those tiers. ^[3] Other systems resize frames to a patch budget or cap total video tokens, so a 4K source may not be billed as four times a 1080p source. Use the provider’s documented resolution rule and record any cap or resize behavior.

Should I use a token calculator or the provider’s count endpoint?

Use a calculator for scenario planning and a provider count or usage endpoint for final reconciliation. A calculator is useful for testing duration, FPS, resolution, and price sensitivity before sending traffic. The count or usage response captures provider-side sampling, caps, dynamic processing, and request-specific behavior. For agentic processing, the documented usage fields are particularly important because the model may load only selected frames, transcript, or audio. ^[3]

What is the difference between static and agentic video processing?

Static processing applies a predictable sampling policy, making duration and FPS useful planning inputs. Agentic processing selects media needed for the prompt and can vary with content and question complexity. A static estimate can be a baseline, but it should not be used as an agentic invoice forecast. Run representative clips, capture actual usage, and report a range until the workload is stable.

Can I compare two providers using only cost per analyzed minute?

Use it as a first normalization, not as the final decision metric. Keep the clip duration, FPS, resolution, prompt, model, endpoint, and output scope identical. Then add accepted-answer rate, latency, retries, and any non-token media charges. A provider with a lower input subtotal may require more sampling or retries to meet the same quality target.