#Pricing

Transcodely uses a transparent, multiplier-based pricing model. The cost of a transcoding job is determined by the input duration, the codec, resolution, framerate, and quality tier of each output. Prices are locked at job creation time — if pricing changes after you submit a job, your cost does not change.

#Cost Formula

The cost per output is calculated as:

output_cost = (duration_minutes) x base_price x codec_mult x resolution_mult x framerate_mult x quality_mult x feature_mult

The total job cost is the sum of all output costs.

#Codec Multipliers

Different codecs have different computational costs:

Every codec’s multiplier is 1.0x — codecs differ only by base price. AV1 is billed at a €0.04/min base price versus the €0.01/min baseline for H.264 and H.265 (VP9 is €0.015/min).

See Encoding Options for codec details and container compatibility.

#Resolution Multipliers

Higher resolutions require more processing:

Custom dimensions are mapped to the nearest resolution tier based on pixel count. See Resolutions for the full list of presets and custom dimension constraints.

#Framerate Multiplier

The framerate multiplier scales linearly from a 30fps baseline:

framerate_mult = actual_framerate / 30

If the framerate is set to 0 (keep original), the actual framerate from the input probe is used.

#Quality Tier Multiplier

See Quality Tiers for default encoder settings per tier.

#Feature Multipliers

Add-on features apply additional cost multipliers. When multiple features are enabled on a single output, their multipliers are combined (multiplied together).

#Combined Features

When multiple compatible features are used together, the feature_multiplier is the product of all individual feature multipliers. Some features are mutually exclusive — Dolby Vision supersedes HDR tone mapping, and per-title encoding supersedes the auto ABR ladder — so only one of each pair contributes. Thumbnails add no multiplier at all. For example, an output with DRM and HDR tone mapping:

feature_mult = 1.25 (DRM) x 1.5 (HDR tone mapping) = 1.875x

The overlay multiplier behaves differently from the rest: it is a single class covering both the logo watermark and burned-in subtitles. An output that burns any pixel overlay into the frame carries exactly one 1.1x, whether that is a watermark, burned-in subtitles, or both — the two never compound to 1.21x. So an output stacking DRM, Dolby Vision, per-title encoding, and one or more overlays:

feature_mult = 1.25 (DRM) x 2.0 (Dolby Vision) x 1.5 (per-title) x 1.1 (overlay) = 4.125x

Adding a watermark to an output that already burns in subtitles (or vice versa) leaves the feature_multiplier unchanged — the single 1.1 overlay term already covers it, so the result is 4.125x, not 4.5375x.

#Example with Features

A 10-minute video encoded to H.265 4K at 30fps with premium quality, DRM, and HDR:

cost = 10 min x €0.01 x 1.0 (H.265) x 4.0 (4K) x 1.0 (30fps) x 2.0 (premium) x 1.875 (DRM + HDR tone mapping)
     = €1.50

#Price Locking

All pricing multipliers are captured in a pricing snapshot when a job is created. This snapshot is immutable — even if base prices or multipliers are updated later, your job’s cost is calculated using the original snapshot.

{
  "pricing": {
    "base_price": 0.01,
    "codec_multiplier": 1.0,
    "resolution_multiplier": 1.0,
    "framerate_multiplier": 1.0,
    "quality_multiplier": 1.0,
    "resolution_tier": "1080p",
    "actual_framerate": 30,
    "pixel_count": 2073600,
    "feature_multiplier": 1.0
  }
}

For the full pricing snapshot reference, see The Output Object — Pricing Snapshot.

#Estimated vs Actual Cost

Costs are calculated at two points in a job’s lifecycle:

The estimated cost is available in the awaiting_confirmation state for delayed-start jobs, allowing you to review costs before encoding begins.

#Example Calculation

A 10-minute video encoded to H.264 1080p at 30fps with standard quality:

cost = 10 min x €0.01 x 1.0 (H.264) x 1.0 (1080p) x 1.0 (30fps) x 1.0 (standard)
     = €0.10

The same video at 4K AV1 premium quality:

cost = 10 min x €0.04 (AV1 base price) x 1.0 (AV1) x 4.0 (4K) x 1.0 (30fps) x 2.0 (premium)
     = €3.20

#Multi-Output Pricing

Jobs with multiple outputs are priced per-output. Each output has its own pricing snapshot and cost calculation:

{
  "total_estimated_cost": 0.225,
  "outputs": [
    {
      "estimated_cost": 0.10,
      "pricing": { "codec_multiplier": 1.0, "resolution_multiplier": 1.0, "..." : "..." }
    },
    {
      "estimated_cost": 0.125,
      "pricing": { "codec_multiplier": 1.0, "resolution_multiplier": 1.5, "..." : "..." }
    }
  ]
}

#Per-Variant Pricing (ABR)

For adaptive streaming outputs (HLS/DASH) with multiple video variants, each variant has its own cost calculation in the variant_pricing array. The example below is a three-rung ABR ladder (1080p, 720p, 480p): each entry reports its own estimated_cost next to a live encoding status and progress, and the per-variant costs add up to the output’s estimated_cost (0.10 + 0.075 + 0.05 = 0.225).

{
  "outputs": [
    {
      "estimated_cost": 0.225,
      "variant_pricing": [
        {
          "index": 0,
          "codec": "h264",
          "resolution": "1080p",
          "quality": "standard",
          "estimated_cost": 0.10,
          "status": "completed",
          "progress": 100
        },
        {
          "index": 1,
          "codec": "h264",
          "resolution": "720p",
          "quality": "standard",
          "estimated_cost": 0.075,
          "status": "processing",
          "progress": 65
        },
        {
          "index": 2,
          "codec": "h264",
          "resolution": "480p",
          "quality": "standard",
          "estimated_cost": 0.05,
          "status": "pending",
          "progress": 0
        }
      ]
    }
  ]
}

The output’s estimated_cost is always the sum of all variant_pricing[].estimated_cost values. The same invariant applies to actual_cost.

#Processing Fee

Encoding capacity is dedicated per job. A job is scheduled onto a machine sized to the renditions it asked for, and that machine encodes that job and nothing else until it finishes. The processing fee is the price of starting that machine: one flat charge per job an encoder picks up, scaled to the size class the job was sized onto.

total = processing_fee_eur + sum of output costs + fees

Every term is additive. The processing fee does not clamp, replace, or absorb anything — it is one more line on the bill, and the per-output invariant is untouched: each output’s cost is still exactly the sum of its variant costs.

The fee is locked at job creation, like the pricing snapshot: the rate quoted when the job is created is the rate you are billed, even if the published rate moves afterward. It rides the wire as an entry in the job’s fees array with fee_type processing, unit job, and quantity 1, and appears on the job’s cost breakdown as its own Processing fee line.

Current rates by size class:

These are the current rates and are runtime-configurable; the pricing page is always authoritative for what is charged today.

#What the fee is billed on

Failed jobs bill €0 — outputs, processing fee and all.

Canceling a job that is still queued costs nothing. The fee applies once an encoder picks the job up, meaning the job has left pending. From that point a cancel bills the processing fee plus any outputs that completed before the cancel landed: the machine was already running. Declining a delayed-start job after its probe has run also bills the fee, because the probe ran on real hardware.

Additive fees — AI captions, for instance — are separate metered services billed on top of the processing fee, and only when the resulting file was actually delivered. Neither fee absorbs the other.

All processing-fee amounts are in EUR.

Historical: the per-job minimum charge. Jobs created before August 2026 were billed under a per-job minimum charge rather than a processing fee: the job total was max(sum of output costs, minimum_charge_eur), where the minimum was the sized machine’s hourly price × 1.25. Those jobs keep the terms they were created under, and their minimum_charge_eur and minimum_charge_applied fields still render on their cost breakdowns. Both fields are deprecated and are absent (or false) on every job created under the processing-fee model. No new job is subject to a minimum charge.

#Currency

All job costs are currently denominated in EUR. Every job carries a currency field indicating which currency its cost fields use; today this is always EUR, independent of the organization’s currency setting (which is not yet consulted for job pricing).

#Cost Estimation Before Submission

Use the estimated_cost_per_minute field on Presets to estimate costs before submitting a job. Multiply this value by your input duration to get an approximate cost.

For precise estimates, use delayed start — the job will probe the input and provide exact cost estimates before encoding begins.