The prior meeting minutes were approved without change.
<glennd> This is the last call before TPAC. The Use Case slides from September 23rd were updated to include the recommended changes from 9-29-15. We don’t have whole day. Waiting to hear what time the session will be held (AM or PM). Could use 2 hours for main issues but if 3-4 hours we can dive deeper.
<MarkVickers> Have not had the discussion yet. Will get back.
<glennd> This is intended to be the draft deck. Will update based on today’s discussion. Intent is to send to members’ list ahead of TPAC for comment.
<glennd> Slide 2: GGIE History. Started the review of the deck with discussion on GGIE’s background and our history, scope, goals. Looking at capture through consumption of all video content, not just professional with the goal of identifying gaps in existing standards. 5 focus points: Scalability, Content ID, Metadata, Identity, and Privacy.
<glennd> Slide 3: Review of 2015 developments in industry. Bullets: # of creators grew rapidly; #of viewers grew faster; higher resolutions (4K now, 8K coming) requiring more bandwidth; new devices for capture – phones now at 4K; new platforms for distribution – 1:Many live video streaming (Periscope); No new technologies to make this easier to do.
<MarkVickers> 2015 had HDR coming on stream, delivered by Amazon.
Edit notes: Delete “is” from second bullet, remove “crazy” from bullets 1 and 2.
<glennd> Slide 4: Important to share the GGIE diagram with TPAC group. Captures much of the complexity we are addressing. Huge ecosystem that creates a need for a new taxonomy to describe it. Intelligence, decision making growing in core but Internet was not designed for that. Need to push intelligence toward edge.
<glennd> Slide 5: Related activities. SMPTE - Open Binding of IDs to media; ATSC 3.0 - ACR watermarking; IETF - NetVC WG (royalty free codec). New alliances have formed (Streaming Video Alliance (NBCU is a member), Alliance for Open Media). SVA is operationally focused on using best practices; short term solutions for caching, content delivery, etc; not developing standards; natural synergy with GGIE.
<glennd> Slide 6: GGIE developed UCs around 5 areas:
<glennd> Slide 7: Task force limits. Operating under W3C IG rules. We can discuss what something may do/what it works like, no details as to how it would do it. Creates IP safe zone to foster creative discussion.
<MarkVickers> Can discuss anything we want. We do not write specs. We can set requirements.
<glennd> Slide 8: Requirement 1 from UCs. Focus on persistent identifiers that can enable intelligent mgmt at all stages using IDs assigned at capture or distribution and associated with the content using metadata, watermark, or fingerprint; solutions should support different ID authorities (Ad-ID, EIDR, ISAN, ...). Pros and cons to each way ID is associated with the content. E.g. multiple watermarks can collide; fingerprint files can grow large; metadata can get separated from content.
<glennd> Slide 9: Requirement 2. Identifying content for search, EPG, apps is different than identifying content for streaming, decoding, caching. Search/EPG/Applications care about “work attributes” – title/ language/version, metadata (actors, etc.). Streaming/decoding/caching is concerned with format and delivery attributes – codec, bit-rate, resolution, latency, etc.
<glennd> Slide 10: Requirement 3. Content IDs for Applications. Needs structure to permit applications to work with many different naming authorities – URI. Need mechanism to associate ID with content (metadata, watermark, fingerprint). Benefit from a standard API for useby browser applicaiotns enabling apps to extract content ID regardless of how it is marked in content. Call this “Content URI”.
<glennd> Slide 11: Requirement 4. Content ID for Delivery. Ideally integrated with the network. Single “viewing” of content may involve multiple linked streams going to different devices delivering diff encodings and data. E.g. HEVC to screen with different audio codec that is not in first container. One suggestion GGIE has discussed is a 128 bit identifier that could be carried in an IPv6 address slot. Call this “Content Address”.
<glennd> Slide 12: Requirement 5. Need to translate between Content URIs and Content Addresses. Fundamental linkage between finding content and accessing content. Open protocol system; bi-directional resolution. Content URI::Content Address => 1::Many relationship. Content Address::Content URI => Many::Many relationship.
<glennd> Slide 13: Requirement 6. Streamed content delivery can be viewed like a composed flow combing many parts. Not simple file copy from source to player. Orchestrated/composed playback of one or more component streams from one or more addresses to one or more devices over one or more networks. Enables rich use cases like Periscope.
<glennd> Need to add a table of content to the UCs.
<glennd> Question. After the review, should we add a summary page as to where we are now.
<MarkVickers> Yes. Also need to add “what’s next”.
<glennd> Looking to address some issues at IETF. Cisco presented a solution at the last IETF meeting. Does the W3C think it makes sense to liaise with Streaming Video Alliance, ATSC, SMPTE (watermarks). TVs becoming browsers. If TV can interact with the IDs it would help.
<MarkVickers> What is the work output for this group? Is the next step is to turn the UCs into a requirements document and then turn the requirements document into a request for liaison? Several approaches: Output for most IGs is to set requirements that W3C turns into a spec in a WG. E.g. some of participants form/join a WG to do the work. 2nd approach is to draft something that is then refined by a WG. 3rd approach is to start a Community Group (CG) which can also write a spec. Since GGIE is trying to influence W3C and other groups we can form the CG and write specs or requirements that go to liaison. Need to determine the path.
<glennd> Always thought of liaison as being a synchronization means but it does not fit all that we are doing here. Could see W3C working within its domain on an API spec. For work outside of W3C, we need to think more about it and discuss the best approach. Perhaps identify the high level ideas/needs.
<MarkVickers> If it turns out the output is a W3C API spec then we can start by writing the requirements and start the spec, then start a CG to complete. Takes 5 people to create a CG. Influencing others is difficult. Thought this is the original idea but it is difficult to influence multiple outside groups.
<glennd> Need to discuss at TPAC and decide how to proceed. If we can hold the meeting in the morning it would help people to call in.
<kaz> Will set up a Doodle Poll to gauge preferences for the time of the meeting at TPAC (AM or PM).
<MarkVickers> Need to have a concrete proposal for next steps at TPAC.
<glennd> The next meeting will be held on Monday at TPAC in Sapporo, Japan. Time (TBD).
<glennd> Meeting adjourned