Skip to content

macOS Plex Original: retained Dolby Vision P7 configuration fails decoder initialization #316

Closed

Description

@jlipworth

Scope

Native macOS 27 beta: a Plex Original/video-copy stream carrying Dolby Vision Profile 7 configuration fails decoder initialization. This is not a blanket HDR failure and does not establish failure on other Apple platforms.

Reproduction and controls

  • Source: 4K HEVC Main10, MKV, Dolby Vision P7 with HDR10-compatible base layer; TrueHD audio.
  • Plex decision: video copy, audio transcode; initialization/first-byte prewarm succeeds.
  • Delivered fMP4: hvc1, Main10 hvcC, colr/nclx primaries 9 / transfer 16 / matrix 9, retained dvcC profile 7.
  • Decoder log: kVTCouldNotFindVideoDecoderErr (-12906), then kVTVideoDecoderUnsupportedDataFormatErr (-12910), surfaced as AVFoundation undecodable media (-11855).
  • Reproduces with HDR enabled through the master and HDR disabled through the existing bounded single-variant child selector.
  • A distinct-source HEVC/PQ/BT.2020 HDR10 control (without DV configuration) plays on the same native host with both display settings; decoded frames were inspected.
  • Explicit capped video transcode of the failing source visibly plays. This does not prove HDR output or preservation of DV metadata.
  • Original correctly requests encoding consent on failure; declining does not start an encoder.

Candidate scope / open questions

Investigate compatible base-layer delivery/normalization rather than weakening the P5 guard, removing color metadata blindly, or silently transcoding. No broad P7 policy change is justified by this one source/packaging result.

Stats currently predicts HDR10 fallback from source/copy intent before any runtime signal is observed. A narrow candidate separates unverified requests from observed stream signaling; neither is measured HDR light output.

Physical iPad/iPhone deployment is currently blocked by device preparation/availability; Vision Pro unavailable; no physical tvOS device available. HDR luminance/colorimetry and other DV profiles remain open. Private identifiers, media, logs and frames are not included here.

Activity

  1. jlipworth commented on Sep 14, 2026

    @jlipworth
    OwnerAuthor

    Additional bounded native-Mac controls (same macOS beta host):

    • HDR10 video-copy playback and seek passed on an HDR-enabled player screen. Decoded 3840×2160 buffers carry PQ transfer and BT.2020 primaries/matrix; decoded PNGs were inspected. This is post-decoder/pre-display evidence, not measured luminance.
    • Explicit 8 Mbps encoding of the failing DV P7 source passed playback/seek with inspected frames and 1920×1080 BT.709 decoder-output attachments (SDR). This does not establish native DV support or successful HDR presentation.
    • DV P7 copy still fails both HDR-on master and HDR-off single-child paths. No speculative metadata-stripping workaround or implicit video-encoding change was applied.
    • Temporary display settings restored and verified; private source bindings, initialization bytes, logs and frames remain local/gitignored.

    Candidate diagnostic wording now distinguishes observed stream signaling from unverified copy/encode intent. Physical-device coverage remains gated; this issue is not resolved.

  2. jlipworth commented on Sep 14, 2026

    @jlipworth
    OwnerAuthor

    Evidence correction: the native HDR10 control used the original probe scenario, which verifies playback progression/hold but does not seek even if a seek-time argument is present. Its decoded PQ/BT.2020 result stands, but the earlier native-control “seek passed” wording should be read as “hold passed.” The explicitly encoded DV control used the actual seek scenario. Initial/postseek capture directory names alone are not proof of a seek.

    Separate iPhone/iPad simulator HDR10 controls now pass the actual zero-bitrate seek scenario with position snapshots and inspected post-seek frames. These do not establish native-Mac seek coverage or physical HDR output. DV decoder work remains separate.

  3. jlipworth commented on Sep 14, 2026

    @jlipworth
    OwnerAuthor

    Investigation checkpoint (local, not published as a playback fix):

    • Corrected control provenance: the passing HDR10 control is a different source file, not an extracted base layer from the failing P7 file. The same-source successful control remains an explicitly approved capped SDR encode.
    • Native format-description experiment: original, reconstructed and restored P7 descriptions each fail VideoToolbox decoder creation with -12910. Omitting only the retained dvcC entry from the extension-atom dictionary permits decoder creation, preserving subtype, dimensions, hvcC and other extensions. No compressed samples are submitted by this experiment; it does not prove safe metadata removal, accurate decoding or normalized HLS playback.
    • Fresh isolated-app authentication and exact-source copy reproduction confirmed the initialization boundary and preserved encoding consent. Compressed-sample acquisition remains incomplete; continuation requires manual Mac unlock and a bounded, provenance-matched capture, followed by sample decoding, inspected frame comparisons and end-to-end playback/seek verification. No shipping playback behavior changed.
    • Validation: 1,705 hermetic package tests, 331 tooling tests and strict documentation/link/Mermaid checks passed. The full native hosted suite is not green: both 633-test runs failed the same offline preparation timing test (sustainedOfflineInitialWait, two expectations); its focused 10-test suite passed. No all-green hosted claim is made.

    Temporary acquisition code was reverted and the isolated staged app removed; private evidence and the isolated app session are preserved. P5 safety, Generic profile and explicit encoding consent remain unchanged. Investigation paused at the unlock/sample-acquisition gate; issue remains open.

  4. jlipworth commented on Sep 14, 2026

    @jlipworth
    OwnerAuthor

    Exact-source sample and local-HLS follow-up (still no shipping transformation):

    • After unlock, a normally authenticated isolated app captured one complete ~13 MB copy segment under a 16 MiB limit. It contains 240 video samples / 10.009 seconds, including 240 RPU and 798 wrapped enhancement-layer NAL units. The unchanged app copy path still requires encoding consent on failure.
    • Native VideoToolbox decoded all 240 samples after omitting only dvcC from the format description. A second run additionally removed only RPU/EL NAL types 62/63, retaining base VCL bytes, other NALs and timing. Both runs produced identical timestamp-matched raw 10-bit pixel hashes for every frame (193 unique), with PQ/BT.2020 attachments; visible late frames were inspected.
    • A native AVPlayer window reading local HLS failed with -11855 for the original captured initialization/segment. A configuration-only experimental initialization with dvcC replaced by a same-size free atom played the unchanged segment and sought from 5 seconds to beyond 7 seconds with an inspected visible frame. An explicit base-only experimental fragment also played/sought; reopening the configuration-only HLS repeated success.

    This establishes an HDR10-base delivery path for this short segment on this native host, not full Dolby Vision or enhancement-layer reconstruction, measured HDR output, general P7 support, or safe production normalization. MEL/FEL characterization, later content, live Plex multi-segment/range/seek/restart integration and hardened malformed-input regression coverage remain open. The local one-segment seek is not a server-seek test.

    Temporary acquisition changes were reverted; owned app/window/server resources cleaned up and private evidence preserved. No P5/Generic/consent changes, server configuration edits, source-library rewrites or release changes. Fresh hermetic/tooling/docs checks pass; the previously reported full native hosted timing-test failure remains a non-green gate. Issue remains open.

  5. jlipworth commented on Sep 14, 2026

    @jlipworth
    OwnerAuthor

    HDR diagnostics/evidence PR #317 is merged and reachable on origin/main at 7ecdf6b1.

    This landed honest stream-versus-display diagnostics, bounded probe evidence and the documented Plex HDR10/HDR10+-source simulator results—not a DV P7 normalization fix. Final PR CI passed docs, hygiene and PMSKit; native/simulator proof levels and the native Original hold-only correction remain documented. The investigation stays active in docs/research/native-hdr-validation.md.

    Issue #316 remains open for the separate DV implementation and acceptance work. Physical HDR presentation, mixed-display behavior and HDR10+ dynamic-metadata processing are not established by this merge; equivalent Jellyfin/Emby live acceptance is also untested here. No DV candidate, P5 guard relaxation or implicit encoding change was included.

  6. jlipworth commented on Sep 15, 2026

    @jlipworth
    OwnerAuthor

    PR #318 is merged and reachable on origin/main at 33318438 (coordinated 1.7.1 build 1).

    This ships the reviewed partial-support scope: narrowly verified Jellyfin copy-HLS waiting behavior and diagnostic/probe improvements. The P7 HDR10-base experiment remains default-off and DEBUG macOS only; Release does not enable it. Generic Plex profile, P5 guards and explicit video-encoding consent remain unchanged.

    Exact reviewed-tree validation: full macOS 637 tests twice, iOS 621, tvOS 339 with normal runner exit; hermetic 1,707 Swift Testing plus 119 XCTest; fresh iPhone/TV semantic fixtures with inspected attachments; all five premerge CI contexts passed. Historical intermittent runner/deadline failures remain documented rather than retroactively waived. Research stays active in docs/research/dv-p7-decoder-boundary.md; full DV reconstruction, physical HDR presentation and broader profile acceptance are not established by this merge. Physical-device installation is being verified separately and is not playback acceptance.

    Preserving the issue's existing closed state; this comment does not claim universal DV support or an App Store/TestFlight release.

  7. jlipworth commented on Sep 15, 2026

    @jlipworth
    OwnerAuthor

    PR #320 is merged and reachable on origin/main at 4ed709a4. The published tree matches the reviewed PR head exactly.

    Landed scope: per-open initialization-representation pinning/rejection, deterministic replacement-wait coverage, and the isolated deletion-persistence test prerequisite. The P7 HDR10-base candidate remains default-off, DEBUG macOS only; Release, Plex Generic, P5 guards, and explicit video-encoding consent are unchanged.

    All five PR/push CI contexts passed before merge. Exact-revision native/package/simulator results and their limitations remain recorded in the PR and active docs/research/dv-p7-decoder-boundary.md; this closeout does not turn historical failures or blocked runs into passes. Fresh closeout documentation/hygiene checks passed.

    Remaining research/acceptance: exact-source Plex rebind and fresh reopen (saved binding returned 404); Jellyfin sampling-gap investigation (no post-hold pass); missing canonical visionOS golden-simulator pointer; broader source/later-segment equivalence and physical HDR/DV/audio validation. No production enablement or App Store upload occurred.

    Preserving the issue's existing closed state for the reviewed partial-support scope, not claiming universal Dolby Vision support. Research remains active rather than archived.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions