Minutes for CELLAR at IETF-96
Codec Encoding for LossLess Archiving and Realtime transmission
||Minutes for CELLAR at IETF-96
CELLAR WG - IETF 96 - Berlin - July 19, 2016 - 14:00-16:00
Chairs: Tessa Fallon, Tim Terriberry
Area Director: Ben Campbell
Administrivia (Chairs, 10 min)
Ben (as AD): Jun/Jul 2016 milestones for EBML/Matroska need to be adjusted.
Dave Rice: Suggest to remove the Matroska v1/2/3 informational sections from
the draft and publish a standards track v4 document. Ben (as AD): Clarify this
is documenting work done elsewhere, not new work.
EBML + Matroska (Steve Lhomme, 60 min)
Dave: ? (missed point)
Thomas Daede: Should define what is valid/invalid for a player implementing
this. Steve: EBML can include CRC which archivists would like to isolate
errors. Thomas: What is the goal of the EBML schema? Can it validate things?
Steve: No machine validation yet, but would be nice. Dave: XML schema is being
used to define EBML schema. Machine validation via schema would be nice.
Jonathan Lennox: Don't boil the ocean with EBML schema, just start with a
reference implementation. Steve: Beyond EBML schema, there are more validations
that can be done. Tim (as chair): EBML draft supports milestone, Matroska draft
does not yet. Adopt EBML draft now? Ben (as AD): Adopting a draft means a good
starting point, not that it's done. Dave: Lots of issues tracked against the
EBML draft. Tim (as chair): Adopt EBML draft now? Moderate hums in room and
jabber. No hums against. Will confirm adoption on the list. FFV1 (Jerome
Martinez, 30 min) draft-niedermayer-cellar-ffv1-00 Tessa (as chair): First FFV1
v0/1/3 as informational? Jerome: Yes, v4 would be standards track. Thomas: Will
FFV1 contain color space info? Jerome: Yes in FFV1 v4, but not earlier
versions. Matroska container may also carry this separately. Jonathan: Consider
moving not copying (between FFV1 and MKV). Jerome: No, we want it in both since
container change/remux may lose the info while the FFV1 elementary stream may
retain it. Stephen Botzko: Duplication of elementary stream info goes beyond
container formats, e.g. SIP/SDP, so not necessary to de-duplicate. Dave:
(something) Siri: I didn't quite get that. :) Peter B.: What Dave said was that
there are cases where it makes sense that the container can overload
information in the codec. Because changing it in the codec might often not be
possible without re-encoding - and it happens (unfortunately quite often) that
users overlook wrong information being written in the codec. Yet, on the other
hand it makes sense to have info in the codec, so it's independent of which
container the data is stored in. :) Participation and work moving forward
(Chairs, 20 min) (including FLAC, advice for new IETF participants, getting
commitments to work on various specs, etc) Chairs: Need volunteers for FLAC.
Dave: Need to convert FLAC html to markdown draft for a starting point. Chairs:
Was a face-to-face meeting useful? Dave: Yes, deadlines for F2F meeting also
helped get things done. Dave: Matroska draft is 220 pages, most of which was
auto-converted from concatenated XML schemas. Ben (as AD): Big drafts are ok,
only split if they can be somewhat independent. Normative XML is ok, as long as
new implementers can effectively use it.