Function av1_codec_string 

pub fn av1_codec_string(h: &Av1SequenceHeader) -> String

AV1 codec string — av01.P.LLT.DD.M.CCC.TTT.MMM.F.

Per the AV1 ISOBMFF binding §A.3:

• P = seq_profile (decimal, 1 char). Profile 0 (Main) is by far the most common; 1 (High) and 2 (Professional) are rare.
• LL = seq_level_idx_0 formatted as 2-digit decimal (00..31).
• T = seq_tier_0 mapped to ‘M’ (Main, 0) or ‘H’ (High, 1). Tier is only signaled in the bitstream for levels >= 4.0 (level_idx > 7); the parser implicitly sets it to 0 below that.
• DD = bit depth as 2-digit decimal (08, 10, or 12).
• M = monochrome flag (0 or 1).
• CCC.TTT.MMM = color_primaries, transfer_characteristics, matrix_coefficients formatted as 3-digit zero-padded decimals. H.273 codes 1/1/1 = BT.709, 9/16/9 = BT.2020 PQ (HDR10), 9/18/9 = BT.2020 HLG, etc.
• F = color_range flag (0 = limited / studio, 1 = full).

Per spec, the optional tail (.M.CCC.TTT.MMM.F) MAY be omitted when ALL of these are at their defaults (M=0, CCC=001, TTT=001, MMM=001, F=0 — i.e. SDR BT.709 limited). We emit the SHORT form when at defaults and the LONG form otherwise.

The original posture was “always emit long for explicit identification”, but that broke playback in the browser MSE path: some hls.js / Chrome / Edge versions reject the long form via MediaSource.isTypeSupported('video/mp4; codecs="av01.0.05M.08.0.001.001.001.0"') even though the underlying av1C bitstream is byte-identical to what the same browser plays via direct rendition load (which internally generates the short form by inferring codec from init.mp4 — bypassing the long-form attribute path). Switching the master playlist to short-form when at defaults makes the same segments decode consistently across native HLS, hls.js, and Safari.

The HDR / wide-gamut / monochrome / non-default-range case still emits the full 9-component form — those values are NOT defaults and short form would mean “BT.709 limited 8-bit” which is wrong.