| Date | Time | Local Times | |
| :-: :-: :- -
| 2025-04-08 | 21:00 Amsterdam | Time Converter | |
| Note | Meeting time is anchored to Amsterdam | | |
https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2025-04
Note that we're now pointing to the Github repo for chair notes here
MEETING INFO and WEB CONFERENCE:
https://datatracker.ietf.org/meeting/interim-2025-cellar-02/session/cellar
https://meetings.conf.meetecho.com/interim/?group=3b846309-092f-4d0f-b97a-4e2d241302e5
note that chat is now Zulip:
https://zulip.ietf.org/login/#narrow/stream/cellar
but is also accessible via meetecho interface.
Now using the Datatracker assigned notepad at:
https://notes.ietf.org/notes-ietf-interim-2025-cellar-04-cellar
Note that if you log in to the IETF datatracker, you'll be able to
edit/clarify/correct these notes, add your name to attendee lists, etc.
Please ask Spencer or Robert if you have questions.
Future 2025 dates listed at
https://datatracker.ietf.org/wg/cellar/meetings/
Attendees
Regrets:
Accept draft minutes from previous meeting
MINUTES ARE AT:
https://datatracker.ietf.org/doc/minutes-interim-2025-cellar-02-202502252000/
https://www.ietf.org/about/note-well/
Please be KIND to each other.
Spencer and Robert have (sort of) an answer from IANA, in private email.
If this is in Matroska v5, that can do the registration (it's an IETF
stream standards track document).
If we want to register the deprecated alias, that goes through Expert
Review and IESG approval.
Ordinarily, we would not use the Errata process to add to an IANA
registry, but the deprecated media types aren't in a registry today ...
(so should we add ALL of the deprecated media types to a new registry?)
Action Robert to confirm what actions need to be taken for other
deprecated media types in RFC 9559 with Steve in email
Action Robert can confer with people in person, in Bangkok to
confirm the necessary process with our AD (Orie Steele) once we pick a
plan.
Our current working group document status is
| Draft | State | Date Posted | Plans |
|:------|:------|:------------|:------|
| draft-ietf-cellar-codec-14 | ID-exists | 2024-12-15 | |
| draft-ietf-cellar-tags-15 | ID-Exists | 2024-11-24 | |
| draft-ietf-cellar-chapter-codecs-05 | ID-Exists | 2024-08-27 | |
| draft-ietf-cellar-ffv1-v4-22 | expired | 2024-01-17 | |
Issues are here, PRs are here.
At our previous meeting we said:
need to add tag for latest EBU recommendations, but we don't have
all the information we need to describe the tag yet
https://tech.ebu.ch/publications/r128/Jerome will check with the right person (bb010g on GitHub
regarding
https://github.com/ietf-wg-cellar/matroska-specification/pull/865)
We have one open PR left on floating point - Steve will review as soon
as possible.
Action: Spencer will initiate Working Group Last Call for tags-16
(with corrections from -15)
Issues are here, PRs are here.
Spencer has reviewed CODEC-14, and Steve has gone through Spencer's
comments and created PRs where necessary. Most of Spencer's comments
have already been addressed.
3.3.1. V_AV1
...
Description: Only one Sequence Header OBU, as defined in section 6.4
of [AV1], is supported per Matroska Segment. Each Block contains one
Temporal Unit containing one or more OBUs. Each OBU stored in the
Block MUST contain its header and its payload. The OBUs in the Block
follow the Low Overhead Bitstream Format syntax. They MUST have the
obu_has_size_field set to 1 except for the last OBU in the frame,
for
which obu_has_size_field MAY be set to 0, in which case it is
assumed
to fill the remainder of the frame.
Spencer: I am guessing how this works, and probably guessing wrong. If
the last OBU in the frame also has obu_has_size_field set to 1, what
does that mean to a Matroska decoder? I'm guessing obu_has_size_field
set to 0 means that this is the last OBU in the frame, but having this
as a MAY means that the decoder can't rely on that.
I actually don’t know if AV1 encoders/decoders rely on that at all. A
player should not rely on that as you never know if a file has been cut
or not. IIRC this was a rule copied from the ISOBMFF spec.
ACTION: Spencer to contact an AV1 wizard to clarify this - does that
make sense?
3.3.6. V_FFV1
...
Initialization: For FFV1 versions 0 or 1, CodecPrivate SHOULD NOT be
written.
Spencer: but if CodecPrivate IS written, what does a Matroska decoder do
with that? I'm guessing this would be better as
Initialization: For FFV1 versions 0 or 1, CodecPrivate MUST be ignored.
but I'm guessing. --> Jérôme: FFV1 CodecPrivate with version 0 or 1 is
invalid and ignore.
Same here, maybe the FFV1 people can help. The text is similar to the
one find in RFC9043
https://www.rfc-editor.org/rfc/rfc9043.html#section-4.3.3.4
We have change it a bit in
https://github.com/ietf-wg-cellar/matroska-specification/commit/2e8b0fcac952276ff251b29f9da12d57b8b1971c
We know these people - they're in CELLAR!
ACTION: Spencer to contact an FFV1 wizard to clarify this - does
that make sense?
At the our previous meeting we said:
Have not done much work on this recently (focus has been on first two
Mastroska extension documents)We do have a reference to a specification that is not public (DVD1
will always be private)Action Spencer to chase this reference so we can do the right thing
(we might have a solution as of the end of January 2025!)
https://en.wikipedia.org/wiki/DVD_Forum
https://web.archive.org/web/20241128004023/http://www.dvdforum.org:80/about-mission.htmhttps://www.dvdfllc.co.jp/notice.html "DVD Format Books (DVD
Specifications) will be deposited to the National Diet Library (NDL),
Japan (https://www.ndl.go.jp/en/index.html) as technology assets,
early 2025."
Do we have an update?
Action: Steve is watching for an update from the National Diet
Library, and will notify the working group when he sees it.