Minutes IETF99: cellar
Codec Encoding for LossLess Archiving and Realtime transmission
||Minutes IETF99: cellar
CELLAR WG - IETF 99 - Prague, CZ - July 21, 2017
Chairs: Tessa Fallon, Tim Terriberry
Area Director: Ben Campbell
Jabber Scribe: Jonathan Lennox
Note Taker: Mo Zanaty
Administrative Slides - Chairs
Ben (as AD): Milestones should be based on real work, not the publication
process. Tessa (as chair): We will update the milestones to later this year.
FFV1 Video Codec - Jerome Martinez
Jerome: Next version of FFV1 codec will change things to fix some bugs.
Ben (as AD): Next version of the draft or of the codec itself?
Jerome: FFV1 v0/1/3 (codec not draft version) are deployed and frozen, no
changes possible. Jerome: FFV1 v4 (codec not draft version) is in design and
needs bug fixes, so will change. Tim: Should the Matroska binding be defined
here in the FFV1 draft or the Matroska document? Jerome: Can be done in either
doc. Steve Lhomme (remote): Separate doc planned with all codec mappings.
Jonathan: Need one normative place to document the mapping, not multiple with
possible conflicts. Jerome: Matroska spec should point to FFV1 spec for
mapping. DECISION: FFV1-Matroska mapping will be defined in the FFV1 spec.
Matroska spec will reference this. Jonathan: If you have a C-like description
and English, which is normative? Jerome: C-like description is the normative
spec, English is informative. Jonathan: What do you mean by optimization of the
algorithm? Jerome: Optimize the normative bitstream itself, not just the
encoder implementation. Tim (as chair): How many have read this draft? Only 1
hand raised in the room, and 1 in the jabber room. Ben (as AD): Ask for
reviewers by name. WG last call may also get more reviews.
Matroska Container Format - Steve Lhomme (remote)
Mo: WebM being documented separately from the full Matroska spec seems like a
problem for change control and version alignment. Steve: WebM is a strict
subset of Matroska, authoritatively documented by Google. They add more
Matroska features to WebM over time. Jerome: We only document full Matroska,
and add some informative info about the WebM subset, but Google can change that
at any time so it is not normative or authoritative. Tim (as chair): Have we
asked Google about documenting WebM formally in IETF? Steve: No. Tim (as
chair): If the WebM subset changes faster than Matroska spec itself, can it be
an IANA registry? Steve: We have a table that shows the WebM subset. (No
discussion of whether this table can go into any registry.) Ben (as AD): Adding
XEBML sounds like substantially increased scope, should ask if WG really wants
to take this on. Standardizing another general purpose data encoding is tough
in IETF, easier to standardize something for a specific purpose. Tim (as
chair): Any volunteers for EBML review? Jerome volunteers. Tessa (as chair): We
will ask for EBML reviewers on the list. Tim (as chair): How many of the 22
issues just need a decision made, versus need actual work? Steve: Mixed bag,
some need just a simple decision, some need discussion. Tim (as chair): Is the
WG ok with moving codec mappings and tags to separate specs? Jonathan: Codec
registrations feels like RTP payload formats. Will IANA take over this? Steve:
Not sure how IANA works. (Tim offered links.) Need to explore that as a
FLAC Free Lossless Audio Codec - Andrew Weaver (remote)
Tim (as chair): Do you need anything from the WG?
Andrew: More communication with FLAC dev list. More authoritative home for
github repo. Tim (as chair): I will check on WG github repos. Jonathan: No
changes to FLAC bitstream, just documenting it, right? Andrew: Yes.
Next steps in the IETF pipeline - Chairs
Ben (as AD): Is it correct that FFV1 v0/1/3 and EBML are mostly done in authors
view; Matroska and FLAC need more work. Tim, Tessa (as chairs): Correct. Also
need more reviewers. Ben (as AD): If we take on XEBML, make it a separate
milestone, so it does not block the EBML milestone. Steve: Agree with Ben.
An Analysis of Two Video Digitization Standards and Their Development
Environments - Jimi Jones (No comments)