View source for GGIE TF/UseCases/Streaming

= Content Streaming =

== How these fit into GGIE  ==
These use cases are part of a larger set  of [[GGIE TF/UseCases|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=

<!--Comment
Cut and paste template for use cases

=== UC- ===
====Extends ====
====Description====
====Actors====
====Dependencies====
====Gaps====
====Notes====
====Authors====
====History====

-->




=== 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====
[[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|talk]])

====History====
:2-24-2015 [[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|talk]]) created
:3-12-2015 [[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|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 [[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|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:
:## control the content flow rate
:## manage its own content buffer fill and consumption
:## basic fault tolerance by switching to alternate video sources in manifest
:## basic performance responsiveness / variable bit rate ability by selecting sources with different bit rates in manifest
:## random access to the content
:## trick play - pause/rewind/fast forward
:## 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====
:[[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|talk]])

====History====
:2-24-2015 [[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|talk]]) created
:3-12-2015 [[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|talk]]) moved from main GGIE use case page.  Renamed from UC-2 to Streaming-UC-2
--[[User:Wjr|William Rose]] ([[User talk:Wjr|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:
::##is unique within the domain it belongs too
::##non-ambigious 
::##if Identifier A == Identifier B then Content A has identical scenes and time sequence as Content B    
::##conveys no information about content format: encoding, bit rate, resolution, etc
::##identifier A == Identifier B yields no information about comparative format properties.
:#Extraction of an unique content identifier C<sub>id</sub> is accomplished by one or more of:
::## Extraction from metadata
::## Extraction from an imbedded watermark (audio or video)
::## 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<sub>id</sub> for measurement/logging purposes
:#The application can use the C<sub>id</sub> 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 [https://tools.ietf.org/html/rfc7302]

==== 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<sub>id</sub> identifier amongst different name spaces.
:*The URI can contain additional information beyond the C<sub>id</sub>, 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====
:[[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|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.
<br />
: 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.
<br />
: 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====


====History====
:2-24-2015 [[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|talk]]) created
:3-12-2015 [[User:Gdeen|Glenn Deen]] ([[User talk:Gdeen|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
 
--[[User:Wjr|William Rose]] ([[User talk:Wjr|talk]]) 23:43, 27 July 2015 (UTC) Posted on behalf of Dale Rochon

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