The H.264 CODECS attribute states the profile the source declares - #439
Merged
Merged
Conversation
…rce declares The master's CODECS entry was built as `String(format: "avc1.%02X%02X%02X", codecpar.profile, 0, codecpar.level)`, and `AVCodecParameters.profile` is not a bare profile_idc: libavcodec ORs the constraint flags into the high bits, so Constrained Baseline arrives as `66|AV_PROFILE_H264_CONSTRAINED` = 578 and the Intra profiles as `idc|AV_PROFILE_H264_INTRA`. `%02X` is a minimum width, not a maximum, so 578 printed as three digits and the attribute came out `avc1.2420028`: seven hex digits where RFC 6381 defines exactly six. Measured on a Constrained Baseline 1080p23.976 fixture through `aetherctl serve --native-subs`. Constrained High and High 10 / 4:2:2 / 4:4:4 Intra overflow the same way; Main and High carry no flags, which is why remuxes never showed it. The hardcoded middle byte was the second half: profile_compatibility carries the constraint_set flags, and declaring zero for every source contradicted the sample entry the muxer writes from the same extradata. Both come from the source now, in the form it carries them: the avcC states all three bytes (bytes 1..3), an MPEG-TS stream states them in the first three bytes of its SPS, and only a source with neither falls back to the codecpar fields, masked and with the two flags libavcodec preserved mapped back into the compatibility byte. That is the same shape `plainHEVCCodecs` already had, and deriving the attribute from the extradata the muxer stream-copies is what keeps the manifest and the init from disagreeing by construction. Scope: only the manifest attribute changes, no segment or init byte moves, and only on the master route (a media-direct session declares no CODECS at all). Sources whose profile carries no constraint flags are byte-identical before and after, verified side by side on the same fixtures: High stayed `avc1.640028` while Constrained Baseline went `avc1.2420028` -> `avc1.42C028`. Not claimed: that the malformed string broke playback. macOS AVFoundation accepted both spellings in an A/B on identical media, so this is a spec violation whose consequence on tvOS is untested. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WbciAqCSxpaiUpTumrCuA9
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.
The master's CODECS entry was built as
String(format: "avc1.%02X%02X%02X", codecpar.profile, 0, codecpar.level).AVCodecParameters.profileis not a bare profile_idc: libavcodec ORs the constraint flags into the high bits, so Constrained Baseline arrives as66|AV_PROFILE_H264_CONSTRAINED= 578.%02Xis a minimum width, so that printed as three digits and the attribute came outavc1.2420028, seven hex digits where RFC 6381 defines exactly six. Constrained High and the High 10 / 4:2:2 / 4:4:4 Intra profiles overflow the same way; Main and High carry no flags, which is why remuxes never showed it.The hardcoded middle byte was the other half: profile_compatibility carries the constraint_set flags, and declaring zero contradicted the sample entry the muxer writes from the same extradata.
Both now come from the source in whatever form it carries them: the avcC states all three bytes, an MPEG-TS stream states them in the first three bytes of its SPS, and only a source with neither falls back to the codecpar fields, masked, with the two preserved flags mapped back into the compatibility byte. Same shape
plainHEVCCodecsalready had.Verification
swift test: 2175 tests in 305 suites pass. 16 new tests inAVCCodecStringTests, written first and watched fail on the value (route.primaryCodecs -> "avc1.2420028"), including a shape assertion across all 13 H.264 profiles.aetherctl serve --native-subs, two binaries side by side on the same fixtures: High stayedavc1.640028byte-identical, Constrained Baseline wentavc1.2420028->avc1.42C028.Scope
Only the manifest attribute changes. No segment or init byte moves, and only the master route is affected (a media-direct session declares no CODECS at all).
Not claimed: that the malformed string broke playback. macOS AVFoundation accepted both spellings in an A/B on identical media, so this is a spec violation whose consequence on tvOS is untested. The Annex-B/SPS branch is unit-tested against real
AVCodecParameters, not end to end.🤖 Generated with Claude Code
https://claude.ai/code/session_01WbciAqCSxpaiUpTumrCuA9