Repository navigation
fix(hdr10+): carry HDR10+ on the software path - #814
Open
williamliu0516 wants to merge 3 commits into
Open
williamliu0516 wants to merge 3 commits into
williamliu0516 wants to merge 3 commits into
Conversation
… and both decoders attach it in Core Media's shape A PQ HEVC title with ST 2094-40 SEI played on the software path as plain HDR10: HardwareVideoDecoder never read the SEI (its onFirstHDR10PlusDetected was declared and never fired), so videoFormat stayed .hdr10 and no frame carried kCMSampleAttachmentKey_HDR10PlusPerFrameData. It now takes each packet's validated T.35 message (HDR10PlusMetadataScan.coreMediaPayload, PQ streams only), keeps it under the packet's presentation time until VideoToolbox outputs that frame, and passes it to the renderer, which already attaches it. SoftwareVideoDecoder attached a payload per frame, but serialised with av_dynamic_hdr_plus_to_t35, which omits the six T.35 header bytes the attachment is documented to start with; the header is put back. The loopback path is unchanged and needs nothing: with a two-scene 1080p HDR10+ fixture, every one of 144 messages is in the served fragments from MKV, MP4 and MPEG-TS (hdr10plus_tool extract identical to the source), and AVPlayerItemVideoOutput's buffers carry HDR10+ per frame, scene 2's values on scene 2. `aetherctl play --sw` on the same file now logs the .hdr10Plus upgrade and the renderer's attachments.
Resolves the CHANGELOG conflict: the HDR10+ software-path entry goes first under Unreleased › Fixed, beside main's newer entries. No code conflicted; main has no other change to the HDR10+ paths since the branch point.
Picks up superuser404notfound#809, which bounds "a stream refused for longer than the budget" from below and needs 2 refused attempts instead of 3: this branch's CI failed only there, with 2. CHANGELOG.md merged cleanly but left the entry under 7.43.0; it moves to [Unreleased] > Fixed, after the 7.45.0 prep. No code conflicted.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
HDR10+ now reaches the display when a title plays on the software path.
HardwareVideoDecodernever read the ST 2094-40 SEI (itsonFirstHDR10PlusDetectedwas declared but never fired), so a PQ HEVC title with HDR10+ showed as HDR10 and no frame had per-frame metadata. It now reads each packet's T.35 message (PQ streams only), holds it until VideoToolbox outputs that frame, and passes it on askCMSampleAttachmentKey_HDR10PlusPerFrameData. It also reports.hdr10Plus.av_dynamic_hdr_plus_to_t35, which leaves out the six T.35 header bytes (B5 00 3C 00 01 04). Apple documents that the attachment starts at the country code, so the header now goes back in front.The loopback path is unchanged and needed nothing.
Why
HDR10+ files are common (most streaming-service WEB-DLs carry it), and on the software path they lost their per-frame metadata.
Tested
AVPlayerItemVideoOutputgets HDR10+ on every frame (macOS 27). That path was already fine.aetherctl play --swon the same clip: it now logs the.hdr10Plusupgrade and the renderer's per-frame attachments (64 bytes each, the same as AVPlayer's own decoder gives).HDR10PlusMetadataScanTestscase: the payload comes out the same from SEI (Annex B and length-prefixed, H.264 and HEVC) and from Matroska side data. The HDR10+ and decoder suites pass.