Content Capture

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 use case involving capturing content with a dedicated camera, or a device with an integrated camera 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

Capture-UC-1 Basic Video Asset Capture

Extends

Nothing

Description

A user using a device with a video camera mode captures a scene by recording it. The scene is recorded as a digital video asset at a fixed resolution and bit rate.

The user uses the camera to capture/record a audio-video scene.
The camera captures the scene, encodes the video into a digital asset at a fixed resolution and bit rate into a digital format and writes the encoded video to a storage device - hard drive, flash storage, etc.
The digital 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 content asset

Actors

User
Camera
Writable Storage
Content asset consisting of s container holding metadata and encoded audio-video data

Dependecies

Notes

This use case represents a trivial example which highlights essential steps of: 1) capture of a scene as a digital video asset; 2) encoding the file using an audio and video codec; 3) writing the asset to digital persistent storag; 4) content metadata stored in the asset container

Gaps

none known

Authors

Glenn Deen (talk)

History

4-21-2015 Glenn Deen (talk) created

Capture-UC-2 Assigning a unique content identifier at asset capture

Extends

Capture-UC-1

Description

Following on from Capture UC-1, a content identifier that is unique within an authority domain is assigned and associated with the captured asset.

The user uses the camera to capture/record an audio-video scene.
The device obtains a content identifier from a content identifier issuing service. The identifier is unique within the domain of the content identifier service.
The issued content identifier is associated by the device with the captured asset. Simple example of this can include imbedding the content identifier in the file name, or in the asset container metadata

Actors

Camera
Writable Storage
Content asset consisting of s container holding metadata and encoded audio-video data
Content Identifier authority

Dependencies

Notes

Generation and association of a unique content identifier with a digital asset can be done anytime post capture. The assignment of a content identifier to a captured asset may differ from assignment of an identifier to a published work. A published work may consist of more than one assets that are edited together to form a new composite work. In both cases the content identifiers must be unique within the domain of authority which created then.

Gaps

standardized content identifier & issuing authority

Authors

Glenn Deen (talk)

History

4-21-2015 Glenn Deen (talk) created

Capture-UC-3 Fingerprinting and associating a content identifier at asset capture

Extends

Capture-UC-2

Description

Following on from Capture UC-2, the capture device generates a digital fingerprint of the captured content, and registers this fingerprint with along with the unique content identifier for the asset.

The user uses the camera to capture/record a video scene.
The device computes a digital fingerprint for the captured asset - either a video, audio, or both fingerprint.
The device registers the digital fingerprint with a content identification authority which issues a content identifier from the authorities name space and registers the association of the fingerprint with the issued content identifier.

Actors

Camera

Writable Storage
Content asset consisting of s container holding metadata and encoded audio-video data
Content Identifier authority
Fingerprint Generator
Fingerprint::Content Identifier Registration Service

Dependecies

Notes

This use case represents the basic task of a device generating and registering a fingerprint for an asset at the time of capture. This fingerprint is associated with a content identifier when registered with the registration service.

Note: Alternatively to this use case the content identifier could be stored in the asset using a digital watermark. Doing so at capture is not idea in that it requires modification of the captured content. Watermarks are either hidden so as to make them not impair the content, or audible/visible meaning they can be detected by the viewer without additional tools. In both cases, modifying the captured content permanently modifies if done at capture time. A more clean solution, for associating a content identifier at time of capture is what is shown in Capture-US-2 and Capture-UC-3 which both preserve a pristine capture. Watermarking may be used to embed a content identifier for a work that is being published as that does not require marking the original pristine content but instead is done on an edited copy.

Gaps

standardized digital fingerprint generators

standardized digital fingerprint algorithm

standardized Fingerprint::Content Identifier Registration Service protocol

Authors

Glenn Deen (talk)

History

4-21-2015 Glenn Deen (talk) created

Capture UC-4 3rd Party Composite Asset From Multiple Sources

Extends

Capture-UC-2 Assigning a Unique Identifier at Asset Capture

Description

It is becoming common for the same event to be captured using a number of different cameras. For example, a commercial entity uses multiple cameras to provide different viewing angles and makes two or more of them available to consumers so they can choose which angle to watch. Alternatively many different people may capture an event on personal devices and make them available through social media. A 3rd party not associated with the original sources composites content from two or more of these sources. Each of the sources and the resulting composite asset are associated with a unique identifier assigned by an authority as in Capture-UC-2.

The 3rd party may obtain live original source content used in the composite from one or more commercial entities and/or from individuals who are posting their content to social media sites. They may also add content from other sources such as advertising, etc. New audio may also be added such as commentary, music, etc. The 3rd party would then make the new stream available to others via subscription, social media or other means. Alternatively, a 3rd party might composite assets from social media sites to create their own “news” channel which they make available to subscribers.

The 3rd party obtains digital feeds/files from one or more sources of content. This may also include archived assets, advertising, new commentary/audio, etc.
Each of the sources/assets includes a unique ID that has been associated with the source/asset as in Capture UC-2.
The 3rd party creates a new asset, obtains a unique content identifier from a content identifier authority and associates it with the new composite asset as in Capture UC-2.
The 3rd party publishes or otherwise makes available the resulting asset to the general public.
A consumer may choose to subscribe to the 3rd party's stream as their preferred source for viewing specific events such as sports, news, etc.

Actors

Content assets from one or more sources (cameras, cloud storage, CDN, etc.) consisting of a container holding metadata and encoded a/v data each with a unique content identifier
Content identifier authority
3rd Party compositor
Publisher

Dependencies

Capture-UC-2

Notes

The means to ensure rights management for any sources used in a composite asset or the composite asset itself is out of scope for this work. However, the mechanisms suggested by this work should anticipate the need to support rights management. One approach is to ensure that the unique ID(s) from any asset(s) used to create the composite asset become and remain associated with the composite asset in some manner.
Assuming the original sources have IDs reliably associated with the asset, there should be a means to associate the original source IDs with the new asset's ID, as well as to recover the metadata associated with the original sources.
Issue: Since the original sources may consist of short clips taken from a larger asset, can the IDs be reliably retrieved for subsequent use in search/discovery and rights management?

Gaps

Standardized content identifier and issuing authority(s)
Reliable means to associate the unique identifier with an asset
Reliable means to associate IDs from original sources with the composite asset ID for search and discovery and for Rights Management

Authors

Bill Rose (talk)

History

--William Rose (talk) 17:35, 30 April 2015 (UTC) Created Capture-UC-4

Capture UC-5 Distributing 3rd Party Composite Asset Using Composite Manifest

Extends

Capture-UC-4 3rd Party Composit Asset From Multiple Sources

Description

Capture UC-4 anticipates the compositor creates a new asset, and distributes, for example, a link to the new asset which would return the manifest for the composited asset file to subscribers. The assumption is the new asset is stored complete on one or more servers for distribution.

In this use case, Capture UC-5, the compositor instead distributes a link to the asset which returns a composite manifest that contains the URIs for each segment from which the new asset is composed. Since the new asset may only include segments from these assets the timing information (or beginning and ending shards/fragments) necessary for the destination client to assemble and play back the new asset must be included. Alternatively, in the case of a live event to which, for example, multiple camera angles are simultaneously made available the compositor would distribute a series of links to the channels (channel changes) along with any necessary timing relating to making the switches between them. Such “links” may be sent in real time to the subscribing client so it can switch “channels” in real time during a live event, or it may be a composite manifest for later playback of archived assets. The audio may be from the original assets or the compositor may provide different audio. The advantages to this approach are

The 3rd party does not need to provide the server(s) to distribute the asset since the actual content will come from the original asset servers
Any rights management needed to access the original assets will be handled by the distributors of those assets. For example, if the original assets are different camera angles for a licensed sporting event the customer/client would need to provide the necessary credentials to gain access to those feeds.
The compositor may provide alternative links for any segments (assets) to which the client does not have a license or does not support the format of the segment(s).
Any changes made to the original assets will automatically be reflected in the new asset. This is a pro (new asset reflects the changes) and a con since the compositor's audio stream may no longer match the altered (original) asset and the associated timing information may no longer be accurate. Additionally, any changes to the location/link to the original asset(s) may cause problems.

Actors

Content assets from one or more sources (cameras, cloud storage, CDN, etc.) consisting of a container holding metadata and encoded a/v data each with a unique content identifier
Content identifier authority
3rd Party compositor
Publisher

Dependencies

Capture-UC-4

Gaps

This author does not know if there exists a mechanism that can be used to ensure the client can access and decode the asset(s) prior to initiating playback to avoid interruptions. This might be done

as part of the subscription process whereby the client registers its capabilities during registration ensuring the composite manifest only contains segments the client can play
in an initial pass through the composite manifest so the client can request alternative segments
the composite manifest can include alternative segments along with enough information to allow the client to select from several choices in real time.

Notes

In discussing this UC it was noted that truly live content such as someone capturing a live event may not receive an ID until the recording window is closed.
It was also noted that in addressing this UC, it may be necessary to differentiate between ephemeral content and persistent or stored content. Ephemeral content may not be stored (only avaialble live) or may have an expiration time. This may affect how it is treated, distributed.
This UC should be re-examined when we are discussing Distribution Use Cases as it includes a somewhat unique distribution paradigm. The manifest that is distributed is essentially a Play List that requires the end device to obtain content from multiple sources that may use different codecs, rights management, etc.

Authors

--William Rose (talk) 20:10, 11 June 2015 (UTC)

History

--William Rose (talk) Created Capture-UC5

William Rose (talk) 19:21, 1 July 2015 (UTC) Added 3 notes