AetherEngine 5.18.7

AetherEngine 5.18.7

Fixed

HEVC-in-MP4 VOD now plays on Apple TV instead of failing to build a video track (#187).

Two device-only causes, both in the loopback's playlist routing rather than the muxer:

• HEVC needs codec signaling in a master playlist on tvOS. Apple TV's hardware builds an H.264 track from a bare media playlist plus init, but for HEVC it needs the codec advertised in a master's EXT-X-STREAM-INF CODECS attribute, or the item fails with tracks count=0 / -11829 / -12848 before any media fetch. macOS and the Simulator build the HEVC track straight from the init hvcC on the media-direct path, which is why neither reproduced it. The loopback now serves HEVC through a master where routing-safe (iOS and macOS keep the media-direct path, which already works for them).

• The plain-HEVC CODECS string is now derived from the actual bitstream. It was hardcoded to hvc1.2.4.L<level> (Main10) for every HEVC stream, mis-declaring an 8-bit Main source as Main10. Once HEVC is signaled through a master, a strict device rejects that Main10 claim against the Main hvcC in the init. The engine now derives the RFC 6381 string from the hvcC profile_tier_level (matching GPAC / ffmpeg, e.g. hvc1.1.6.L93.90), so the manifest and the init agree.

Defensive strip of a zero-sample sdtp box from the fragmented init.

The pinned FFmpeg (8.x) never writes this box: its movenc zeroes track->entry before the sample table under empty_moov. But a consumer that links an older FFmpeg the wrong way, for example a -force_loaded framework whose movenc shadows the vendored build, emits an sdtp describing zero samples into the init. Apple TV rejects that init while macOS and the Simulator tolerate it. The engine now strips a zero-sample sdtp from the video sample table of the captured init regardless of which FFmpeg produced the bytes, so a mislinked integration can't resurface the rejection.

Acknowledgements

Reported and device-verified on an Apple TV 4K by @kskchaitanya1993, whose byte-level init.mp4 capture off the loopback and nm on the vendored archive pinned the FFmpeg-version mislink as the root cause. Thank you.