CELLAR -- DRAFT AGENDA for Virtual Interim Meeting

| Date | Time | Local Times | |
| :-: :-: :- -
| 2025-04-08 | 21:00 Amsterdam | Time Converter | |
| Note | Meeting time is anchored to Amsterdam | | |

Administrivia

INFO:

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.

Shared HedgeDoc for notetaking

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.

2025 virtual interim meeting dates

Future 2025 dates listed at
https://datatracker.ietf.org/wg/cellar/meetings/

• 2025-04-08
• 2025-04-29
• 2025-05-27
• 2025-06-24
• 2025-08-26
• 2025-09-23
• 2025-10-14
• 2025-12-09

Agenda Items

Roll call

Attendees

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

Regrets:

• Robert Sparks

Accept draft minutes from previous meeting
MINUTES ARE AT:
https://datatracker.ietf.org/doc/minutes-interim-2025-cellar-02-202502252000/

• Accepted with no objections

Note Well:

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

Registration of application/x-font-otf (No update at this meeting)

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.

Milestone review:

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 | |

tags-15

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)

• Feedback from Spencer's review of tags-15?

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)

PRs for CODEC-14

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?

Any update on chapter-codecs-05?

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.htm

https://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.

Update on FFV1

• version 3 is getting a GPU accelerated decoder in FFmpeg v8
• we need to update FFV1 version 4 draft to include improvements done
  in the reference decoder, especially float16 and float32 support

AOB?

Next meeting is 2025-04-27.