v1.4.0

Added

• Energy in the ladder reports (qc ladder, qc run; terminal, HTML,
  JSON energy): what encoding each rung on the whole title costs, in CPU
  time measured on its verification encode and scaled to the title, plus
  the decode of the source, measured apart. Within 4% of the whole-title
  encodes of a 59 min 1080p title (1080p and 360p rungs). --core-watts
  turns it into Wh or kWh. --energy-tolerance X moves each rung, at the
  same bitrate, to the lowest resolution within X VMAF of the best, and
  reports the CPU saved — see energy. The
  wizard asks both when the ladder is customised.
  Library: ladder.Energy, Rung.Encode, ladder.WithDecoder
  (implemented by encode.FFmpeg.Decode).

Changed

• --cpus holds in the description of a ladder's digest (qc ladder,
  qc run, and a container's CPU quota, which Go follows): under 6 CPUs
  its frame analysis, its two fast encodes and their VMAF scores run one
  after the other, each on all of them, and the two encodes one after the
  other too. They ran side by side, each sized for every CPU: an instant
  ladder took 2.8 cores on average under --cpus 2, 6.5 at its peak, and
  its 8.8 s were 13 s on two real cores.
• VMAF measurements cost up to a third less CPU, scores unchanged to
  the bit: with a VMAF v1 model on the CPU, the warm-up frames of a clip
  are given to motion alone, the only temporal feature, instead of to the
  whole model (CAMBI and chroma are most of its cost). −29% of CPU on an
  exact measurement of a 32 s 1080p encode, libvmaf 11.1 → 4.7 s in an
  instant ladder, which on two cores now takes 10 s instead of 13 (qc vmaf, the probes and the verification of a ladder benefit as well).
  Library: vmaf.WarmScorer, implemented by libvmaf.Scorer.
• Clearer rate-quality chart in the terminal report of a ladder
  (qc ladder, qc run). It is framed on the rungs (their bitrates
  widened by 1.6 on each side, VMAF from under the lowest rung to 100)
  instead of every probe, which a model spreads from VMAF 0 to 100 and
  from 28 kb/s to 32 Mb/s. Each curve is one dot thick, drawn as the
  ladder reads it (VMAF linear in the logarithm of the bitrate), in the
  colour of its resolution where it is the upper envelope the rungs are
  placed on and faint under it; only measured probes are dotted. The
  rungs are numbered as in the ladder table. VMAF is labelled every 10
  with faint guides, and the bitrate axis has ticks at round values
  (200k, 500k, 1M…). The chart is 18 rows high instead of 14.
• With several codecs (-c h264,av1), the codec comparison draws the
  rungs of each codec on one chart, under its text.
• Charts drawn as pictures in terminals that show them (Kitty,
  Ghostty and Warp by the Kitty graphics protocol; iTerm2, WezTerm, VS
  Code by the iTerm2 one): the two charts above become smooth pictures
  (anti-aliased lines, the colours of the HTML report, dark or light to
  match the terminal), the envelope bold and the curves under it thin, the
  rungs numbered. Other terminals, tmux and redirected output keep the
  braille charts. QC_CHARTS=kitty|iterm|text|auto overrides the
  detection. Library: packages internal/chartimg and internal/termimg;
  tui.RenderLadder and tui.RenderCodecs take tui.ReportOptions.
• The ladder's live panel is a picture too in terminals of the Kitty
  protocol, redrawn in place as the probes land, then as each rung is
  verified (numbered, at its measured point). tui.RunDashboard takes the
  picture protocol; panels drawing themselves as pictures implement
  tui.Pictured.

Fixed

• golangci-lint 2.15 (wrapcheck): the libvmaf binding wraps the errno
  of a failed call.

Docker

docker run --rm -v "$PWD:/data" ghcr.io/eko/qc:1.4.0 version --check

Binaries

Self-contained (libvmaf and the VMAF models are built in); ffmpeg is still
needed. Linux binaries are static; the macOS one is not signed
(install).