compress.target hits byte budgets in one encode

Give compress.target a maxBytes or maxSize target for an H.264 video and it now works out the bitrate the budget allows, picks a resolution that bitrate can carry, and runs a single two-pass encode. It used to search for a quality level that happened to fit, with a full encode at every step. On a 10 second 1080p clip with a 5 MB limit, the encode step went from 51.5 to 7.4 seconds in our tests, landing at 95% of the budget with VMAF within 0.1 of the old result. Billing is per compute second, so the price follows.

Tight budgets step down in resolution#

When a budget is too small for the source resolution, the job now steps down a standard ladder (1080, 720, 540, 480, 360, 240 on the short edge) until the picture gets at least 0.045 bits per pixel. A smaller frame that the player scales up looks better than a full size one starved of bits. A 40 second 1080p clip asked to fit 3 MB used to come back at 1080p with a VMAF of 31. It now comes back at 360p with a VMAF of 49, in a seventh of the time. That is still a low score, and the report says so. The budget is what limits it.

Quality targets: fewer encodes, recalibrated tiers#

The quality search now starts from a measured guess instead of the middle of the range, accepts a result within one point of the target, and stops refining after four encodes for video or five for images once it has a passing result. Across our eight test clips it ran 27 encodes where it used to run 37. Accepting a near pass can leave a file slightly larger than the exact answer would be, for images as well as video, which is the trade for the encode it saves.

The video tiers moved from VMAF 96, 93 and 88 to 94, 91 and 86. Rendobar scores with the NEG VMAF model, which reads about two points under the standard model those numbers were quoted on, so the old tiers asked for more than their names promised. visually-lossless used to hand back the original file almost every time. balanced now produces files 8 to 39% smaller in our tests, at a score viewers cannot tell apart. The verdict label follows, so visually_lossless now starts at 94 instead of 95. If you want the old behaviour, pass the number: target: 93.

JPEG to JPEG XL without touching a pixel#

With compatibility: "modern", a JPEG source is now also repacked into JPEG XL with its pixels untouched, and the smaller of the repack and the lossy search ships. Across eight 1080p web photos the repack came out at a median 86% of the source, level with a lossy search at balanced and with no quality loss. On a high-quality camera JPEG the lossy search still wins by a wide margin, which is why both run. A repacked result reports mode: "lossless" with no score, and it also ships when the lossy search could not reach your target at all. EXIF and XMP are stripped unless you ask for metadata: "all".

Also in this release#

• Long videos are sampled in proportion to their length, and the report’s new scoredOn field says whether the score was measured on samples or on the delivered file.
• A byte-budget result reports qualityLevel: null and probes: 1, because there is no quality level to search for. Its audio is re-encoded to AAC at a planned rate, up to 128 kbps and about a fifth of the budget, where it used to be copied.
• H.264 outputs are always 8-bit 4:2:0. A 10-bit or 4:2:2 source, such as ProRes or iPhone HDR footage, used to keep its pixel format, and browsers cannot play H.264 in that form.
• MP4 outputs are written with the index at the front, so playback can start before the download finishes. HEVC outputs carry the hvc1 tag that Apple players need.
• A video that already fits the budget is returned as it is, with no encode.
• A video job that resizes with maxResolution or drops audio with audioTracks: "none" always returns the re-encoded file, even in the rare case where it is larger than the source. Returning the untouched source would have ignored what you asked for.
• A quality search stops as soon as one attempt misses the target while already as large as the source, because no setting can then win.
• dryRun now predicts skipped_no_improvement when the real run would return your original file. It used to report ok with a ratio below 1. A dry run also returns no file in every mode, lossless included.
• Portrait phone clips that carry a rotation flag no longer fail when the job resizes them.
• A skipped_no_improvement result reports achievedScore and qualityLevel as null. The numbers it showed before belonged to an encode that was thrown away, not to the file you received.

The two-pass route covers H.264, which is what compatibility: "broad" selects. HEVC, AV1 and VP9 budgets keep the search for now.