I-D list for Codec Encoding for LossLess Archiving and Realtime transmission RSS Feed

Matroska Media Container Tag Specifications

2026-08-13T20:11:59.927734+00:00

RPC status changed to Awaiting First editor from Awaiting Editor Assignment

Matroska Media Container Codec Specifications

2026-08-06T16:09:30.562683+00:00

Changed action holders to Steve Lhomme, Moritz Bunkus, Dave Rice (IESG state changed)

Matroska Media Container Codec Specifications

2026-08-06T16:09:30.505001+00:00

IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation

Matroska Media Container Codec Specifications

2026-08-06T07:04:33.356779+00:00

[Ballot comment]
I support Roman's DISCUSS and would like to understand how consensus was achieved/declared.

To assist the reader, please correct these references between sections: Section 3.5.3 defines presentation graphics subtitles and should therefore refer to Section 5.5 (instead of 5.6), and Section 3.5.4 defines text subtitles and should therefore refer to Section 5.6 on text subtitles (instead of 5.5).

Matroska Media Container Codec Specifications

2026-08-06T07:04:33.356715+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Tommy Jensen

Matroska Media Container Codec Specifications

2026-08-05T23:53:40.574037+00:00

[Ballot comment]
Section 3.3.25, V_THEORA CodecPrivate layout:

767 > * Bytes 2..n: lengths of the first #p packets, coded in Xiph-style
768 > lacing. The length of the last packet is the length of the
769 > CodecPrivate block minus the lengths coded in these bytes minus
770 > one.

The same text appears verbatim in Section 3.4.41 (A_VORBIS), lines
1405-1408. On Éric's DISCUSS: I checked, and RFC 9559 already defines this
exact mechanism under its own name.

> Xiph Lacing: This approach uses a series of size values to delimit
> frames. The final frame's size is calculated by subtracting the sum
> of preceding frame sizes from the total remaining data, eliminating
> the need to explicitly store the last frame's dimensions.

That's Section 10.3 of RFC 9559, "Block Lacing." So the fix really is
trivial: add "; see Section 10.3 of [RFC9559]" (or similar) at both of the
two places above, and RFC9559 moves from an informative to a normative
reference.

---

Section 8.1, Table 4, "Matroska Codec IDs" registry:

3212 > | S_SSA | 17 | SubStation Alpha | Reclaimed, |
3213 > | | | Format | Section 3.5.7 |

This points readers to Section 3.5.7, which is S_TEXT/ASS. But the
Codec ID S_SSA is actually discussed in Section 3.5.9 (S_TEXT/SSA):

1571 > The codec MAY also be found with the Codec ID S_SSA, but using that
1572 > value is NOT RECOMMENDED.

s/Section 3.5.7/Section 3.5.9/

---

Section 3.2, recommendations for new Codec Mappings:

384 > These recommendations are based on Section 3 of [RFC6648].

RFC 6648 Section 3 actually says SHOULD NOT for the "X-" prefix, not MUST
NOT. Elevating it to MUST NOT here is a reasonable editorial choice for a
registry-governed identifier space, but the text presents it as directly
"based on" RFC 6648 without noting that it's strengthening the
recommendation. A short note to that effect would avoid a reader assuming
RFC 6648 itself mandates this.

---------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 9.1, [ITU-T.H.262] normative reference:

3427 > [ITU-T.H.262]
3428 > ITU-T, "Procedure for the allocation of ITU-T defined
3429 > codes for non-standard facilities", ITU-T
3430 > Recommendation H.262, July 1995,
3431 > .

That title is word-for-word the title given later in the document for
[ITU-T.35] (Informative References) — it's the wrong title. The actual
title of ITU-T Recommendation H.262 is "Information technology - Generic
coding of moving pictures and associated audio information: Video" (the
joint ISO/IEC 13818-2 MPEG-2 video spec, which is what Section 3.3.12
actually needs).

s/Procedure for the allocation of ITU-T defined codes for non-standard facilities/Information technology - Generic coding of moving pictures and associated audio information: Video/

---

Section 9.1, [ISO.11172-3] normative reference:

3403 > [ISO.11172-3]
3404 > International Organization for Standardization,
3405 > "Information technology - Coding of moving pictures and
3406 > associated audio for digital storage median at up to about
3407 > 1,5 Mbit/s - Part 3: Audio", ISO 11172-2:1993, August
3408 > 1993.

The title says "Part 3: Audio" but the document number given is
11172-2, which is Part 2 (Video) — already cited two entries above for
[ISO.11172-2]. The correct number for the audio part is ISO/IEC
11172-3:1993.

s/ISO 11172-2:1993/ISO\/IEC 11172-3:1993/

---

Section 3.4.11, A_AC3 description:

995 > Section 4.4.2.1 of [ETSI.TS102-366] is 10 or below. Channel number
996 > have to be read from the corresponding audio element

s/Channel number have to be read from the corresponding audio element/The channel number has to be read from the corresponding audio element./

---

Section 3.3.9, V_MPEGH/ISO/HEVC field layout:

526 > Codec Name: HEVC/H.265
527 > Description: Individual pictures (which could be a frame, a field, or

Every other codec entry has a blank line between fields (Codec ID / Codec
Name / Description / Initialization). This one runs Codec Name straight
into Description with no blank line. The same thing happens in Section
3.3.13 (V_MPEG4/ISO/AVC), 3.3.28 (V_VP8), and 3.5.3 (S_HDMV/PGS). Cosmetic,
but easy to fix in one pass.

Matroska Media Container Codec Specifications

2026-08-05T23:53:40.573972+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani

Matroska Media Container Codec Specifications

2026-08-05T19:47:30.926719+00:00

[Ballot comment]
I support Kentan's discuss on IANA registry guidance.

Matroska Media Container Codec Specifications

2026-08-05T19:47:30.926643+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Christopher Inacio

Matroska Media Container Codec Specifications

2026-08-05T08:26:52.279661+00:00

[Ballot comment]
Thanks for this work.

I support Ketan's DISCUSS on IANA registries to need stronger rules.

a small, but relevant, typo is that WAVEFORMATEX integer signed/unsigned is wrong.

Section 3.4.25 says:
"A WORD corresponds to a signed 2 octets integer, DWORD corresponds to a signed 4 octets integer."

Microsoft defines WORD as an unsigned 16-bit integer and DWORD as an unsigned 32-bit integer. Please change both to unsigned. See https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types.

Matroska Media Container Codec Specifications

2026-08-05T08:26:52.279601+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde

Matroska Media Container Codec Specifications

2026-08-04T22:53:49+00:00

IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed

Matroska Media Container Codec Specifications

2026-08-04T14:08:23.454660+00:00

[Ballot comment]
I support Ketan's DISCUSS on the need for instructions for the DEs.

Matroska Media Container Codec Specifications

2026-08-04T14:08:23.454597+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Andy Newton

Matroska Media Container Codec Specifications

2026-07-31T20:42:02.611140+00:00

[Ballot discuss]
** Sections 3.1.6 and 8.1

-- Section 3.1.6, “Citation, Documentation of the associated normative and informative references for the codec is RECOMMENDED.”

-- Section 8.1, “To register a new Codec ID in this registry, one needs a Codec ID
string, … and an optional Reference to a document describing the Codec ID”.

How is interoperability ensured if the code point for a given Codec ID has no associated reference for the implementer to use? Should the registration policy be “Specification Required”?

** For the responsible AD/WG Chairs – could the consensus to publish this document please be checked (and as appropriate, documented). What I found in the record was:

26-August-2026 – Interim meeting, https://datatracker.ietf.org/doc/minutes-interim-2025-cellar-08-202508261900/, one WG participant on the call who wasn’t the WG chair or a document author. No call for consensus on the call

26-August-2026 – WGLC Started on the Mailing List, https://mailarchive.ietf.org/arch/msg/cellar/gDR-EVk6j-IABAJGceMLv7qX47Q/. There were no responses to this WGLC.

23-September-2026 – Interim meeting, https://datatracker.ietf.org/doc/minutes-interim-2025-cellar-09-202509231900/, following the WGLC with the same situation as the 26-August meeting (one WG participant who wasn’t the WG chair or a document author. No documented instance of trying to establish consensus)

14-October-2026 – WGLC closed, consensus called, https://mailarchive.ietf.org/arch/msg/cellar/wyKO4yLu4ZuSidsmq2LF7wESYak/

Matroska Media Container Codec Specifications

2026-07-31T20:42:02.611120+00:00

[Ballot comment]
Thank you to Mallory Knodel for the GENART review.

I support the DISCUSS positions of Éric Vyncke and Ketan Talaulikar.

** Section 3. What is the expected behavior of an implementation when encountering a CodecID that is not registered?

** Section 3.5.13. The reference for VobSub files appears to be to

[VobSub] MultimediaWiki, "VOBSub", 21 March 2007,
.

However, that page provides an example, not a specification for the format. This wiki page references a SourceForge project, https://sourceforge.net/projects/guliverkli/files/? Is that the reference? Where in the code repository is the format? Is there a better reference?

** Sections 4.1.1.1, 4.1.1.2, 4.1.2.2. These sections appear to use a formal notation. Please cite the format. Perhaps the reference should be to C99?

** Sections 5. This entire section appears to be verbatim (cut-and-paste) from https://www.matroska.org/technical/subtitles.html. I don’t know the pedigree of the text but consider if some kind of acknowledgement of citation is needed in this document.

** Section 5.1. I was unable to access this site (or even resolve the DNS name):
DVD Forum, "DVD-Books: Part 3 DVD-Video Book", November
1995, .

** Section 5.3. Editorial. Consider revising the colloquial framing of the text following “Now, how are they stored in Matroska?” to be more consistent with the rest of the text.

Matroska Media Container Codec Specifications

2026-07-31T20:42:02.611055+00:00

[Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw