DV Profile 7 dual-layer MKV: video track has no format description (`<no fdesc>`) → AVPlayer `-11855`; HDR10 fallback fails identically

[RomanLiberda]

Summary

A Dolby Vision Profile 7 dual-layer MKV (UHD-BD remux) fails to start on the native / HLS-loopback path. AVPlayer rejects every rendition variant with AVFoundationErrorDomain -11855 ("Cannot Decode"), underlying CoreMediaErrorDomain -12910. The item's video track arrives with no format description (fourCC=<no fdesc>, enabled=false), i.e. CMVideoFormatDescription could not be built from the generated init.mp4 hvcC.

The engine's own fallback ladder — DV master → HDR10-only master_hdr → media.m3u8 — fails identically, so this is not DV-signaling-specific: the plain HDR10 base-layer rendition is equally undecodable.

Per CHANGELOG 1.3.2 ("DV Profile 7 (UHD-BD remuxes) now plays: routed as plain HEVC HDR10 with the source dvcC stripped"), this file is expected to play. The signature matches the hvcC-has-no-parameter-set-arrays class fixed for P5 MP4 in 2.0.2 (#19), now recurring for DV P7 dual-layer MKV.

Environment

• AetherEngine 6.21.0
• Apple TV 4K, tvOS 26.6 (build 23L773) — UA AppleCoreMedia/1.0.0.23L773
• HDR-capable panel, Match Content ON (panelIsHDR=true, EDR headroom 1.20, useMaster=true)

Source media (ffprobe)

• Container: Matroska (MKV), ~61.8 GB (66,343,218,052 B). HTTP source, full Range support verified (206 Partial Content with correct Content-Range at offset 0, mid-file, and near-EOF).
• Video: HEVC Main 10, 3840×2160, yuv420p10le, bt2020nc / smpte2084 / bt2020 (HDR10 / PQ base).
• DOVI configuration record:

  dv_version_major=1  dv_version_minor=0
  dv_profile=7  dv_level=6
  rpu_present_flag=1  el_present_flag=1  bl_present_flag=1
  dv_bl_signal_compatibility_id=6
  dv_md_compression=extended
  

• Audio: AC-3 5.1 (eng), single track.
• Subtitles: 11× HDMV PGS.
• Secondary anomalies (probably not root cause, included for completeness): the video PTS is anchored at ~4200 s (engine compensates with a shift); the MKV Cues are sparse — index unusable (10 IRAPs, coverage 8889.8s, largestGap 8641.3s) → uniform-stride fallback.

I can't attach the ~62 GB source, but the ffprobe above + full log below should localize it. Happy to provide a fuller -show_streams dump or a short remuxed clip if useful.

Expected

Plays as HDR10 (P7 base layer), per CHANGELOG 1.3.2.

Actual

Every rendition fails with -11855 / -12910; the video track has no format description.

Engine prep + serving:

prepared: codec=hvc1.2.4.L153,ac-3 supplemental=dvh1.08.06/db1p resolution=3840x2160 fps=23.976 range=PQ DV=profile7 segments=2222
serving on http://127.0.0.1:<port>/master.m3u8 (dvModeAvailable=true effectiveDvMode=true panelIsHDR=true useMaster=true videoRange=pq dvVariant=profile7)

Master playlist advertises HDR10 base + DV P8 supplemental:

#EXT-X-STREAM-INF:...,CODECS="hvc1.2.4.L153,ac-3",SUPPLEMENTAL-CODECS="dvh1.08.06/db1p",RESOLUTION=3840x2160,VIDEO-RANGE=PQ

Failure (repeats for master.m3u8, master_hdr.m3u8, and media.m3u8):

video codecpar: codec=173 3840x2160 profile=2 level=153 extradata=726B head=00000140010c01ff
in-band parameter-set scan found none: packets=16 vps=false sps=false pps=false
...
item.status=failed err=AVFoundationErrorDomain/-11855 'Cannot Decode'
  item.error.underlying=CoreMediaErrorDomain/-12910
  item.tracks[0] mediaType=vide fourCC=<no fdesc> enabled=false
  item.tracks[1] mediaType=soun fourCC=<no fdesc> enabled=false
readiness gate: master never produced tracks after 2 attempts; falling back to the media playlist (HDR10 base, DV upgrade dropped)
#10 media.m3u8 → item.status=failed err=-11855 (identical)

The segments themselves are produced fine (seg0.mp4 5.9 MB captured and served); the failure is purely AVPlayer being unable to build a video format description from init.mp4.

Analysis / suspicion

• <no fdesc> ⇒ CMVideoFormatDescription couldn't be built from the output hvcC — the exact class 2.0.2 addressed (config record with no parameter-set arrays / numOfArrays = 0).
• Source is MKV, whose parameter sets live in CodecPrivate → codecpar.extradata (here 726 B, head=00000140010c01ff = annex-B VPS start), which per the 2.0.2 note should let ff_isom_write_hvcc rebuild a proper hvcC. On paper MKV shouldn't hit this — yet this P7 dual-layer file does. The large 726 B extradata likely carries BL + EL parameter sets; a plausible culprit is ff_isom_write_hvcc (or the P7 route) mishandling the dual-layer extradata, and/or dv_md_compression=extended.
• The current P7 route emits SUPPLEMENTAL-CODECS="dvh1.08.06" rather than the "strip dvcC → plain HEVC HDR10" behavior described in 1.3.2. If P7 fell back to that plain-HDR10 strip path with a correctly rebuilt hvcC, it would presumably decode.

Repro

Any DV Profile 7 dual-layer (BL+EL+RPU) HEVC Main10 MKV with bl_signal_compatibility_id=6 and md_compression=extended. Reproduced on a UHD-BD remux streamed over HTTP (host supports Range fully; not a transport issue).

---

Related (separate issue if wanted): a different UHD HDR10 remux hits muxerFailed — "prime scan gave up … without an audio packet" — when the selected audio track is a sparsely-interleaved legacy track (Czech AC-3 2.0 "VHS, TV") far from the start; a well-interleaved track on the same file muxes fine. Can file separately with logs + ffprobe.

[DrHurt]

Aether strips the EL and converts the BL to P8.1 on the fly. AVPlayer will fallback to HDR10 automatically if the display doesn't support DV.

That said, I haven't played any P7 movies for a while so something might have broke a at some point.

[RomanLiberda]

Thanks! Two things that might narrow it:

1. It's not only the DV→HDR10 fallback failing to engage — the HDR10-only paths fail identically. The ladder tried master.m3u8 (hvc1 + SUPPLEMENTAL-CODECS=dvh1.08.06), then master_hdr.m3u8 (DV dropped), then media.m3u8 (plain HDR10 base) — all three end in item.status=failed -11855 with the video track as fourCC=. So the base-layer sample entry itself is undecodable, which points at BL extraction / hvcC generation rather than DV signaling.

2. Source RPU is dv_md_compression=extended (full record: profile 7, level 6, bl/el/rpu present, bl_signal_compatibility_id=6). If the on-the-fly BL→P8.1 conversion doesn't handle extended metadata compression, that'd be a candidate for the regression.

Display is DV-capable.

[DrHurt]

Additional data point:

Tested my DV P7 BL+EL+RPU on the current beta on Sodalite and it played successfully as P8.1 and triggered TV's DV mode.

dovi_tool which the engine uses for conversion does support compressed RPU (unless it's broken)

I think point 1 is the more likely culprit.

[superuser404notfound]

Fixed in 6.25.0 (30269926, merged df509474). Thanks for the log, it contains the answer even though the analysis around it points elsewhere.

The hvcC is not the problem

I built three fixtures from one source by EBML surgery (proper hvcC CodecPrivate, Annex-B CodecPrivate, Annex-B CodecPrivate plus Annex-B blocks) and all three produce a byte-identical, correct 116-byte hvcC with three parameter-set arrays.

fourCC=<no fdesc> also does not carry the meaning it looks like it carries: that line comes from a dump of item.tracks on an item that has already failed, and in the posted log the AC-3 track prints exactly the same thing. An audio track cannot be missing a format description because of an hvcC. The engine's own doc comment made the same shortcut, from #19, and has been corrected too.

What the log does pin down

One line: extradata=726B head=00000140010c01ff. That config record is Annex B, not an hvcC. That is the shape a Matroska remux has when its CodecPrivate is Annex B or absent entirely, in which case libavformat synthesises Annex-B extradata from the first in-band parameter sets. It also explains in-band parameter-set scan found none in the same log: bytes 21 and 22 of an Annex-B HEVC record pass that scan's hvcC checks by construction, because the 00 00 03 emulation-prevention pattern in a Main10 VPS sits exactly there.

From there it is the mp4 muxer's own rule that does the damage. mov_write_packet_internal decides whether to convert samples by looking at the extradata, not at the packet: "extradata is Annex B, assume the bitstream is too and convert it". When the packets are in fact length-prefixed, ff_hevc_annexb2mp4 runs over MP4-framed samples and finds start codes only where a 4-byte NAL length happens to read as 00 00 01. Measured on a 1080p fixture: a 2,158,448 B segment came out at 61,912 B, the init.mp4 stayed perfectly valid, and AVPlayer reached readyToPlay and never produced a frame. That is also why the whole ladder failed identically in the report: master, master_hdr and media all serve the same segments.

The engine now measures the framing on real packets at open and converts the config record to an hvcC when the two disagree, so the muxer's test comes out right.

A second defect on the same sources

@DrHurt, the data point that a P7 BL+EL+RPU disc plays on the current beta was the useful one, because it localised this to the source rather than the route. The DV P7 to 8.1 RPU rewrite walks NALs assuming length prefixes, so on Annex-B packets it read 00 00 01 40 as a 320-byte NAL, found no RPU, reported success, and shipped the P7 RPU and the enhancement layer inside a container already rewritten to 8.1. Silently, with the only symptom being an absent FEL log line. It now takes the measured framing and emits packets in the framing it received.

Retest

Both shapes are covered, so the fix does not depend on which one this file is. After the fix all three fixtures produce a byte-identical init.mp4 and a byte-identical 2,158,448 B seg0, and all three reach first frame in a real AVPlayer.

If the file still fails on 6.25.0, the fastest decisive artifact is the first 2 MB of it (dd if=movie.mkv bs=1M count=2 of=head.bin): the EBML header plus the first cluster settles both the CodecPrivate form and the block framing in one go.

One note on the CHANGELOG line quoted in the report: the 1.3.2 wording ("routed as plain HEVC HDR10 with the source dvcC stripped") has been out of date since 3.11.0, which converts P7 to 8.1 with libdovi instead of stripping it. The strip only remains for a non-DV display.

[RomanLiberda]

Retested on 6.25.1 — plays in Infuse, still fails in the engine's fMP4 → AVPlayer path

This exact file plays fine in Infuse (which demuxes the MKV directly and drives the decoder itself), so the source is not the blocker — the failure is specific to AetherEngine's remux-to-fMP4 → AVPlayer handoff, where AVPlayer needs a valid hvcC / sample entry to build a CMVideoFormatDescription.

Source: DV Profile 7 dual-layer MKV, HEVC Main10 4K PQ + AC-3 5.1 + 11× PGS. Env: AetherEngine 6.25.1 / tvOS 26.6 (AppleCoreMedia/1.0.0.23L773, Apple TV, loopback HLS).

On 6.25.1 the new framing-probe path fires and explicitly logs #365:

video codecpar: ... profile=2 level=153 extradata=726B head=00000140010c01ff
video NAL framing probe: inspected=4 lengthPrefixed=0 annexB=4 → annexB
#365 the muxer will reformat this track's samples and the packets are Annex B;
     forwarding the config record unchanged (the muxer converts the samples itself)

…but AVPlayer still cannot build a video format description from the resulting init.mp4 (1977 B), and the item fails as before:

item.status=failed err=AVFoundationErrorDomain/-11855 'Cannot Decode'
item.error.underlying=CoreMediaErrorDomain/-12910
item.tracks[0] mediaType=vide fourCC=<no fdesc> enabled=false
item.tracks[1] mediaType=soun fourCC=<no fdesc> enabled=false

The engine then walks all of its own fallbacks and every one hits the same -11855 / -12910:

1. master.m3u8 (DV) → failed
2. master.m3u8 via LAN IP (readiness-gate reload, attempt 2/2) → failed
3. master_hdr.m3u8 (DV dropped, CODECS="hvc1.2.4.L153,ac-3", VIDEO-RANGE=PQ) → failed
4. media.m3u8 (HDR10 base, DV upgrade dropped this session) → failed

The DV-stripped HDR10 fallback failing identically is the key point: the blocker is the plain HEVC hvcC / parameter-set construction in the remuxed init, not Dolby Vision signalling.

Observations that may help root-cause

• Extradata is Annex-B, not a length-prefixed config record: extradata=726B head=00000140010c01ff (start code 00 00 01 + NAL 40 = VPS). The probe classifies it correctly (annexB=4) and the #365 path forwards it to the muxer — but the muxer-built hvcC in init.mp4 is still not something AVPlayer accepts (<no fdesc>). Possibly the dual-layer BL+EL parameter sets in the 726 B blob don't round-trip through ff_isom_write_hvcc into a record AVPlayer will parse.

• DV signalling mismatch: the master advertises SUPPLEMENTAL-CODECS="dvh1.08.06/db1p" (Profile 8), but the stream is served as Profile 7 unconverted:

  DV source: profile=7 compat=6 level=6 rpu=1 el=1 bl=1 color_primaries=9 color_trc=16 color_space=9
  prepared: codec=hvc1.2.4.L153,ac-3 supplemental=dvh1.08.06/db1p ... range=PQ DV=profile7
  

  No libdovi P7→8.1 conversion appears on this loopback VOD path — the config record is "forwarded unchanged" — yet the playlist declares dvh1.08.06. (Separate from the primary <no fdesc> failure, since the HDR10 fallback dies too.)

Not the blocker (Infuse tolerates these — listed only for completeness)

The Matroska cue index is sparse and the video PTS base is far from zero, so the engine falls back to uniform-stride segmentation:

segment plan: uniform stride fallback (index unusable (10 IRAPs, coverage=8889.8s,
  largestGap=8641.3s), anchorPts=377996246, measured IRAP spacing 0.876s → stride=4.000s, 2223 segments)
VOD shift published: 4199.958s ... presentationOrigin=4200.000s

This is not a resume — playback started at position 0 (video gate open: ... desired=0); the ~4200 s is the source's own PTS base, which the engine shifts to item time 0. Infuse plays the same file without issue, so these properties are tolerable and are not the cause of the decode failure — noted only in case they interact with the muxer path.

[superuser404notfound]

Thanks for the retest, and for running it with the log excerpt rather than just the verdict. Two of the inferences in it do not separate what they look like they separate, and saying why narrows this down rather than widening it.

The four attempts share one init.mp4. The readiness-gate ladder only calls load() with a different playlist URL against the same local server (inPlaceSwap: true), and master_hdr.m3u8 is a reduced master, not a second remux. So the DV-stripped arm failing identically does rule out the playlist signalling, but it cannot separate "the hvcC" from "the DV boxes in the init": all four arms read the same init bytes.

fourCC=<no fdesc> is not a statement about the video track. dumpFailedItemTracks runs on an item that has already failed, and on a failed item every track prints that, which is why the AC-3 track shows it too. That reading is what pointed round 1 at the hvcC when the defect was actually in the sample framing.

The BL+EL idea is refuted at the source. hvcc_add_nal_unit (libavformat/hevc.c, identical in the pinned n8.1.2 and on master) drops every NAL with nuh_layer_id > 0 unless it is writing an lhvC box, so enhancement-layer parameter sets cannot reach the record even when they sit in the CodecPrivate. The VPS head posted above says the same thing from the other side: 40 01 0c 01 ff decodes to vps_max_layers_minus1 = 0, a single-layer VPS.

What I did find sits one line above that, and it is a real gap. ff_isom_write_hvcc collects five NAL types, not three:

static const uint8_t array_idx_to_type[] =
    { HEVC_NAL_VPS, HEVC_NAL_SPS, HEVC_NAL_PPS,
      HEVC_NAL_SEI_PREFIX, HEVC_NAL_SEI_SUFFIX };

So on the path this file takes, where the record is forwarded as Annex B and movenc builds the hvcC itself, a prefix SEI in the CodecPrivate becomes a fourth array in that record. That is exactly the shape Apple TV's HEVC track builder rejects (AE#187: asset.tracks count=0, no format description). The engine has carried a defense against it since #187 and it cannot reach this door: it guards on configurationVersion == 1, which an Annex-B buffer fails by construction, and the record movenc builds never passes through the engine at all.

Measured rather than assumed: feeding a real 1080p Main10 PQ VPS+SPS+PPS plus a 506 B user-data SEI, in Annex B, through the same movenc path the session muxer uses returns a record whose arrays are [32, 33, 34, 39].

The size fits the report. Those parameter sets are 78 B of NAL payload in total. A 4K SPS is bigger, but not several hundred bytes bigger, so 726 B leaves a lot of room for something that is not a parameter set.

Fixed on main in f6201cf (merge d2fc7f2): the non-parameter-set NALs are dropped before the muxer runs. The record stays Annex B, so movenc's decision about the samples is unchanged and only the SEI is gone. It ships with the next release.

What settles it for this file. The record's size alone does not say whether the excess is a large SPS or an SEI, and only the latter reaches the hvcC, so the forward branch now logs the composition. Next run it reads like this, .session category, the same channel as the lines quoted above:

#365 the muxer will reformat this track's samples and the packets are Annex B;
the muxer builds the config record itself out of 726 B of Annex B
[VPS×1 (28 B), SPS×1 (112 B), PPS×1 (10 B), SEI_PREFIX×1 (570 B)],
dropped the non-parameter-set NALs before it does (→ 156 B, AE#187)

If it ends in nothing to drop instead, this candidate is dead for that file, the DV configuration boxes in the init are next in line, and the first 2 MB of the source (EBML header plus the first cluster) would settle the remaining framing question at the same time.

The DV signalling mismatch is worth its own look and I am not treating it as the blocker yet, for the reason in the first paragraph: with one init behind all four attempts, that arm has not been tested independently.

[superuser404notfound]

Out as 6.25.4.

What decides it on that file is the #365 line in the .session channel, the one that already carried the framing verdict in the last capture. It now names the record's composition. SEI_PREFIX×N in the brackets means this was it; nothing to drop at the end means it was not, and then the DV configuration boxes in the init are next and the first 2 MB of the source (EBML header plus first cluster) would answer the remaining framing question in the same pass.