Video formats

Per-title optimization

Automatically select video quality and bitrate settings for each source instead of using one fixed setting for every video.

Two videos with the same resolution and duration can require very different bitrates. A talking-head interview is usually easier to compress than a fast-moving game or sports broadcast.

Applying the same settings to both can waste bandwidth on the simpler video or reduce quality on the more complex one.

Per-title encoding adapts encoding settings to the content. Chunkify analyzes the source and requested output, then selects rate-control settings for that combination of video, codec, and resolution.

Per-title optimization is opt-in for API requests. Set per_title: true to enable it. The Chunkify app enables its per-title switch by default for supported video formats.

How per-title optimization works

How the models were developed

Chunkify trained its machine-learning models on more than 100,000 videos, covering varied content types, resolutions, motion patterns, textures, and levels of visual complexity.

During training, the models learned how these visual characteristics affect the encoding settings required to achieve consistent quality while controlling bitrate.

At processing time, Chunkify analyzes decoded visual content rather than signals tied to the source codec. It combines those characteristics with the requested output codec and resolution to predict suitable encoding settings.

How optimization is applied

flowchart TD
    job(Create job with per-title enabled)-->ingest(Ingest and split into chunks)
    subgraph perChunk[For each chunk]
        direction LR
        analyze(Extract visual features)-->predict(Predict settings for the codec and resolution)-->transcode(Transcode)
    end
    ingest-->analyze

For each chunk, the prediction model combines the extracted features with the requested codec and resolution to select suitable encoding settings.

Because every chunk is analyzed independently, the encoding settings can adapt to changes in visual complexity throughout the video instead of applying one decision to the entire source.

Processing time and billing

Per-title analysis typically adds approximately 30 seconds of processing time per chunk.

This additional processing is included in billable compute time. Actual overhead can vary with the source and output configuration.

What per-title encoding optimizes

Chunkify uses a content sample to estimate how difficult the video is to compress. The analysis considers motion, texture, spatial detail, and the target resolution.

The resulting settings depend on the output format:

  • MP4 and WebM: Chunkify selects a quality-based CRF and bitrate bounds. This lets the encoder spend more bits on complex content while avoiding unnecessary bitrate on simpler content.
  • HLS: For each HLS job, Chunkify uses average bitrate (ABR) rate control and selects a content-aware video bitrate based on the source, codec, and requested output resolution.

For MP4 and WebM, you choose the output format, codec, and resolution. For HLS, you also choose the resolution of each rendition.

To create a multivariant HLS ladder with the current API, create one job per resolution and group them with the same hls_manifest_id. Per-title selects an average bitrate independently for each rendition.

In this page, average-bitrate encoding means targeting the bitrate of one rendition. HLS adaptive bitrate streaming is the player behavior that switches between multiple renditions as network conditions change.

Benefits

  • More consistent visual quality: easy and difficult videos do not have to share one compromise setting.
  • Lower storage and delivery volume: simpler content can use fewer bits without allocating a worst-case bitrate to every video.
  • Less encoding guesswork: you do not need to select and maintain CRF, bitrate, and buffer settings for every codec and resolution.
  • Content-aware HLS renditions: the bitrate assigned to each requested rendition reflects the source and output resolution rather than a universal setting.

Actual savings vary with the source, codec, resolution, quality requirements, and the fixed settings used for comparison.

Measured examples: why content-aware settings matter

These internal comparisons used 30-second samples excluded from model training. Each pair was encoded at 1920 × 1080 and targeted a VMAF score of 95.

CRF controls the encoder's quality target. A lower value generally preserves more detail and uses more bits. VMAF estimates visual quality by comparing the encoded output with the source.

H.264 comparison

With H.264, per-title selected CRF 23 for the music video and CRF 21 for the game. Both reached comparable visual quality, while the game required approximately 2.9× the bitrate.

Content Selected CRF Measured bitrate Mean VMAF
Music video 23 2.02 Mbps 96.20
Video game 21 5.93 Mbps 96.41

AV1 comparison

With AV1, per-title selected CRF 27 for the music video and CRF 43 for the game. Both reached comparable visual quality, while the game required approximately 4.3× the bitrate.

Content Selected CRF Measured bitrate Mean VMAF
Music video 27 0.61 Mbps 96.07
Video game 43 2.60 Mbps 96.21

Across both codecs, the samples required different CRF values to reach similar VMAF scores. A CRF suited to one type of content cannot be assumed to suit another.

Choosing one generic CRF for every video creates a tradeoff. Simple content may use more bits than necessary, while complex content may miss the desired quality or produce a much larger output.

Per-title removes that guesswork. It analyzes each chunk and selects a CRF suited to its content, codec, and resolution. This helps varied content reach comparable quality without one compromise configuration.

These figures are results from specific test clips, not guaranteed savings. VMAF is an objective quality metric; it does not replace visual review or playback testing for your own content.

Enable per-title optimization

Set per_title: true inside the job's format object. If you omit per_title, optimization remains disabled and existing manual rate-control settings continue to work.

Per-title optimization is available for:

  • MP4 with H.264, H.265, or AV1
  • WebM with VP9
  • HLS with H.264, H.265, or AV1
import Chunkify from '@chunkify/chunkify';

const client = new Chunkify({
    projectAccessToken: 'My Project Access Token',
});

const job = await client.jobs.create({
    source_id: source.id,
    format: {
        id: 'mp4_h264',
        height: 1080,
        per_title: true,
    },
});

Use per-title for an HLS rendition

Choose the HLS codec and resolution you want to encode. Chunkify analyzes the source at that resolution, then uses ABR rate control with an automatically selected average video bitrate.

The requested height is the output resolution for this job; it is not a ladder ceiling.

Do not provide video_bitrate, crf, minrate, maxrate, or bufsize when per-title optimization is enabled. You can still set audio_bitrate because per-title optimization controls the video rate.

import Chunkify from '@chunkify/chunkify';

const client = new Chunkify({
    projectAccessToken: 'My Project Access Token',
});

const job = await client.jobs.create({
    source_id: source.id,
    format: {
        id: 'hls_h264',
        height: 1080,
        gop: 60,
        x264_keyint: 60,
        audio_bitrate: 128000,
        per_title: true,
    },
});

This job creates one 1080p HLS rendition and returns an hls_manifest_id.

To build a multivariant ladder, create another HLS job for each additional resolution. Pass the manifest ID to group the renditions. Per-title selects the video bitrate independently for every job.

See the HLS guide for manifest and keyframe configuration.

Use per-title optimization for most video-on-demand workflows. Use manual settings when a fixed rate-control configuration is itself a requirement, and validate HLS ladders on your device and network matrix before a broad rollout.