关于Matroska/WebM中AV1视频帧数据格式的技术疑问
Great question—this confusion boils down to a key split between container ecosystems, and how each was optimized to work with AV1's native design. Let’s break this down clearly:
Core Reason for the Discrepancy
ISOBMFF (the standard behind MP4/MOV) and Matroska/WebM are entirely separate container specifications, each with their own rules for packaging media data. The AV1 ISOBMFF document you looked at is specifically built for ISOBMFF-based containers—it never was intended to apply to WebM or MKV.
Unlike H.264/H.265, which ended up with similar length-prefixed NAL unit wrapping across multiple containers (including MKV), AV1 was designed from the start to support different container paradigms. WebM/MKV took advantage of AV1's built-in structure to skip redundant formatting steps.
How AV1 Is Actually Stored in WebM/MKV
Instead of using the ISOBMFF-style "length prefix + NAL unit" structure, WebM/MKV directly stores AV1's native OBU (Octet Buffer Unit) sequences. Here’s what that looks like in practice:
- Each OBU includes its own header with critical metadata: OBU type, length, and temporal layer information. This removes the need for an external length prefix (like the one in ISOBMFF's AV1 samples) because the OBU itself tells decoders exactly how big it is.
- The packaging follows the Matroska AV1 Specification (for MKV) and WebM's extension of this standard. These specs mandate that AV1 data is written as a continuous stream of OBUs, with decoders relying entirely on the OBU headers to parse individual units.
To contrast with ISOBMFF: ISOBMFF wraps AV1 OBUs into NAL units (adding a length prefix) because its sample-based model requires explicit boundaries between units. WebM/MKV's more flexible stream-based model can leverage the OBU's native headers directly, making the extra prefix unnecessary.
内容的提问来源于stack exchange,提问作者ravin.wang

