Videos with Dolby Profile 5 in MP4 container cannot be played using native player (avplayer hls).

[strangeliu]

video info:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'The.Wandering.Earth.Ⅱ.2023.V2.WEB-DL.4K.HEVC.DV.DDP-Enichi.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomdby1iso2mp41
title : The Wandering Earth Ⅱ (2023)
encoder : Lavf61.7.100
Duration: 00:00:30.13, start: 0.000000, bitrate: 16529 kb/s
Stream #0:00x1: Video: hevc (Main 10) (dvh1 / 0x31687664), yuv420p10le(tv), 3840x1616 [SAR 1:1 DAR 240:101], 16396 kb/s, 24 fps, 24 tbr, 6150144 tbn (default)
Metadata:
handler_name : VideoHandler
encoder : DOVI Coding
Side data:
DOVI configuration record: version: 1.0, profile: 5, level: 6, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 0, compression: 0
Stream #0:10x2: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 126 kb/s (default)
Metadata:
handler_name : SoundHandler

[superuser404notfound]

Thanks for the report.

The engine's DV Profile 5 path looks correct on inspection: P5 is detected from the dvcC record, routed as dvh1 with the dvcC box preserved through muxing, and the HLS master/media playlist emits CODECS="dvh1.05.<level>,..." as expected. So the most likely causes are environmental rather than a missing code path.

Could you share the following so I can reproduce or rule things out?

1. Apple TV model (4K gen 1 / 2 / 3?) and tvOS version.
2. Display chain: TV (and AVR if any), and whether they negotiate Dolby Vision when other DV content plays (e.g. an Apple TV+ DV title).
3. AetherEngine version, and which host app (Sodalite or your own integration).
4. Whether any DV Profile 5 file plays for you, or only this one fails. Profile 7 / 8.1 files for comparison are useful too.
5. Console log from the playback attempt (start of session through the failure). If the host exposes a log capture, that is ideal; otherwise the AVFoundation / AVPlayer error code from the failure is the minimum useful signal.

If you can share a short sample that reproduces, even a 5 to 10 second clip, that helps a lot. P5 compatibility_id=0 has no HDR10 base layer, so it requires a DV-capable sink end to end; that is the first thing I want to rule out before chasing a muxer bug.

[strangeliu]

Thanks for your quick response, The device I am using is an M1 MacBook Pro. Here is the problematic video segment:
https://www.dropbox.com/scl/fi/hp7js4bdxebaxkt2b78se/The.Wandering.Earth.-.2023.V2.WEB-DL.4K.HEVC.DV.DDP-Enichi.mp4?rlkey=d7kdlkrvowkidp5e0trm4sr8v&st=8nl9lzk0&dl=0

[superuser404notfound]

Thanks for the sample and platform info. M1 MacBook Pro changes the picture from my original triage, which assumed Apple TV.

Two things matter on macOS specifically:

1. AetherEngine's displayCapabilities.supportsDolbyVision is hard-coded to false on macOS (AetherEngine.swift:192). The DV detection on tvOS/iOS uses AVPlayer.availableHDRModes, but that API doesn't report DV on macOS, so the engine conservatively treats any macOS display as non-DV. For Profile 5 the engine still emits dvh1 + dvcC because that's the only legal packaging (no HDR10 base layer), routes the media playlist only, and relies on AVPlayer's internal DV decoder to tonemap. If AVPlayer's macOS DV decode path requires the display to advertise DV, the decode never engages and you get the symptom you reported.

2. Profile 5 has compatibility_id=0 with no HDR10 base layer. On a display chain that isn't DV-capable end to end, there is nothing to fall back to. The behaviour may be the expected outcome of "P5 on a non-DV sink", not an engine bug.

To narrow it down, please share:

• Exact MacBook Pro model (M1 13" 2020, M1 Pro/Max 14" or 16" 2021, M2, etc.) and macOS version. The 14"/16" XDR panels can decode DV in some configurations; the 13" Retina cannot.
• Which host: Sodalite, DemoPlayerMac, or your own integration.
• AetherEngine version (commit SHA or release tag).
• Whether the same file plays in QuickTime Player or Safari (Apple-native DV decode, no engine involved). If QuickTime also fails, the file cannot render DV on this Mac regardless of the engine.
• Whether any other DV Profile 5 file plays through AetherEngine on this Mac.
• AVFoundation / AVPlayer error code from the failed session (item.error or console log).

If QuickTime plays it but AetherEngine does not, there is an engine bug to fix. If neither plays it, the file needs a DV-capable display chain.

[strangeliu]

It’s very strange — it doesn’t seem to be related to the device. The video cannot be played on QuickTime Player, nor can it be played by AVPlayer on my iPhone. It appears to be a format issue. For a Dolby Vision video with profile 5, level 6, if it is packaged in MKV, it can be played via HLS, but not in MP4 format.
PS: I am using the release version 2.0.

[superuser404notfound]

Thanks, that's informative. It rules out a panel/display chain issue.

What I'm seeing: the MP4 container is rejected by Apple's AVAsset layer (QuickTime, iPhone AVPlayer). The matching MKV of the same content plays through AetherEngine, which means the elementary HEVC+DV stream is fine. So if there's an engine-side bug, it's in how AetherEngine handles a Profile 5 MP4 whose dvcC box or sample entry is non-standard in a way that breaks Apple's mp4 demuxer.

In the engine's pipeline, both MKV and MP4 go through the same FFmpeg demux + fMP4 remux. If FFmpeg's mp4 demuxer fails to extract AV_PKT_DATA_DOVI_CONF from the source's dvcC (non-standard location, malformed payload), doviConfigRecord returns nil, the variant classifies as .none, and the route falls back to plain HEVC HDR10. The output fMP4 sample entry then doesn't match the actual bitstream and AVPlayer rejects it. The MKV path succeeds because matroska stores the DV configuration record in a separate element that FFmpeg's matroska demuxer reads correctly even when the MP4 demuxer can't.

To confirm, please share:

1. ffprobe -hide_banner -v error -show_streams -show_format <file.mp4> output. Relevant fields: codec_tag_string on the video stream, any side_data_list entries (specifically a DOVI configuration record), color_transfer, color_primaries.
2. AetherEngine console log from the failed MP4 playback. Search for [HLSVideoEngine] serving on and the dvVariant= value.
3. If you have Bento4 handy, mp4dump -v <file.mp4> and the dvcC / hvcC / ftyp lines. That shows whether the dvcC is in the standard place.

If the log says dvVariant=none and ffprobe shows no DOVI side data, that is the engine-side fix path: extend the classifier to detect P5 from codec_tag == 'dvh1' and infer a default DOVI record when FFmpeg cannot parse the source's configuration directly.

[DrHurt]

Tested on my iPhone and also not working so it’s not an aether problem.

It’s probably a bad file and AVPlayer is very strict.

Many online files are mastered using dodgy tools which deviate from specs.

Tested via another app which uses AVPlayer via local HLS and it worked so I suspect they have a hack in place for broken DV5 files (this never happens with DV8 which AVPlayer is more relaxed about)

Best way @superuser404notfound can address this is comparing the Dolby reference mp4 I sent him with your broken file, seeing where the differences are and whether it could be corrected on the fly.

I suspect it will be straightforward.

[DrHurt]

When I worked on this before, this problem only ever happened with some DV5 files in mp4 containers.

Never happened with mkv or DV8.

[superuser404notfound]

Confirmed the root cause from the Dropbox sample.

The MP4 has dvh1 + a well-formed dvcC (P5 L6 compat_id=0), but the HEVC SPS VUI transfer / primaries / matrix are all unspecified and there's no colr atom on the sample entry. FFmpeg's mp4 demuxer reports color_transfer=unknown for that source. The engine was stream-copying through to its output fMP4 without filling in the gap, so AVPlayer saw a dvh1 sample entry with no explicit PQ signal and refused to engage the DV decoder.

The MKV variant works because matroska's Colour element populates codecpar.color_* directly, which FFmpeg's mp4 muxer then writes as a colr nclx atom. The mp4 demuxer has no equivalent inference.

Fixed in af8cafd: when dvVariant == .profile5, force the canonical P5 color tuple (BT.2020 primaries, PQ transfer, BT.2020-NCL matrix, limited range) on the muxer's stream codecpar before avformat_write_header. P5 is defined as IPT-PQ-c2, so the dvcC record alone implies that signaling, which makes the override safe (no risk of mislabeling a non-PQ source).

@strangeliu please pull the latest main and re-test. @DrHurt thanks for the comparison framing, the broken-vs-reference angle made the missing PQ signal jump out quickly.

[strangeliu]

1. ffprobe output:

[STREAM]
index=0
codec_name=hevc
codec_long_name=H.265 / HEVC (High Efficiency Video Coding)
profile=Main 10
codec_type=video
codec_tag_string=dvh1
codec_tag=0x31687664
width=3840
height=1616
coded_width=3840
coded_height=1616
has_b_frames=4
sample_aspect_ratio=1:1
display_aspect_ratio=240:101
pix_fmt=yuv420p10le
level=150
color_range=tv
color_space=unknown
color_transfer=unknown
color_primaries=unknown
chroma_location=left
field_order=unknown
view_ids_available=
view_pos_available=
id=0x1
r_frame_rate=24/1
avg_frame_rate=24/1
time_base=1/6150144
start_pts=0
start_time=0.000000
duration_ts=185273088
duration=30.125000
bit_rate=16396374
max_bit_rate=N/A
bits_per_raw_sample=N/A
nb_frames=723
nb_read_frames=N/A
nb_read_packets=N/A
extradata_size=23
DISPOSITION:default=1
DISPOSITION:dub=0
DISPOSITION:original=0
DISPOSITION:comment=0
DISPOSITION:lyrics=0
DISPOSITION:karaoke=0
DISPOSITION:forced=0
DISPOSITION:hearing_impaired=0
DISPOSITION:visual_impaired=0
DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0
DISPOSITION:non_diegetic=0
DISPOSITION:captions=0
DISPOSITION:descriptions=0
DISPOSITION:metadata=0
DISPOSITION:dependent=0
DISPOSITION:still_image=0
DISPOSITION:multilayer=0
TAG:language=und
TAG:handler_name=VideoHandler
TAG:encoder=DOVI Coding
[SIDE_DATA]
side_data_type=DOVI configuration record
dv_version_major=1
dv_version_minor=0
dv_profile=5
dv_level=6
rpu_present_flag=1
el_present_flag=0
bl_present_flag=1
dv_bl_signal_compatibility_id=0
dv_md_compression=none
[/SIDE_DATA]
[/STREAM]
[STREAM]
index=1
codec_name=aac
codec_long_name=AAC (Advanced Audio Coding)
profile=LC
codec_type=audio
codec_tag_string=mp4a
codec_tag=0x6134706d
mime_codec_string=mp4a.40.2
sample_fmt=fltp
sample_rate=44100
channels=2
channel_layout=stereo
bits_per_sample=0
initial_padding=0
id=0x2
r_frame_rate=0/0
avg_frame_rate=0/0
time_base=1/44100
start_pts=0
start_time=0.000000
duration_ts=1323441
duration=30.010000
bit_rate=126634
max_bit_rate=N/A
bits_per_raw_sample=N/A
nb_frames=1295
nb_read_frames=N/A
nb_read_packets=N/A
extradata_size=2
DISPOSITION:default=1
DISPOSITION:dub=0
DISPOSITION:original=0
DISPOSITION:comment=0
DISPOSITION:lyrics=0
DISPOSITION:karaoke=0
DISPOSITION:forced=0
DISPOSITION:hearing_impaired=0
DISPOSITION:visual_impaired=0
DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0
DISPOSITION:non_diegetic=0
DISPOSITION:captions=0
DISPOSITION:descriptions=0
DISPOSITION:metadata=0
DISPOSITION:dependent=0
DISPOSITION:still_image=0
DISPOSITION:multilayer=0
TAG:language=zho
TAG:handler_name=SoundHandler
[/STREAM]
[FORMAT]
filename=/Users/liu/Downloads/The.Wandering.Earth.Ⅱ.2023.V2.WEB-DL.4K.HEVC.DV.DDP-Enichi.mp4
nb_streams=2
nb_programs=0
nb_stream_groups=0
format_name=mov,mp4,m4a,3gp,3g2,mj2
format_long_name=QuickTime / MOV
start_time=0.000000
duration=30.125000
size=62243354
bit_rate=16529355
probe_score=100
TAG:major_brand=isom
TAG:minor_version=512
TAG:compatible_brands=isomdby1iso2mp41
TAG:title=流浪地球2[The Wandering Earth Ⅱ ](2023)
TAG:encoder=Lavf61.7.100
[/FORMAT]

2. AetherEngine logs:

[Demuxer] Opened: 2 streams, duration=30125000 us
[Demuxer]   stream[0] type=video 3840x1616
[Demuxer]   stream[1] type=audio 0x0
[AetherEngine] load url=The.Wandering.Earth.%E2%85%A1.2023.V2.WEB-DL.4K.HEVC.DV.DDP-Enichi.mp4 source-format=dolbyVision effective-format=sdr rate=23.976
[AetherEngine] dispatch: codec=173 → native
[HLSVideoEngine] cue prewarm: seek to 15.1s took 0.0ms
[HLSVideoEngine] segment plan: keyframe-aligned, 16 IRAPs → 8 segments [firstKeyframePts=-768768 (-0.125s) videoStream.start_time=0 format.start_time=0us plan[0].startSeconds=0.000]
[HLSVideoEngine] DV source: profile=5 compat=0 level=6 rpu=1 el=0 bl=1 color_primaries=2 color_trc=2 color_space=2
[HLSVideoEngine] audio: codec=aac → stream-copy as `mp4a.40.2` (fallback duration=1024 in audioTb 1/44100)
[HLSSegmentProducer] init OK (baseIndex=0, segments=8, targetDur=4.000s, srcVideoTb=1/6150144) audio=stream-copy inTb=1/44100
[HLSVideoEngine] prepared: codec=dvh1.05.06,mp4a.40.2 resolution=3840x1616 fps=24.000 range=PQ DV=profile5 segments=8 duration=30.1s
[HLSLocalServer] Listening on port 50054
[HLSSegmentProducer] video gate open: actual=-768768 anchorPts=0 target=-9223372036854775808 desired=0 shift=-768768
[HLSSegmentProducer] first video pkt: dts=0 pts=768768 duration=256256 size=8658 (fallback=256256 in srcVideoTb)
[HLSSegmentProducer] audio gate open: actual=-2646 target=-5513 desired=0 shift=-2646 gapMs=65.0
[HLSSegmentProducer] WARNING: audio gate opened 65.0 ms after video gate (baseIndex=0). Audio content for seg-0's first video frame is offset from the video by this much, expect A/V drift to be audible.
[HLSVideoEngine] serving on http://127.0.0.1:50054/media.m3u8 (dvModeAvailable=false effectiveDvMode=false panelIsHDR=false displaySupportsHDR=true matchContent=true sourceIsHDR=true useMaster=false videoRange=pq dvVariant=profile5)
[HLSSegmentProducer] init.mp4 captured (1372 B)
[NativeAVPlayerHost] #1 load url=http://127.0.0.1:50054/media.m3u8 startPos=nil
[NativeAVPlayerHost] #1 timeControlStatus=paused reason=-
[NativeAVPlayerHost] #1 rate=1.0
[NativeAVPlayerHost] #1 timeControlStatus=waitingToPlay reason=AVPlayerWaitingWhileEvaluatingBufferingRateReason
[HLSSegmentProducer] seg-0.m4s captured (7643902 B)
[NativeAVPlayerHost] #1 rate=1.0
[NativeAVPlayerHost] #1 timeControlStatus=waitingToPlay reason=AVPlayerWaitingWhileEvaluatingBufferingRateReason
[HLSSegmentProducer] seg-1.m4s captured (3453854 B)
[HLSSegmentProducer] seg-2.m4s captured (5618375 B)
[HLSSegmentProducer] seg-3.m4s captured (5464797 B)
[HLSSegmentProducer] seg-4.m4s captured (7250088 B)
AddInstanceForFactory: No factory registered for id <CFUUID 0xb198695a0> F8BB1C28-BAE8-11D6-9C31-00039315CD46
[HLSSegmentProducer] seg-5.m4s captured (14628371 B)
[HLSSegmentProducer] seg-6.m4s captured (16077859 B)
      HALC_ShellObject.mm:594    HALC_ShellObject::SetPropertyData: call to the proxy failed, Error: 1852797029 (nope)
[HLSSegmentProducer] seg-7.m4s captured (2096766 B)
[HLSSegmentProducer] pump finished: packetsRead=2018 packetsWritten=723 lastError=0 elapsed=215ms cacheCount=8
[NativeAVPlayerHost] #1 asset.load(isPlayable) ok url=http://127.0.0.1:50054/media.m3u8 value=true
<<< timebase >>> signalled err=-12753 at <>:3981
<<<< FigStreamPlayer >>>> signalled err=-12783 at <>:63418
<<<< FigStreamPlayer >>>> signalled err=-12860 at <>:29920
[NativeAVPlayerHost] #1 asset.load(tracks) ok url=http://127.0.0.1:50054/media.m3u8 count=0
<<<< FigStreamPlayer >>>> signalled err=-12860 at <>:29920
<<<< FigStreamPlayer >>>> signalled err=-12860 at <>:29920
[NativeAVPlayerHost] #1 timeControlStatus=waitingToPlay reason=AVPlayerWaitingWithNoItemToPlayReason
[NativeAVPlayerHost] #1 timeControlStatus=waitingToPlay reason=AVPlayerWaitingToMinimizeStallsReason
[HLSLocalServer] conn opened fd=13
[HLSLocalServer] GET /media.m3u8 HTTP/1.1
[HLSLocalServer] first request headers fd=13: Host: 127.0.0.1:50054 | X-Playback-Session-Id: 358F3606-1F6D-4AB0-8C2A-60032192D1CE | Accept: */* | User-Agent: AppleCoreMedia/1.0.0.25F71 (Macintosh; U; Intel Mac OS X 26_5; en_us) | Accept-Language: en-US,en;q=0.9 | Accept-Encoding: gzip | Connection: keep-alive
[HLSLocalServer] media.m3u8 head:
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:5
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="init.mp4"
#EXTINF:4.000,
seg0.mp4
[HLSLocalServer] media.m3u8 tail:
#EXTINF:4.000,
seg6.mp4
#EXTINF:1.125,
seg7.mp4
#EXT-X-ENDLIST
[HLSLocalServer] -> 200 /media.m3u8 bytes=331 type=application/vnd.apple.mpegurl
<<HLS-FASB>> signalled err=-15514 at <>:1053
[HLSLocalServer] conn opened fd=15
[HLSLocalServer] GET /init.mp4 HTTP/1.1
[HLSLocalServer] -> 200 /init.mp4 bytes=1372 type=video/mp4
[HLSLocalServer] GET /media.m3u8 HTTP/1.1
[HLSLocalServer] -> 200 /media.m3u8 bytes=331 type=application/vnd.apple.mpegurl
<<<< HEVCBridge >>>> signalled err=-12712 at <>:10330
<<< timebase >>> signalled err=-12753 at <>:3981
[NativeAVPlayerHost] #1 accessLog uri=http://127.0.0.1:50054/media.m3u8 server=127.0.0.1 bytes=1372 reqs=0
[NativeAVPlayerHost] #1 asset.load(duration) ok url=http://127.0.0.1:50054/media.m3u8 seconds=30.125
[HLSLocalServer] GET /seg0.mp4 HTTP/1.1
[HLSLocalServer] -> 200 /seg0.mp4 bytes=7643902 type=video/mp4 [sendfile]
<<<< VTVideoDecoderSelection >>>> signalled err=-12906 at <>:4702
<<<< VT-DS >>>> signalled err=-4 at <>:2627
[NativeAVPlayerHost] #1 item.status=failed err=CoreMediaErrorDomain/-4 'The operation couldn’t be completed. (CoreMediaErrorDomain error -4.)'
[NativeAVPlayerHost] #1 asset.url=http://127.0.0.1:50054/media.m3u8 (item.failed)
[NativeAVPlayerHost] #1 asset.tracks empty (item.failed)
[NativeAVPlayerHost] #1 errorLog dump: <nil>
[NativeAVPlayerHost] #1 accessLog dump: 0 events
[NativeAVPlayerHost] #1 item.tracks count=2
[NativeAVPlayerHost] #1   item.tracks[0] mediaType=vide fourCC=<no fdesc> enabled=false
[NativeAVPlayerHost] #1   item.tracks[1] mediaType=soun fourCC=<no fdesc> enabled=false
[NativeAVPlayerHost] #1 item.presentationSize=(0.0, 0.0)
[NativeAVPlayerHost] #1 item.seekableTimeRanges.count=1
[NativeAVPlayerHost] #1 item.loadedTimeRanges.count=0
[NativeAVPlayerHost] #1 item.canPlayFastForward=false canPlayFastReverse=false canStepForward=false
[NativeAVPlayerHost] #1 item.duration=30.12
[NativeAVPlayerHost] #1 item.appliesPerFrameHDRDisplayMetadata=true
[NativeAVPlayerHost] #1 rate=0.0
[NativeAVPlayerHost] #1 timeControlStatus=paused reason=-

[strangeliu]

Confirmed the root cause from the Dropbox sample.

The MP4 has dvh1 + a well-formed dvcC (P5 L6 compat_id=0), but the HEVC SPS VUI transfer / primaries / matrix are all unspecified and there's no colr atom on the sample entry. FFmpeg's mp4 demuxer reports color_transfer=unknown for that source. The engine was stream-copying through to its output fMP4 without filling in the gap, so AVPlayer saw a dvh1 sample entry with no explicit PQ signal and refused to engage the DV decoder.

The MKV variant works because matroska's Colour element populates codecpar.color_* directly, which FFmpeg's mp4 muxer then writes as a colr nclx atom. The mp4 demuxer has no equivalent inference.

Fixed in af8cafd: when dvVariant == .profile5, force the canonical P5 color tuple (BT.2020 primaries, PQ transfer, BT.2020-NCL matrix, limited range) on the muxer's stream codecpar before avformat_write_header. P5 is defined as IPT-PQ-c2, so the dvcC record alone implies that signaling, which makes the override safe (no risk of mislabeling a non-PQ source).

@strangeliu please pull the latest main and re-test. @DrHurt thanks for the comparison framing, the broken-vs-reference angle made the missing PQ signal jump out quickly.

Still unable to play using the latest commit (commit hash: af8cafd)

[superuser404notfound]

Please download the new dmg from the 2.0.1 release page and test again.

[strangeliu]

not working. item.status=failed err=CoreMediaErrorDomain/-4 'The operation couldn’t be completed. (CoreMediaErrorDomain error -4.)'

default	17:11:33.850982+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 load url=http://127.0.0.1:52868/media.m3u8 startPos=nil
default	17:11:33.852487+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 timeControlStatus=paused reason=-
default	17:11:33.853378+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 rate=1.0
default	17:11:33.853450+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 timeControlStatus=waitingToPlay reason=AVPlayerWaitingWhileEvaluatingBufferingRateReason
default	17:11:33.853770+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 rate=1.0
default	17:11:33.853833+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 timeControlStatus=waitingToPlay reason=AVPlayerWaitingWhileEvaluatingBufferingRateReason
default	17:11:33.859040+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 asset.load(isPlayable) ok url=http://127.0.0.1:52868/media.m3u8 value=true
default	17:11:33.865205+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 asset.load(tracks) ok url=http://127.0.0.1:52868/media.m3u8 count=0
default	17:11:33.866647+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 timeControlStatus=waitingToPlay reason=AVPlayerWaitingWithNoItemToPlayReason
default	17:11:33.866728+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 timeControlStatus=waitingToPlay reason=AVPlayerWaitingToMinimizeStallsReason
default	17:11:33.869841+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 asset.load(duration) ok url=http://127.0.0.1:52868/media.m3u8 seconds=30.125
default	17:11:33.876677+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 accessLog uri=http://127.0.0.1:52868/media.m3u8 server=127.0.0.1 bytes=1391 reqs=0
default	17:11:33.892832+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 item.status=failed err=CoreMediaErrorDomain/-4 'The operation couldn’t be completed. (CoreMediaErrorDomain error -4.)'
default	17:11:33.892864+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 asset.url=http://127.0.0.1:52868/media.m3u8 (item.failed)
default	17:11:33.892874+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 asset.tracks empty (item.failed)
default	17:11:33.892894+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 errorLog dump: <nil>
default	17:11:33.892923+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 accessLog dump: 0 events
default	17:11:33.892932+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 item.tracks count=2
default	17:11:33.892985+0800	DemoPlayerMac	[NativeAVPlayerHost] #3   item.tracks[0] mediaType=vide fourCC=<no fdesc> enabled=false
default	17:11:33.893021+0800	DemoPlayerMac	[NativeAVPlayerHost] #3   item.tracks[1] mediaType=soun fourCC=<no fdesc> enabled=false
default	17:11:33.893035+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 item.presentationSize=(0.0, 0.0)
default	17:11:33.893042+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 item.seekableTimeRanges.count=1
default	17:11:33.893047+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 item.loadedTimeRanges.count=0
default	17:11:33.893054+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 item.canPlayFastForward=false canPlayFastReverse=false canStepForward=false
default	17:11:33.893074+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 item.duration=30.12
default	17:11:33.893079+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 item.appliesPerFrameHDRDisplayMetadata=true
default	17:11:33.893192+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 rate=0.0
default	17:11:33.893276+0800	DemoPlayerMac	[NativeAVPlayerHost] #3 timeControlStatus=paused reason=-

[superuser404notfound]

The 2.0.1 colr fix was necessary but not sufficient. Reproduced your symptom locally with the Dropbox sample and found the second-layer cause: the source MP4's hvcC carries only the 22-byte configuration header (numOfArrays = 0) and ships VPS / SPS / PPS in-band on every IRAP packet. AVPlayer cannot build a CMVideoFormatDescription from a dvh1 sample entry whose configuration record has no parameter set arrays, which is exactly the item.tracks[*].fourCC=<no fdesc> + CoreMediaErrorDomain -4 you saw. The matroska demuxer dodges this because matroska parameter sets live in CodecPrivate, which FFmpeg lifts into codecpar.extradata as a complete annex-B sequence that the mp4 muxer's ff_isom_write_hvcc then rebuilds properly.

Fixed in ed0e6af, released as 2.0.2 (release): the engine scans the first IRAP packet for VPS / SPS / PPS NAL units, builds a proper hvcC, and replaces the output stream's codecpar.extradata before avformat_write_header. Gated on the precise signal (HEVC, extradata ≥ 23 B with byte 22 = 0, NALU length size 4); other inputs fall through to the existing stream-copy path.

Verified locally against your sample:

• aetherctl serve loopback playback advances in QuickTime / AVPlayer past 9 s and runs to completion.
• init.mp4 has all four expected boxes: dvh1 + hvcC (125 B with parameter sets) + colr nclx 9/16/9 + dvcC P5 L6 compat_id=0.
• Colors render correctly (IPT-PQ-c2 → tonemapped, no green/purple cast).

@strangeliu the 2.0.2 DMG will appear on the release page in a couple of minutes when the notarization workflow finishes. Please retest and let me know.