Content Streaming

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 the act of streaming content from a content service to a user device.

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

Streaming-UC-1 Basic Streamed Content Viewing

Extends

Nothing

Description

A user using a viewing application selects from a list a content asset to view which is then streamed from a video streaming source to a viewing application.

The viewing application obtains a list of content assets available from a source
The viewing app displays the list to the user, who selects an asset to view
The viewing app sends a request to play the asset to the source
The source returns a URL with the protocol, port, and address of the server which will stream the content asset
The viewing application selects one of the streaming source addresses, establishes a connect to the streaming source
The source begins sending the video asset data stream to the viewing application
The viewing application recieves the stream, decodes it, and shows the video the user until the stream ends and is closed by the source

Actors

User
Viewing application
Content source
Content stream source
Content asset

Dependecies

Notes

This use case represents a trivial example which highlights essential steps of: 1) selection of content; 2) use of a content identifier; 3) source discovery; 4) viewing application connection to source; 5) video decoding done my the viewing application.

This is a very trivial initial example which is missing several important features: The only flow control is at the TCP level. Bytes are delivered by the source to the viewing application wihtout any control by the application. There is also no ability by the viewing applicaiton to start any place other than the start of the asset, and there is no trick play, or randmon access ability. These will be introduced in subsequent use cases.

Gaps

none known

Authors

Glenn Deen (talk)

History

2-24-2015 Glenn Deen (talk) created

3-12-2015 Glenn Deen (talk) moved from main GGIE use case page. Renamed from UC-1 to Streaming-UC-1

Streaming-UC-1bis Basic Streamed Content Selection

Extends

Streaming-UC-1, Basic Streamed Content Viewing

Description

A user uses a search application to search for a specific content asset to view by using one or more search terms (e.g., title, actors, director, language etc.).
The search application obtains a list of sources from which that content item meeting the search criteria can be streamed. Each source may include a cost to stream the asset.
The search app displays the list to the user, who selects a specific source for the specified asset.
When the user selects a particular source, the viewing app opens and takes over the next steps.
The viewing app interacts with the selected source and the user to ensure payment for the content (if that is required).
Assuming successful conclusion of the payment, the rest of the use case picks up from step 3 of UC-1

Actors

User
Viewing application
Search application
Content source
Content stream source
Content asset

Dependencies

Notes

This use case illustrates the need to identify assets with various pieces of metadata. Thus, the user requests a specific asset, not a generic one.

The search and the viewing app could be the same.

This should also be the very first use case, as finding and selecting the asset seems to me to precede delivery. I didn't want to put it ahead of the current UC-1 without feedback.

Gaps

None identified

Authors

Nilo Mitra

History

3-10-2015 Nilo Mitra created

3-12-2015 Glenn Deen (talk) moved from main GGIE use case page. Renamed from UC-1bis to Streaming-UC-1bis

Streaming-UC-2 Streamed Content Viewing

Extends

Extends Streaming-UC-1 adding several features:

A manifest file is returned by the source to the application listing multiple content data sources
The viewing application makes requests for specific ranges of the content asset. Enabling the application to:
1. control the content flow rate
2. manage its own content buffer fill and consumption
3. basic fault tolerance by switching to alternate video sources in manifest
4. basic performance responsiveness / variable bit rate ability by selecting sources with different bit rates in manifest
5. random access to the content
6. trick play - pause/rewind/fast forward
7. access to event streams associated with the media

Description

A user selects a content asset to view which is then streamed from a video streaming source to a viewing application.

The viewing app retrieves a list of available content assets from a source
The viewing app user selects an asset and sends a request for the asset to the content source
The content source returns a manifest file with a list of URLs of servers of the content
The viewing app selects a URL and sends a requests for a range of bytes
The content server returns the request list of bytes.
The application receives the requested bytes and adds them to a decode buffer
The application sends the decode buffer to the video playback decoder
The application may use a separate thread to manage filling of the decode buffer while the decoder is playing the content
If the content server does not respond, the application can select another URL from the manifest.
The application offers trick play - pause/rewind/fast forward to the users as well the abllity to jump ahead/back to any point in the content stream.
The application can manage buffers for which it can control the fill/consume rate of.
The application can receive data from event streams associated with the content stream and provide the associated interactions to the user.

Actors

User
Viewing application
Content source
Content stream source
Content asset

Dependecies

Streaming-UC-1

Notes

This use case with a few additions above Streaming-UC-1 represents a more sophisticated even real world example of Internet video delivery.

Gaps

none known

Authors

Glenn Deen (talk)

History

2-24-2015 Glenn Deen (talk) created

3-12-2015 Glenn Deen (talk) moved from main GGIE use case page. Renamed from UC-2 to Streaming-UC-2

--William Rose (talk) 13:14, 15 September 2015 (UTC) added "7. access to event streams associated with the media" and line 12. to the description.on behalf of G Mandyam

Streaming-UC-3 Identifying Streamed Content

Extends

Streaming-UC-2

Description

User A selects a content asset to view which is then streamed from a video streaming source to a viewing application. The application identifies the content it is playing and uses this information to record viewing, and to help select a source of the content.

The viewing app retrieves a list of available content assets from a source
The viewing app user selects an asset and sends a request for the asset to the content source
The content source returns a manifest file with a list of URLs of servers of the content
The viewing app selects a URL and sends a requests for a range of bytes
The content server returns the request list of bytes.
The application receives the requested bytes and adds them to a decode buffer
The application sends the decode buffer to the video playback decoder
The application may use a separate thread to manage filling of the decode buffer while the decoder is playing the content
If the content server does not respond, the application can select another URL from the manifest.
The application offers trick play - pause/rewind/fast forward to the users as well the abllity to jump ahead/back to any point in the content stream.
The applicaiton can manage buffers for which it can control the fill/consume rate of.
The application identifies the content mapping it to a comparative content identifier that uniquely identifies the content being played.

Identifier properties:

1. is unique within the domain it belongs too
2. non-ambigious
3. if Identifier A == Identifier B then Content A has identical scenes and time sequence as Content B
4. conveys no information about content format: encoding, bit rate, resolution, etc
5. identifier A == Identifier B yields no information about comparative format properties.

Extraction of an unique content identifier C_id is accomplished by one or more of:

1. Extraction from metadata
2. Extraction from an imbedded watermark (audio or video)
3. Computation of a fingerprint (audio or video) and subsequent retrieval of content identifier associated with the fingerprint

The application can record/report the detection of the C_id for measurement/logging purposes
The application can use the C_id to form a URI than can be used with other video content sources to uniquely identify the content being viewed

Extends

Extends Streaming-UC-2 by adding content identifiers and associating a content identifier with a content asset

This permits the application to optionally log the content being watched,
This permits the application to optionally report the content idenfitier for purposes such as measurement
The application can form a URI that it can use when contacting other video sources to identify the content it is playing

Actors

User
Viewing application
Content source
Content stream source
Content asset

Dependecies

Streaming-UC-2

Entertainment Identifier Registry (EIDR) URN Namespace Definition RFC 7302 [1]

Notes

The content identifier identifies the "work", that is to say the video "Bird flying into Clouds by John Smith". This identifier does not identify either the delivery hosts/service nor the format or other information about instances.
The Content Identifier will likely not be universally unique across all content. Instead it will be unique with a particular domain of issued identifiers. An example of this would be EIDR identifiers which are created when content is registered with the EIDR registry and are only unique within the scope of EIDR identifiers. For this reason, it will be necessary to including a name space identifier prefix to disambiguate the C_id identifier amongst different name spaces.
The URI can contain additional information beyond the C_id, what additional elements will be revealed by the demands necessary to satisfy other use cases using the URI.

Gaps

No existing standard to reference for content identifier URIs

No existing standard to reference for extracting content identifiers from content metadata

No existing standard to reference for retrieving imbedding content identifiers as content watermarks

No existing standard to reference for computing fingerprints of content

No existing standard to reference for retrieving a Content Identifier based on a content fingerprint

Authors

Glenn Deen (talk)

Streaming-UC-4 Manipulating streamed content

Extends

Creating streaming content, for which a use case hasn't been defined yet.

Description

Content items may be interposed within other content to create the version that is streamed to the end consumer. A classic example is linear TV which is a sequence of programming content and advertisement slots. Another is video-on-demand, where previews and advertisements can be placed before, after and within the main content item. The number, position and length of these interstitial content items are determined by business agreements between the actors identified below.

Another instance is the replacement of one program by another, for business or regulatory reasons, when streamed to end consumers in a particular locality/region. An example is sports programming blackout.

Some examples of manipulation of streamed media are:

In the US, Broadcast network programs can have certain programs and ad slots replaced by others at a local broadcast station before transmission to the end consumer. Similarly some Cable network ads can be replaced by the cable service provider.
Online video service providers can insert different ad loads into programs they acquire from programmers or movie distributors; similarly for user-generated content.
Some cable, satellite and IPTV service providers cache ad content in subscriber STBs and use consumer data and analytics to choose more targeted ads to replace the ones streamed

For the above cases showing the manipulation of streamed content, signals are needed to identify which programs/ad slots can be replaced.

Actors

Programmer (e.g., Broadcast or Cable network, film producer/distributor, user-generated content)
Video distributor (e.g., online video portal, cable or IPTV service provider)
Advertiser
End consumer

Dependencies

None identified thus far.

Gaps

The following points were made at the telcon on July 15:

It is easy and commonplace to add pre-roll and post-roll ads to short user generated content, but increasingly there is a class of semi-professional long form content (e.g., YouTube channels) where mid-roll ad insertion is also becoming prevalent.
It is not clear how end consumers can directly monetize their content without the mediation of an online video service provider, which has all the necessary relationships with advertisers.

Notes

Ad-ID and EIDR are used to identify ad content and entertainment/programming content respectively.

SMPTE is working on a specification to insert such identifiers into content items and recover these at the consuming device to support measurements for ratings, royalties, etc.

SCTE has defined specifications for signaling the position of interstitials and alternative content. This is used by Cable networks and cable service providers, and some IPTV service providers.

IAB has defined how online video providers can use its VAST specifications to query ad servers for advertising content to place in pre-post-mid roll breaks as well as some other forms (e.g., overlays).

Authors

Nilo Mitra (nilo.mitra@ericsson.com)

History

2-24-2015 Glenn Deen (talk) created

3-12-2015 Glenn Deen (talk) moved from main GGIE use case page. Renamed from UC-3 to Streaming-UC-3

Streaming-UC-5 Streamed Content Ad Insertion Interstitial Ads

Extends

Nothing

Description

As digital media program streams are assembled for consumer viewing there may be secondary parties that may assemble additional media also known as Ads into the media program stream that is being viewed. Ad insertion can occur at several points along the media program stream distribution process.

Consumers use Media Playback Devices to view program content streams with or without associated Ad Content.
The Media Playback Device initiates requests to display program content with associated Ad break notifications as determined by the program content owners.
There is a process that creates the playlist for the individual media stream viewing with the appropriate Ad insertions scheduled for the individual device and the instructions of where and how to insert the appropriate Ads from the locations where Ads may be stored.
The digital media program asset consists of a single file or container which contains both the video and audio encoded by codec and metadata which is additional data about the video, the camera, the capture event, the user, etc.
The digital asset contains metadata written by the camera including resolution, bit rate, and other attributes of the capture. It may contain time, location, copyright info, camera info.
The source returns a URL with the protocol, port, and address of the server which will stream the Program content asset

Actors

User
Media Playback Device
Media player
Ad asset storage
Program Content Assets consisting of containers holding metadata and encoded audio-video data
Ad Content Assets consisting of containers holding metadata and encoded audio-video data
Ad insertion processing consisting of set of audio & video playback instructions with for each of the media assets involved in the requested media program streams and associated Ads.

Dependencies

No dependencies identified to date

Notes

This use case represents a trivial example which highlights essential steps of: Ad insertions in a program stream.

IAB (Internet Advertising Bureau) has defined specifications for signaling the position of interstitial Ad content used in online and mobile applications.

An issue regarding the potential for a rogue app to replace legitimate interstitial ads with alternative, unauthorized media. In reviewing this Use Case this issue should be discussed. Also looking for W3C advice on potential remedies and implications.

Gaps

none known

Authors

Dale Rochon (dale_rochon@att.net)

History

7-15-2015 Dale Rochon created

--William Rose (talk) 23:43, 27 July 2015 (UTC) Posted on behalf of Dale Rochon

--William Rose (talk) 15:05, 4 August 2015 (UTC)Added 3rd note on rogue apps