hdrprobe v1.0.1

New

• Builds from source now pull dolby_vision from crates.io. The 3.4.0 release is now published on the registry, so the temporary git pin from v1.0.0 is retired. The shipped binary is unchanged; this only affects source builds and dependency auditing.

Fixed

• Colored reports on Windows consoles no longer print raw escape codes. Windows consoles start with virtual-terminal processing disabled, so v1.0.0's default colored report could show literal ←[38;2;...m sequences and misaligned wrapping under conhost and the Explorer context-menu window (issue #12). hdrprobe now enables VT processing before emitting any ANSI, and falls back to plain output on consoles that cannot render it (legacy console mode). Piped, redirected, and --output runs were never affected.

Schema

• Unchanged at 3.0. No fields, labels, or presence conditions moved; 1.0.1 reports are byte-compatible with existing 3.0 consumers.

hdrprobe v1.0.0

New

• The legacy library, covered. hdrprobe now reads the formats a long-lived media collection actually accumulates: AVI (with exact bitrates from the file's own index), ASF/Windows Media (WMV and VC-1), Flash Video (legacy and Enhanced/E-RTMP alike, including HDR metadata carried in Enhanced tags), Ogg (Theora and VP8), MPEG program streams (.mpg/.vob, DVD rips included, plus HD DVD .evo), raw MPEG-1/2 video streams, MPEG-4 Part 2 (Xvid/DivX), Motion JPEG, raw DV tape streams (.dv), and RealMedia (.rm/.rmvb). Every format reports the general facts (codec, resolution, frame rate, duration, bitrate, and colour where the file signals it) with the same discipline as the HDR formats: signalled-only, nothing guessed. Directory scans and the Windows context menu pick the new extensions up automatically (re-run --install-shell to register them).
• DVD-Video ISOs. .iso probing now covers DVD-Video discs alongside Blu-ray: hdrprobe locates the main feature inside VIDEO_TS, probes it through the ordinary pipeline, and reports the runtime the disc itself declares. CSS-scrambled rips are detected and refused honestly rather than misread; decrypted backups probe normally.
• Aspect ratio and scan type. Every format now reports the signalled aspect ratio and scan type. The text report stays quiet unless it would otherwise mislead: DAR appears only for non-square pixels and an interlaced marker only when the stream declares it. JSON always carries both ratios when one was signalled.
• Machine-readable errors. A new --errors flag adds structured per-file error objects to JSON output, so scripted consumers can tell a refused file from a missing one without parsing stderr.
• Dolby Vision compatibility resolved from Dolby's own tables. Profile labels no longer carry the "(fallback)" suffix: the base-layer compatibility id now resolves through explicit rungs (declared by the container, fixed by the spec's profile table, inferred from the signalled colour, or assumed by ecosystem convention), and the JSON discloses which rung answered. A raw Profile 5 stream now reads 5.0 and a raw HDR10-base stream 10.1 in JSON as well as text, spec-defined base-layer colour fills absent fields with per-field provenance, and withdrawn profile/CCID pairings are flagged as deprecated.
• Encrypted and unusual Dolby Vision carriages. Common-encryption MP4 tracks (encv, CENC and CBCS) now report their real codec and full Dolby Vision metadata, since Dolby's streaming specs keep the RPU unencrypted. avc2/avc4 sample entries are recognized, an MP4 enhancement layer folds into its base track by the tref/vdep reference the spec requires, and a transport stream PID's DV descriptor is now authoritative about the base/enhancement shape.
• Every colour code named. The report names every CICP code point ITU-T H.273 defines, so a legal but uncommon colour signal renders as its name instead of being dropped.
• Updated Dolby Vision parser. The dolby_vision library moves to 3.4.0, which accepts L11 content-type metadata written by some devices that previously failed validation.

Fixed

• A misnamed MPEG file can no longer fabricate HEVC metadata. A DVD program stream renamed .hevc could previously print a fully populated (and entirely invented) profile, resolution, and colour description, because among tens of thousands of MPEG slice start codes some byte run eventually decodes as a plausible SPS. Start codes now route structurally, and the Annex-B backends refuse heads that classify as MPEG.
• Transport stream durations now come from the video's own timestamps. The PCR times byte arrival and real muxers flush the tail without one, so a stream could read short and its bitrate correspondingly high (a corpus stream read 1.92 s for a true 2.000, overstating bitrate 4.2%). The video PTS span now wins, with the PCR span as the fallback.
• Derived Dolby Vision levels no longer over-promote ultrawide streams. The level table's width limits now come from the spec's own maximum-width column rather than each level's anchor format, which previously pushed ultrawide-but-low-rate content up two levels.
• hdrprobe ... | head exits cleanly. A consumer closing the pipe early is a success signal; previously it produced a Rust panic backtrace and exit code 101.
• A malformed command line exits 1. The usage code the exit-code contract documents; previously it exited 2, which scripted callers read as "an input file was unreadable".
• Single-PID Profile 5 transport streams are read correctly beside a second video PID. A PID whose DV descriptor declares a present base layer was still being treated as an enhancement layer by its private stream type, merging two independent tracks into one; the descriptor now decides.
• Unrecognized codec labels are terminal-safe. A control character in a file's raw FourCC can no longer reach the terminal.

Schema

• 2.4 to 3.0 (breaking). Schema 3.0 aligns names and shapes across the report and discloses provenance throughout: bitrates carry their scope and source, stated rates also appear as exact ratios, tracks carry their own durations, the container's own codec identifier is reported, scan coverage is disclosed, hdr.base names the classified base signal, colour carries per-field provenance including spec-defined fills, the Dolby Vision compatibility rung lands in compat_source, quantized frame periods decode to their exact rates, FourCC padding is trimmed, and input_truncated extends to file probes. A step-by-step consumer migration guide, docs/MIGRATION-3.0.md, ships in every release archive; docs/SCHEMA.md documents the complete contract field by field.

hdrprobe v0.8.0

New

• SL-HDR detection. hdrprobe now recognizes SL-HDR dynamic metadata (ETSI TS 103 433), the format most common in European broadcast. The mode is named on the format line alongside the base signal it rides (for example SL-HDR2 / HDR10), and the report carries the specification version, payload mode, target-picture facts (primaries, max luminance), and the source mastering display when signalled. Detected from the per-frame information SEI in HEVC and AVC streams across every supported container.
• HDR Vivid detection. hdrprobe now recognizes HDR Vivid dynamic metadata (CUVA, T/UWA 005), the standard used in Chinese broadcast and streaming, named with its base signal (for example HDR Vivid / HLG). Detected from the per-frame metadata in HEVC/AVC and AV1 streams, and from the MP4 cuvv declaration box, which also lets --no-rpu report presence without reading any frame data. The report carries the metadata version and the sampled set of target display luminances.
• New --sections keywords. The new sections filter like the existing ones: --sections slhdr and --sections hdrvivid (hyphenated spellings also accepted). --sections hdr continues to select the static HDR section.
• Fully-static Linux x86_64 build. A new linux-x64-static archive carries a musl-linked binary with no libc or loader dependency, a drop-in for appliance NAS systems such as Unraid. It joins the existing static arm64 build for CoreELEC/LibreELEC boxes.
• FreeBSD x86_64 binaries. A new freebsd-x64 archive, built and tested on FreeBSD itself, covering TrueNAS CORE and other FreeBSD-based systems.
• Faster --full scans over network shares on macOS and FreeBSD. The linear read-ahead that keeps a full scan to one pass over the wire, previously Windows and Linux only, now also engages on macOS and FreeBSD network mounts.
• Release archives are named by platform. Downloads now read hdrprobe-0.8.0-linux-x64.tar.gz, hdrprobe-0.8.0-macos-arm64.tar.gz, and so on, instead of raw Rust target triples. If you script your downloads, update the filenames.

Fixed

• MP4/MOV constant-frame-rate tracks now report their exact frame rate. The rate was averaged over a media duration that real muxers pad slightly long, so a 60.000 fps file could read 59.983. Constant-rate tracks now report the rate the sample table declares, matching MediaInfo and ffprobe; variable-frame-rate reporting is unchanged.

Schema

• 2.3 to 2.4 (additive). New optional video_tracks[].sl_hdr object (mode, spec_version, payload_mode, target_primaries, target_max_luminance, source_mastering) and video_tracks[].hdr_vivid object (version, optional system_start_code, target_max_luminances with its sampled flag), each present only when the corresponding metadata was found. SL-HDR1/SL-HDR2/SL-HDR3 and HDR Vivid join the hdr.format component set. Streams without these signals are unchanged, so consumers following the docs/SCHEMA.md conventions are unaffected.

hdrprobe v0.7.0

New

• Stdin input. hdrprobe - probes a stream piped to stdin: the container is sniffed from the first bytes, a bounded format-aware head is read (currently 24 MiB for MPEG-TS/M2TS, whose metadata rides about one GOP in, and 16 MiB for everything else), and the ordinary probe pipeline runs over that buffer. This is built for callers whose media has no filesystem path an external process could open, such as Kodi addons, media-server plugins, and ranged HTTP fetches. A stream that ends within the budget reports identically to probing the same bytes as a file; a longer stream is flagged input_truncated in JSON, and the facts a prefix cannot support (a transport stream's duration, most bitrate figures) are withheld rather than reported wrong. hdrprobe stops consuming stdin once it has its budget, so the upstream writer seeing a broken pipe is the success signal and piping an entire remux costs only the head. - may appear at most once per invocation, --full is rejected on stdin (a pipe cannot be seeked or fully scanned), and metadata sidecars (raw RPU .bin, DV CM XML, HDR10+ JSON) are recognized by file extension so they still need paths. A consumer integration guide ships as docs/INTEGRATION-STDIN.md and is included in every release archive.

Schema

• 2.2 to 2.3 (additive). New top-level input_truncated boolean, serialized only when true; a complete stdin read and every file probe stay unflagged. "-" joins the file value space for stdin probes, and on a truncated probe size_bytes counts the bytes probed while the prefix-derived facts above are withheld. No existing field changed shape, type, unit, or presence, so consumers following the docs/SCHEMA.md conventions are unaffected.

hdrprobe v0.6.0

New

• Blu-ray ISO support. A decrypted Blu-ray disc image (.iso) is now probed directly: hdrprobe walks the UDF filesystem, parses every playlist under BDMV/PLAYLIST, selects the main feature automatically (duplicate and looped decoy segments are collapsed before durations are compared, so playlist obfuscation cannot outrank the feature), and runs the ordinary TS/M2TS pipeline over the selected playlist's largest clip. The report describes that clip exactly as if the mounted stream file had been probed, and a new Main feature line names the selected playlist and clip. AACS-encrypted images are detected and rejected with a clear error; hdrprobe never decrypts. Both plain UDF and UDF 2.50 Metadata Partition layouts are supported.
• Dolby Vision level for authentic disc content. Genuine BDMV clips carry no DV level declaration (UHD Blu-ray signals Dolby Vision via the playlist rather than the transport stream, and the RPU does not carry the level either), so they previously reported no level at all while remuxes of the same content did. When no container config declares one, the level is now derived from the coded stream's resolution and frame rate against the Dolby level table, and flagged in JSON via level_derived so consumers can distinguish declared from computed. A declared level always wins, and the derivation is a pixel-rate floor: the level's bitrate/tier axis is not probed. Applies uniformly to descriptor-less TS/M2TS, Blu-ray ISO clips, and raw HEVC/AV1 elementary streams with in-band timing.
• Shell integration confirmations match the report. --install-shell and --uninstall-shell now confirm in the report's own styling (masthead, section rule, themed aligned rows) on colored terminals, following the same --color policy and terminal-width probe as reports; piped output stays plain.

Fixed

• Merged dual-track groups now report their real layer presence. A dual-track Dolby Vision mux carries its configuration record on the enhancement-layer sub-stream, whose bl_present: 0 truthfully describes that stream's own carriage but not the merged BL+EL logical track, so the JSON report claimed the base layer was absent on content that plainly has one. Layer presence is now translated into logical-track facts at report assembly: a merged dual-track group reports both layers present, while a genuinely EL-only input keeps its declared absence. The unconverted-RPU verdict now gates on the derived enhancement-layer presence, so it can no longer misfire inside a dual-track group.

Schema

• 2.1 to 2.2 (additive). "Blu-ray ISO (BDMV)" joins the container set, and the new optional bd_iso object on the report records which BDMV playlist and clip were auto-selected as the main feature. dolby_vision.level may now be derived from stream properties when no container config declares one, flagged by the new level_derived boolean (serialized only when true; a declared level stays unflagged). The bl_present/el_present descriptions were clarified to logical-track semantics; no field changed shape, type, unit, or presence, so consumers following the docs/SCHEMA.md conventions are unaffected.

hdrprobe v0.5.0

New

• VP9 support. VP9 streams are now inspected across MKV/WebM, MP4 (vp09 sample entry plus the vpcC record), and IVF. Profile, bit depth, and chroma come from the WebM CodecPrivate feature list or the first keyframe's header, and container colour keeps authority since a bare VP9 stream names no transfer or primaries of its own. HDR10+ dynamic metadata carried in Matroska BlockAdditions (the registered ITU-T T.35 slot) is parsed and reported through the same gate as the AV1 T.35 route. IVF files are now routed by FourCC, so a VP9 IVF demuxes as VP9 (previously every IVF was read as AV1, reporting garbage for VP9 content) and VP8 gets an honest error instead.
• ProRes support. ProRes tracks in MKV and MP4/MOV are now inspected: the profile from the MOV/MP4 sample-entry FourCC (Matroska carries no profile signal, so an MKV mux reports none, matching MediaInfo and ffprobe), chroma and bit depth from the frame header and profile family, and static HDR from the container's signalling. When a MOV carries no colr box at all (the common ffmpeg-written case), the frame header's own CICP colour fills the gap, so a PQ master still classifies HDR.
• Unconverted RPU verdict. A new Unconverted RPU chip on the Dolby Vision Profile line (JSON: dolby_vision.unconverted_dual_layer_rpu) flags streams whose RPU still carries the dual-layer composer payload while the carriage has no enhancement layer: the signature of a transcode that injected a UHD Blu-ray Profile 7 RPU without converting it. The stray payload is inert for playback, but it misleads tools that guess a profile from the RPU, producing out-of-spec declarations like DV 10.6 on AV1. Reported as a provenance observation, not an error claim.

Fixed

• Mastering gamut labels now match regardless of primary slot order. Some real muxers (notably the writer behind YouTube-sourced WebM) store Display P3 mastering primaries rotated across the R/G/B slots. The primaries are now canonicalized by chromaticity role before matching, so such files get their correct gamut tag, matching MediaInfo.
• MKV mastering luminance renders in ST.2086 units. MKV MasteringMetadata luminance is usually stored as a 32-bit float, and the promotion to double rendered noise on the Mastering line (a stored 0.005 printed as 0.004999999888241291). Values are now rounded to the 0.0001 cd/m² unit ST.2086 defines, matching MediaInfo and the SEI path's output.
• Colour range is recovered from the stream when the container omits it. iPhone HLG/DV MOVs write the QuickTime nclc colr form, which carries no range field; the limited/full verdict lives only in the SPS. When container colour resolves but leaves the range unset, just the range is filled from the codec-config parameter set, for both MP4 and MKV remuxes of such files. Also fixes an out-of-bounds read of the nclx range byte on a box truncated at end of file.
• Dolby Vision compat 6 now counts as an HDR10 base in the format fallback. Compat id 6 is the UHD Blu-ray base signal, the same CTA-861.3 HDR10 base as compat 1; a compat-6 stream whose transfer could not be read previously reported no base tag.
• AV1 colour is recovered from the av1C sequence header. mkvmerge leaves AV1 colour in-stream, so an HDR AV1 remux commonly has no MKV Colour element or MP4 colr box; the CICP description then lives only in the sequence header embedded in the av1C record. Such files previously reported an empty colour section and misclassified the Dolby Vision base. The embedded sequence header's colour is adopted only when it carries an explicit colour description, so a CICP-unspecified stream never overwrites container colour with defaults.

Schema

• 2.0 to 2.1 (additive). New optional field video_tracks[].dolby_vision.unconverted_dual_layer_rpu, omitted when false. Value-set growth: "VP9" and "ProRes" join the codec set with their own codec_profile formats, and "raw VP9 (IVF)" joins the container set. No field changed type, unit, presence, or meaning, so consumers following the docs/SCHEMA.md conventions are unaffected.

hdrprobe v0.4.0

New

• Per-video-track reports. Files with more than one independent video track now get one report section per track: a multi-track MKV or MP4 reports each video track, and a multi-program TS capture reports one track per service with its program number. A Dolby Vision base layer + enhancement layer pair still reads as one logical track, classified by each stream's own DV signaling rather than by track count, so a P7 dual-track remux keeps its single Dual track, dual layer report. In the text report each track's sections are grouped under a full-width track rule with the body indented beneath it, so which sections belong to which track reads at a glance, and -q prints one line per track tagged [k/N]. Single-track files render byte-identical to before.
• Metadata cadence verdict. Dolby Vision reports gain a Metadata cadence line stating whether the title's dynamic metadata was authored shot-by-shot or frame-by-frame, decided by comparing consecutive frames' creative DM payloads. The verdict appears only when the evidence is complete: a --full video scan, a raw RPU sidecar, or a DV XML's own declared shot structure. The default sampled scan never guesses.
• Schema 2.0 migration guide. A step-by-step consumer migration guide for the new JSON shape ships as docs/MIGRATION-2.0.md and is included in the release archives.

Schema

• 1.2 to 2.0 (breaking). The JSON report is restructured for multi-video-track reporting: per-track fields moved from the old general, hdr, dolby_vision, and hdr10plus locations into the always-present video_tracks array (one entry per video track, including for sidecars, so consumers always iterate the array), each entry gaining track_number, program, and default. general.container, general.format_version, and general.duration_secs moved to the top level and general itself is gone. No field changed type, unit, or meaning. Also adds video_tracks[].dolby_vision.metadata_cadence. Documented in docs/SCHEMA.md, with the upgrade path in docs/MIGRATION-2.0.md.

hdrprobe v0.3.0

New

• Mastering primaries mismatch verdict. When a Dolby Vision grade's own L9 mastering gamut disagrees with the mastering display the base layer signals (MDCV box or ST.2086 SEI), the DV Mastering line now carries an MDP mismatch badge, the classic signature of re-encode drift such as a BT.2020-claiming MDCV over a P3-D65 grade. The verdict fires only when both sides are recognized gamuts from real signaling; it is never guessed.
• L10-defined custom trim targets. The trim-target set now includes custom target displays defined by the title's global L10 metadata even when no sampled trim referenced them, folded into the L8 set. This most often surfaces the authored target list of Profile 20 titles.
• Reports stream as files finish. In multi-file runs each report prints the moment its file completes instead of waiting for the whole run. On interactive terminals a finished file's progress display is erased in place, so the screen accumulates clean reports with the live scan bar always at the bottom. Piped, quiet, and JSON output is byte-identical to before; only the timing changes.
• Dividers and counts in multi-file runs. Consecutive reports are separated by a divider, and each report header carries a [k/N] counter.
• Terminal-width layout. Long value lines now reflow at natural separators to fit the terminal, and section rules and the between-reports divider stretch to the full terminal width. Piped and redirected output keeps its historical fixed-width formatting byte-for-byte.
• Folder context-menu scan (Windows). The explorer integration adds a folder verb that scans a directory recursively, alongside the existing per-file verb. Re-install using --install-shell to pickup the new capability.

Schema

• 1.1 to 1.2 (additive). The JSON report adds dolby_vision.mastering_primaries_mismatch, and trim_targets now also includes target displays defined by the title's global L10 metadata, folded into the L8 set (a semantic broadening of levels: [8], no new field or value). Documented in docs/SCHEMA.md.

hdrprobe v0.2.1

New

• Complete Dolby Vision profile labels for raw elementary streams. A raw stream has no container record (dvcC/dvvC) to declare the profile's compatibility minor, so the text report and -q line previously showed a bare 5 or 10. They now complete the digit when the deduction is certain: a bare Profile 5 renders as 5.0, the only compatibility id the Profiles & Levels spec admits, and a bare Profile 10 (raw AV1 IVF/OBU) is completed from the base layer's signalled CICP only when that signal is airtight. Anything less explicit keeps the bare number rather than guessing.

Fixed

• The right-click Full scan window now starts clean on Windows Terminal. Windows Terminal implements a screen clear by scrolling the old viewport into scrollback rather than erasing it, so the end-of-scan clear left the scan-time masthead and progress bar visible above the final report. The context-menu window now purges its own scrollback before the report renders. Shared interactive terminals are unaffected: their history and output bytes are unchanged.

Schema

• The JSON report is unchanged from 0.2.0. Both changes in this release affect only the rendered text output: no JSON fields were added, removed, or changed in meaning. In particular, the profile-label completion is display-only; dolby_vision.profile and dolby_vision.bl_compatibility_id still carry the mux's declaration verbatim, exactly as in 0.2.0. hdrprobe_schema_version stays at 1.1.

hdrprobe v0.2.0

New

• FEL reconstructed bit depth. Dual-layer Dolby Vision titles with a full enhancement layer (FEL) now show a Reconstruction line in the Dolby Vision section: the reconstructed signal bit depth read from the RPU itself, such as 12-bit (10-bit BL + FEL residual) on a Profile 7 title. It is shown only for FEL streams, where the enhancement layer carries real residual data that composes beyond the 10-bit base layer. The JSON output adds dolby_vision.reconstructed_bit_depth; schema version 1.0 to 1.1 (additive, documented in docs/SCHEMA.md).

Fixed

• H.264 in MKV is now fully classified. AVC tracks in Matroska previously reported the raw V_MPEG4/ISO/AVC codec ID with no codec profile, bit depth, or chroma subsampling. SDR AVC MKVs (8-bit, and 10-bit Hi10P) now report their bit depth, and Dolby Vision Profile 9 MKVs are now sampled for their RPU metadata, matching the MP4 and TS behavior.
• 10-bit HEVC no longer misreads as 8-bit under a sloppy mux. Some muxers zero the hvcC record's summary depth and chroma bytes even on a Main 10 stream. hdrprobe now prefers the SPS embedded in the same record, the bitstream's own word, and falls back to the summary bytes only when no SPS parses. Applies to MP4 and MKV, and matches what MediaInfo reports.