CELLAR -- Feb 24 1800 UTC

Meetecho session

Agenda / Notes

Please share video when possible. Remember that the session is being
recorded and will appear at YouTube.

Tip: press “Expand all” in the navigation menu

👥 Participants (please add yourself as you join)

• Spencer Dawkins
• Robert Sparks
• Steve Lhomme
• Jérôme Martinez
• Dave Rice
• Michael Niedermayer

Regrets:

📣 Note Well

https://www.ietf.org/about/note-well/
Please be KIND to each other.

👀 Previous meeting minutes

• Are any corrections needed to the previous meeting minutes?
• No objections on the call, so approved.

🗣️ Working Group Documents

See https://datatracker.ietf.org/group/cellar/documents/

draft-ietf-cellar-tags

• draft-ietf-cellar-tags-22 has been submitted
• Action: Steve and Spencer will go through the IANA section
  looking at normative language.
• Action: Spencer to close with ADs (and with IANA) to make sure
  we have addressed all DISCUSSes and COMMENTs, and then this draft
  will be approved

draft-ietf-cellar-codec

• We have our AD Evaluation for -16 on the mailing list
• Steve has submitted -17, which Orie says addressed his AD Evaluation
  comments
• • Action: Spencer will nudge Orie to move -17 forward before
    IETF 125, so Orie can schedule IETF Last Call while he is still
    our AD.

• Action: Spencer to confirm with Stephan Wegner that the IESG and
  reviewers can get copies of specifications for references in this
  draft (ISO and ITU-T)

draft-ietf-cellar-chapter-codecs

What we said at a previous meeting

• draft-ietf-cellar-chapter-codecs-05 is Expired, but we said we were
  waiting to return to this draft
• Still correct? Yes, we can return to this in 2026

draft-ietf-cellar-ffv1-v4

What we said at a previous meeting

• draft-ietf-cellar-ffv1-v4-22 is Expired - time to submit an update?
• Jérôme has time to work on this in 2026
• Need to resynchronize with implementations
• Need to address ffmpeg ffv1-v4 questions and work on performance
  improvements
• We are working on hardware acceleration for ffv1-v3, and want to
  bring that forward

🔥 Hot Topics

Mailing list question about draft-swhited-ogg-stems/

• Is this draft/technology in scope for CELLAR? It's really a request
  for a Matroska profile
• What standardization is actually needed?
• We have already started mailing list discussion with Sam Whited (the
  draft-swhited-ogg-stems/ author). We'll have more discussion,
  and will figure out whether anything needs to be updated in our
  working group specifications, and whether anything must be written
  down in order to achieve interoperability

Starting on an Internet-Draft for matroska v5

What we said at a previous meeting

• The Github version of what will become -00 is here
• We do want to make it easier for newcomers to figure out what
  specification/version they need to look at in Github

On this call

• If we don't call this document v5, what DO we call it? (this would
  be both file name and title change)
• Would we rather split the document out, for each new capability or
  group of capabilies?
• The pace of changes is also relevant here.
• We can say "Matroska extensions as of 2027", etc. but if there are
  obvious subsets, that would be better
• We still need to think about the details here, but we think we can
  explain specific subsets

Discussion about our charter to support v5

What we said at a previous meeting

• Why does this need to be v5? We don't really use version numbers
  at the protocol level (Matroska does backwards compatibility)
• Matroska does backwards-compatibility, so Matroska version numbers
  don't mean what version numbers mean in many protocols at the IETF
• We haven't been using Matroska extension documents for very long -
  before, there was one big document that defined Matroska v2, etc.
• v5 really is more of a feature set than a version number
• We do need to make a decision about whether we would make changes
  that are NOT backward-compatible in v5.
• Robert will look for similar uses of XML container versioning with
  other groups
• Robert also needs a strong motivation for why IETF is the right
  place to do a Matroska v5
• Martijn pointed out that rechartering would also provide a home for
  any FLAC extensions

On this call

• We don't think we need to have a protocol identifier for Matroska,
  so we don't think we need to recharter in order to work on new
  capabilities in Matroska - at least not yet
• We are going to have a new charter, the question is whether version
  numbers are part of that new charter
• We (might) write extension documents, but leave the base Matroska
  specification alone
• The only breaking change we've identified is a new timestamp format.
  It could be backward-compatible, and then we wouldn't need two
  versions (and otherwise, we do).
• Is there specification work for us to do, on the new timestamp
  format? PR 422
• Action: Robert to socialize our understanding of versioning with
  the IESG at IETF 125

Any Other Business?

None noted on the call

Next meeting dates

| Meeting | Date |
|----------
| interim-2026-cellar-03 | 2026-04-28 |
| interim-2026-cellar-04 | 2026-05-26 |
| interim-2026-cellar-05 | 2026-06-23 |
| interim-2026-cellar-06 | 2026-08-25 |
| interim-2026-cellar-07 | 2026-09-22 |
| interim-2026-cellar-08 | 2026-10-27 |
| interim-2026-cellar-09 | 2026-12-08 |