#Content-Aware Encoding

per_title is available; auto_abr is not. Per-title encoding ships in API 5.21.0 on worker 1.28.1. An output carrying content_aware.mode = auto_abr is still rejected at job creation with error code parameter_unsupported — the message is “auto_abr is not available yet; per_title is”. The auto-ABR reference below is documented for forward compatibility so you can prepare your integration.

Per-title encoding tunes the encode to this particular source rather than to its quality tier. The worker measures short samples of your input at several CRFs, scores each against the untouched original with VMAF, and encodes your declared ladder at the cheapest setting that still reaches the target.

The ladder itself is untouched — same renditions, same resolutions, same count. That is why per-title can ship while auto-ABR cannot: pricing is per declared rendition and fixed at create, and changing the rendition count afterwards would invalidate the quote you already accepted.

Content-aware encoding is configured via the content_aware object on an Output Specification.

Content-aware encoding adds a per-mode feature multiplier to the output cost: per_title adds a 1.50x multiplier, and auto_abr adds a 1.75x multiplier. The per-title uplift is only charged when a search actually ran. See Pricing for details.

#The ContentAwareConfig object

{
  "content_aware": {
    "mode": "per_title",
    "vmaf_target": 95
  }
}

#Modes

#How the search works

One search per output, on its top rung. The worker picks the output’s highest-resolution quality-driven rendition, cuts a sample from the middle of the source — three short samples spread across it for long sources — and encodes that sample at a handful of CRFs, scoring each with libvmaf against the untouched original.

The search is bounded. At most four sample encodes of at most fifteen seconds each. It interpolates between the last two measurements rather than bisecting blindly, and it starts from the CRF the rung would have used anyway, which is usually already close.

The result is the highest CRF that still scored at or above the target, within a 0.5 tolerance. That is the cheapest setting that meets your quality bar, not the best quality achievable.

The lower rungs move with it, for free. They are not searched. Each takes the offset your ladder already declares relative to the top rung, so your own quality shape is preserved and only its absolute level moves. A ladder that declares no CRFs falls back to a shape by height.

It is deterministic. Sample positions are a pure function of the source’s duration and the candidate arithmetic is integer, so the same file searched twice gives the same CRF.

It fails open, and a fallback is not billed. A search that cannot run — an unknown duration, an encode error — falls back to the CRF the rung would have used, and the job proceeds. A correct file at the tier’s CRF is worth more than a failed job. That output is then billed at 1.0x, not 1.5x, and its own pricing snapshot states the corrected number.

#VMAF targeting

VMAF (Video Multimethod Assessment Fusion) is a perceptual quality metric developed by Netflix. A VMAF score of 93+ is generally considered “excellent” quality with artifacts imperceptible to most viewers.

vmaf_target accepts 80 to 97 and defaults to 93 — one number, not a table by quality tier. Below 80 the result is not a quality target anyone would ask for, and above 97 the search cannot tell the last point from the one below it.

Lower target, smaller files:

• Simple content (interview, slideshow, animation) → a higher CRF reaches the target, so a lower bitrate
• Complex content (action movie, sports, concert) → a lower CRF is needed, so a higher bitrate

There is no quality-tier restriction. economy, standard and premium all accept per-title encoding; the search seeds from whatever CRF the rung would have used anyway.

Override the default with vmaf_target:

{
  "content_aware": {
    "mode": "per_title",
    "vmaf_target": 95
  }
}

#Reading what the search decided

A per-title output reports its search back on report.content_aware. The block is present only on an output whose encode actually ran the analysis — absent on every ordinary output, and absent on a per-title output whose search fell back.

#Rules

A per-title request is refused in three cases. All three exist for one reason: you would pay the 1.5x multiplier for an analysis that could not do anything.

The source-length rule is decided at probe rather than at create because nothing has read your input at create, and guessing its duration would refuse correct requests. It measures what will be encoded, not how long the source is — a twenty-second clip of a ten-minute film is refused.

#Auto ABR

Not available. auto_abr is rejected at job creation with parameter_unsupported. The constraints below are validated for shape and then ignored, because a request in this mode is refused on its mode alone. This section documents the planned surface.

Auto ABR would analyse the source content and build the ABR ladder for you. Instead of specifying each variant, you would define constraints and let Transcodely determine the configuration.

#AutoABRConfig attributes

{
  "type": "hls",
  "video": [
    {"codec": "h264", "quality": "standard"}
  ],
  "content_aware": {
    "mode": "auto_abr",
    "vmaf_target": 93,
    "auto_abr": {
      "min_variants": 3,
      "max_variants": 6,
      "min_resolution": "480p",
      "max_resolution": "2160p"
    }
  }
}

#Content analysis

Separately from the CRF search, the worker measures the source’s complexity: an overall complexity_score, a motion_score, a texture_score (each 0.0—1.0) and a detected content_type of film, animation, sports, screen_share or mixed.

These are measured and then dropped. No API response carries them and no column stores them. Transcodely records the search result — see Reading what the search decided — not the source scores behind it, and nothing in the per-title decision reads them: the search measures your source directly. They are described here only to explain what the worker looks at.

#Examples

#Per-title encoding with the default VMAF target

Use per-title mode with your existing ABR ladder. Transcodely searches the top rung for the CRF that reaches VMAF 93 on this source, and the lower rungs move with it by the offsets your ladder declares.

{
  "type": "hls",
  "video": [
    {"codec": "h264", "resolution": "1080p", "quality": "standard"},
    {"codec": "h264", "resolution": "720p", "quality": "standard"},
    {"codec": "h264", "resolution": "480p", "quality": "standard"}
  ],
  "content_aware": {
    "mode": "per_title"
  }
}

#Per-title with a custom VMAF target

Override the default and target a specific VMAF score.

{
  "type": "dash",
  "video": [
    {"codec": "h265", "resolution": "2160p", "quality": "premium"},
    {"codec": "h265", "resolution": "1080p", "quality": "standard"},
    {"codec": "h265", "resolution": "720p", "quality": "standard"}
  ],
  "content_aware": {
    "mode": "per_title",
    "vmaf_target": 95
  }
}

#What it was measured doing

The numbers below are from the validation run against worker 1.28.1 on 2026-09-15 that qualified the feature for release. They describe those clips, not a corpus-wide savings figure.

• A single 1080p H.264 output at the default target of 93 landed a sample VMAF of 93.043 at CRF 27, and the searched file came out at 63.5% of the size of an identical untuned output encoded from the same source.
• A three-rung HLS ladder asking for a non-default target of 90 landed 90.426, with the 1.5x multiplier applied once at the output level rather than once per rung.

Both cases are in the public conformance catalog alongside the three negatives that cover the short-source refusal, the bitrate-pinned ladder, and auto_abr.