- From: Daniel Davis <ddavis@w3.org>
- Date: Thu, 8 Oct 2015 17:42:13 +0900
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Hello all,
Here are the minutes from the GGIE (Glass-to-Glass Internet Ecosystem)
call on October 7th:
http://www.w3.org/2015/10/07-webtv-minutes.html
and pasted in full below. Thanks to Bill for scribing again.
With regards,
Daniel
==========
Web and TV IG: GGIE meeting
7 Oct 2015
Attendees
Present
Glenn Deen, Leslie Daigle, Nilo Mitra, Mark Vickers,
Glen Goldstein, Dale Rochon, Bill Rose, Kazuyuki
Ashimura
Regrets
Chair
Glenn
Scribe
Bill Rose
Contents
* [2]Call admin
* [3]Review of TPAC Use Case slide deck
* [4]Next Meetings
__________________________________________________________
Call admin
The prior meeting minutes were approved without change.
Review of TPAC Use Case slide deck
<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:
1. User Content Discovery/search/EPG/Media Library
2. Viewing
3. Content ID and Measurement
4. Network Location and Access
5. Content Capture
<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.
Next meetings
<glennd> The next meeting will be held on Monday at TPAC in
Sapporo, Japan. Time (TBD).
<glennd> Meeting adjourned
Summary of Action Items
Action Items created during this call
* Glenn Deen to draft Next Steps for TPAC meeting
* Bill Rose to create TOC for Use Case section.
* Kaz to set up Doodle Poll to determine desired time for the
meeting at TPAC for dial-in participants.
[End of minutes]
__________________________________________________________
Received on Thursday, 8 October 2015 08:42:47 UTC