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)

draft-lhomme-cellar-ebml-00
draft-lhomme-cellar-matroska-00
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.