Content Identification and Measurement Use Cases

How these fit into GGIE

These use cases are part of a larger set of GGIE Use Cases being worked on by the GGIE taskforce. This page covers user cases relating to methods to identify and to measure content

Abstract

This document describes use cases for the glass to glass digital video ecosystem ranging from capture through to viewing

Status of this document

This is a public working in draft collection of use cases that the GGIE task force is discussing and exploring. It has no official standing of any kind and note represent the support or consensus of any standards organization or contributor. GGIE is a taskforce of the W3C Public Web & TV Interest Group

Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Use Cases

Content Identification UC-1 User Device Retrieval of Content Address(es) Using EPG/Title

Extends

Streaming UC-1, UC-2, UC3 https://www.w3.org/2011/webtv/wiki/GGIE_TF/UseCases/Streaming

Description

In Streaming Use Cases UC-1, UC-2 and UC-3 it is noted that the viewing app selects an asset and sends a request for the asset to the content source which returns a list of URLs for the content. One of the concepts being discussed in GGIE is that each version of an asset (e.g. EIDR, encoding, bit rate, etc.) could be given a unique 128 bit address prefix. Content matching that prefix may reside at any number of locations. Furthermore, different parts of the asset may reside in different locations. Therefore a request for a given asset URL will need to be resolved to the content addresses which may reside on one or more locations. Thus there would need to be a means to resolve the Content ID/Title of an asset to its unique address. We can suppose a distributed "Content Cache Resolution Service" (CCRS) to be defined later. The process might look like the following:

The user selects a title from the EPG. The EPG listing for the title includes the content ID (e.g. EIDR) for the title
The media player appends device specific parameters (encoding, BR, etc.) to the Content ID (e.g. EIDR ID) and sends it to the media resolver
The media resolver sends a request to the external CCRS for e.g. uri://eidr:10fe3...
The external CCRS calls the EIDR CCRS to resolve the EIDR ID
The EIDR CCRS calls the Content Owner CCRS to get the address prefix(es) for the content (note that each decoding might have a distinct address prefix)
The Content Owner CCRS returns one or more 128 bit content address(es) to the media player via the EIDR CCRS and external CCRS.
Each fragment of the content has an IP address (associated with the content address prefix) allowing the media player to request any fragment or range of fragments of the content by address.

Actors

Viewing device comprised of the Media Player, EPG, Media Resolver
External CCRS(s)
Issuing Authority CCRS (e.g. EIDR)
Content Owner CCRS

Dependencies

Streaming UC-1, 2, 3

Gaps

Not all content is issued a Content ID (CID)/URL by an Issuing Authority
Defined method of assigning unique content prefix addresses for CID with each encoding/BR, etc., receiving a unique prefix.
Defined method of addressing content shards based on content prefixes
Method for propagating content addresses (e.g. similar to DNS)

Authors

--Glenn Deen

--William Rose (talk) 00:37, 29 July 2015 (UTC)

History

--William Rose (talk) 00:37, 29 July 2015 (UTC) Posted