SVTA Documents Dashboard

This consumer research study, based on 1000 respondents, was fielded in late 2016 and explored attitudes and behaviors around watching video on mobile phones.

VR/360-degree video is an exciting evolution of traditional video content and both entertainment companies and traditional businesses are exploring its uses. While consumer adoption of VR video is still at the beginning of the adoption curve, many content owners and marketers are looking to this innovative medium to differentiate themselves in a crowded content market, to tell new, engaging stories, or deliver product/brand messaging. This market report looks at the technology, challenges, and approaches currently available to content creators with VR/360-degree video.

Delivering a great video experience requires content to be served as close to the end-user as possible. In this whitepaper, we illustrate how network operators can implement Open Caching nodes at the edge of their network, while adhering to specifications created by the Open Caching Working Group of the Streaming Video Alliance. These nodes can mitigate delivery latency and provide an improved viewer experience when hosted by the ISP and connected to the CDN/Content Provider nodes outside of the operator network, to create an Open Caching Network.

This paper explores the technology behind Multicast ABR and its potential to improve how video content is streamed over IP, meeting the network operator’s needs for a scalable way to deliver growing video traffic and end-users’ demands for the best possible streaming experience.

This document provides an explanation of the Common Media Application Format (CMAF) and the Alliance’s position on it within a streaming video workflow.

The evolution of content distribution models over the past decades has introduced a tremendous amount of flexibility for content processing and delivery. The availability of metadata, which provides information related to descriptive, business, and technical aspects of content, is needed to take advantage of advanced content streaming approaches. Commonly used metadata approaches primarily serve static distribution models. Additionally, there are a lack of solutions available that provide a consistent, user-friendly, and efficient approach to managing metadata. This document provides a starting point for understanding metadata usage and challenges and looks at organizations that have developed metadata-related standards.

As mobile networks evolved, became faster and offered more and more bandwidth, consumer habits also changed. Users began to adopt data-hungry activities like streaming video, streaming music, and cloud gaming. As the networks have continued to improve, so too has our expectations of the amount and quality of content delivered to our devices negating many of the benefits offered by the latest network and radio infrastructure.

The popularity of OTT services such as Netflix and YouTube are burgeoning and the demand for video content on mobile devices is rising exponentially placing massive demands on current 4G networks. Increased demand is just one aspect though. New formats like 360 degree video and XR in conjunction with higher definition including 4k and 8k are becoming common for videos viewed on connected devices, particularly those streaming content to big screen TV’s or head mounted VR units and as video quality rises, so does the need for faster connections to enjoy seamless streaming.

The ability to stream high quality video HD content requires download of less than 5 Mbps while an ultra-HD 4k video requires around 15 Mbps depending on the codec and compression. Both are easily supportable with the constraints of the current 4G specification however when combined with massive catalogs and insatiable demand, shared bandwidth on a radio network quickly becomes exhausted.

Even if the ability to stream at a high bandwidth is available, its not much use if the 4G radio network is not accessible. While operators continue to build out their 4G infrastructure we still experience far from ubiquitous coverage. When users lose their 4G connection the service is normally bumped down to 3G network which is typically 5 times slower making it impossible to initiate or continue to stream content. Clearly 4G cannot support the quality of service that most major content brands expect need to present to their consumers or the low latencies that XR and Cloud Gaming applications require.

5G has the potential to deliver a broad, disruptive user experience throughout the Media and Entertainment vertical, and will extend the metaphor of very simple content delivery to mobile devices that is prevalent in the market today, to an immersive, interactive and tactile shared experience for video entertainment, cloud gaming and extended reality (XR). With exceptional QoE combined with new business models that will include hyper-targeted advertising and enhanced QoE, 5G has the potential not only to bring content closer to the consumer, but also bring consumers closer together within the content ecosystem.

Extended Reality (XR) is becoming deeply ingrained in the consumer entertainment space and represents an interesting opportunity to provide immersive video experiences for the creators of premium entertainment and gaming content. This document looks at the XR use cases that are currently being deployed in both the entertainment and enterprise sectors and examines some of the technologies being leveraged today.

This document examines some of the differences and improvements between TCP and QUIC and provides an overview of HTTP/3. It examines the deployment model and summarizes some of the pros and cons that streaming providers need to consider before QUIC adoption.

This document describes a working proof of concept (PoC) developed by the SVTA to prove the value of tracing for this very purpose and move the industry towards more robust, reliable experiences that delight, rather than frustrate viewers.

This whitepaper details the results from the Phase 1 testing in the QUIC/TCP PoC project.

Problem statement and functional requirements of an open caching solution deployed by service providers to be used by content providers and content delivery networks.

This document specifies requirements for Open Caching System (OCS) for Logging data to help track data acquisition and delivery of it to the end user. The information logging is critical for the Open Caching Nodes as well as the upstream CDN and the Content Provider (CP). Logging information helps OCS track key performance metrics such as, data acquisition, delivery success and failures, measuring of effective throughput, cache hits and for troubleshooting fault and performance degradation. The logging data provided to the CDN by the OCS is also used by CDNs for auditing, billing and SLA purposes. The information logging will also be used by Open Caching Nodes (making up an OCS) for ensuring its compliance of SLAs with CDNs and measuring and assuring
Quality of Experience (QoE) for an end user.

This document describes the process of provisioning a Logging Integration between a CDN and an ISP in an Open Caching solution. That is the process of configuring how delivery logs are transferred from ISP to CDN. The requirements for logging in Open Caching Nodes are described in the “Open Caching Logging Requirements Specification” document. This document defines extensions to the “Footprint and Capabilities” interface and to the “Service Metadata” interface, to allow provisioning a Logging Integration.

This includes the functional specification of open-caching service provisioning interfaces enabling a CDN and an SP to exchange information to enable the delegation of CDN content requests to the SP Open Caching system.

High-level functional specification of open caching request routing and the required interfaces to enable request routing to be performed from an upstream CDN to an open cache system.

This document describes the functional specification of the Open Caching Content Management interface and the functionality requirements from the SP Open Caching system. This document discusses the interface between the SP Open Caching Controller and the CDN. The interface between the SP OCC and the cache nodes (OCNs) is beyond the scope of this document.

This document describes the functional specification of open-caching relayed-token-authentication mechanism. The focus is on generically supporting URI signing using this method. There are additional applications – like user Cookies, which are mentioned in this document without getting into the specifics. While multiple different CDNs, as well as CDNi, support Tokenization in alternative methods, the goal of this implementation is to support all of these different formats via the relay authentication mechanism.

This document outlines measurement metrics for open-caching. The focus of this document is to outline key performance indicators related to quality of service metrics at the open cache nodes that is responsible for delivering the streaming content.

The Home Storage Open Caching Node (HS-OCN) project adds functionality to the open caching system to further improve quality of experience (QoE) on networks with last mile challenges including speed limits (e.g. low speed DSL), usage limits (e.g. wireless), and last mile congestion (e.g. COVID quarantine). In the United States, almost 20 million households still have DSL or wireless Internet service. This number is larger worldwide. By leveraging storage in the home, end-users can have experiences with fewer rebuffer events, faster start times, and higher visual quality including UHD. At the same time as the QoE is improved, the amount of content which can be viewed is increased because the operator can reduce the peak period usage.

This is the first part in a set of documents that specifies the motivational drivers, use cases, and standards for a configuration interface to facilitate interoperability within the content delivery network (CDN) and open caching ecosystems. This document set presents a layered architecture that extends the Internet Engineering Task Force (IETF) CDN Interconnect (CDNi) metadata model and adds publishing layer Application Programming Interfaces (APIs) to provide configuration management capabilities required by the CDN and open caching industries.

This is the first part in a set of documents that specify the Streaming Video Technology Alliance (SVTA) Configuration Interface, defining both the metadata model and Application Programming Interfaces (APIs) for entities to publish and retrieve configuration metadata. This document specifies the motivational drivers, use cases, and standards to facilitate interoperability within the content delivery network (CDN) and Open Caching ecosystems. The full document set presents a layered architecture that extends the Internet Engineering Task Force (IETF) CDN Interconnect (CDNI) Metadata and Capabilities Models and adds publishing APIs to provide configuration management capabilities required by the CDN and Open Caching industries.

This is part two in a set of documents that specifies the motivational drivers, use cases, and standards for a configuration interface to facilitate interoperability within the content delivery network (CDN) and open caching ecosystem. This document presents the context and requirements for extending the Content Delivery Network Interconnection (CDNi) metadata model, as well as specific extensions that will fulfill those requirements. This document will provide all the necessary information for an Internet Engineering Task Force (IETF) memo describing the Streaming Video Alliance (SVA) metadata interface requirements beyond those stated in RFC-7337 (Content Distribution Network Interconnection Requirements), along with requested extensions to RFC-8006 (Content Delivery Network Interconnection Metadata).

The Internet Engineering Task Force (IETF) Content Delivery Networks Interconnection (CDNI) Metadata Interface enables interconnected content delivery networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. This document and its subparts describe extensions to the CDNI Metadata Object Model as documented in “CDNI Metadata” [RFC8006] to address the complex requirements of the commercial CDN industry and to support a wider set of use cases such as Open Caching.

This is part three in a set of documents that specifies the motivations, use cases, and standards for a configuration interface to facilitate interoperability within the content delivery network (CDN) and open caching ecosystems. In this document, the requirements for a configuration publishing layer are presented, along with APIs that facilitate the publishing of CDNi metadata objects within the CDN and open caching ecosystems.

This is part 3 in a set of documents that specify the Streaming Video Alliance (SVTA) Configuration Interface. This document presents the Simple Configuration Metadata API, which provides basic metadata retrieval and publishing capabilities, as introduced in SVTA Configuration Interface Part 1 Introduction & Architecture [SVTA2028].

This document specifies the syntax and provides usage examples for an expression language to be used within Streaming Video Technology Alliance (SVTA)/Content Delivery Network Interconnection (CDNI) Metadata Interface (MI) objects. The purpose of this expression language is to enable metadata to be applied conditionally (based on aspects of an HTTP request), and to enable Hypertext Transfer Protocol (HTTP) responses to be generated or altered dynamically.

This document specifies a set of objects extending the Content Delivery Network Interconnection (CDNI) metadata model [RFC8006] to allow for metadata to be applied conditionally and at various points in a dCDNs processing of requests. The concept of Processing Stages are introduced, where each stage in a CDN’s processing pipeline presents an opportunity to examine requests and responses and make alterations as needed. Metadata, such as caching rules, can be applied conditionally (based on aspects of an HTTP request header), and HTTP responses from a source can be altered dynamically (such as adding or dropping an HTTP header). This standard leverages the expression language documented in the Metadata Expression Language (MEL) Specification [SVTA2031].

This specification adds to the basic cache control metadata defined in [RFC8006], providing content providers and upstream CDNs (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the origin, bypassing caching altogether, or altering cache keys with dynamically generated values.

This specification provides an alternative to the MI.SourceMetadata objects defined in [RFC8006], providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin.

This specification adds to the basic client access control metadata in [RFC8006], providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels.

This specification defines configuration metadata objects related to controlling edge access to resources via content delivery networks (CDNs) and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules and client connection timeouts.

This specification adds to the core set of configuration metadata defined in [RFC8006], providing delivery metadata to define traffic types, Open Caching request delegation behavior for Open Caching node selection, and request routing modes of traffic delegation.

This specification defines a mechanism for downstream content delivery networks (dCDNs) to define private extensions to the metadata model that are mutually agreed upon between participating upstream content delivery networks (uCDNs) and dCDNs.

This document defines a simple mechanism for protected secret data (such as salt values or encryption keys) that may be embedded in configuration metadata or capabilities advertisements.

This specification introduces the Service Configuration Model, an object layer that wraps the HostMatch metadata defined in [RFC8006] with a construct defining content delivery network (CDN) Services and Properties (groups of hosts with shared metadata definitions), as well as reusable metadata definitions that can be used across all of a service’s CDN Properties. The Service Configuration Model represents a self-contained bundle of configuration metadata and definitions that can be published and deployed as an atomic unit without external references. This model is defined independently of any Application Programming Interface (API) and will be used as the basis for the Streaming Video Technology Alliance (SVTA) Orchestration API.

This document defines the requirements and model for a CDNI Footprint & Capabilities (FCI) object that allows a downstream content delivery network (dCDN) to advertise the configuration metadata capabilities that it supports. It goes beyond the simple FCI.Metadata object defined in [RFC80008] by providing fine-grained advertisements with allowed usage contexts and allowed values as well as advertisements for specific Metadata Expression Language (MEL) capabilities.

The Orchestration API provides full configuration metadata lifecycle management, with publishing and staged deployment as distinct operations, along with versioning and rollback capabilities. The API provides capabilities required by infrastructure orchestration tools such as Terraform and Ansible to issue the commands necessary to update a dCDN configuration to a desired state.

This document describes the Application Programming Interface (API) methods and data model related to the Footprint and Capabilities Interface. The API has been entirely designed by the SVTA Open Caching group whereas the data model is based on the IETF Content Delivery Network Interconnection (CDNi) work. and on extensions specified by the SVTA Open Caching group.

Content delivery delegation in open caching can be realized through two modes of request redirection, iterative and recursive.

Open caching previously supported the iterative mode only. This document describes the data model and architecture changes required to enable the recursive mode of delegation as well.

The SVTA Configuration Interface is a multi-part set of documents defining both the metadata model and Application Programming Interfaces (APIs) for entities to publish and retrieve configuration metadata for content caching and delivery.

This manifest specifies the SVTA document numbers and versions of each of the parts and subparts comprising a version of the Configuration Interface. Each individual document in the set is assigned a unique SVTA document number and is versioned independently. OpenAPI definitions as well as communications of compliance with this standard may make references such as Configuration Interface Version 2.0 or Configuration Interface Version 2.1. Those versions of this document manifest can be referenced to determine the SVTA document numbers and versions of the parts and subparts that comprise any given version of the Configuration Interface standard.

The two most common streaming formats for Adaptive Bitrate Streaming – Dynamic Adaptive Streaming over HTTP (DASH) and HTTP Live Streaming (HLS) – provide mechanisms for ads to be inserted into manifest files. However, there’s often a challenge to properly identify the unique ad asset(s) that are embedded in a manifest. This hampers efforts to ensure delivery and monitoring accuracy.

This document proposes a clear and interoperable signaling mechanism for the signaling of creative assets in DASH and HLS. It enables, for example, unique ad asset identifiers such as those from Ad-ID.org and/or unique in-house ad asset IDs to be captured in original or stitched manifest files.

In this document, a cross-functional working group committee reviews and responds to the HLS Content Steering Proposal 1.1b1 and the subsequent Redundant Stream Steering Proposal (RSS).

This document describes key network delivery metrics for streaming Internet video. The Streaming Video Alliance Quality of Experience (QoE) working group (WG) developed these metrics as a common language to describe effectiveness of network delivery. Although many more metrics could have been documented, these particular metrics represent the most common and important metrics according to the QoE WG group membership. It is expected that these metrics can be used across the streaming video ecosystem to provide guidance that can lead to enhancement of QoE.

The piracy of online video content is a significant issue for content owners and distributors. This document explains the technology of watermarking and how it can be employed, in various methods, to secure video against theft.

There are many different approaches to associating attributes to an IP address and many different attributes that can apply. There are also several different approaches to delivering that data. This document will focus on attributes that fall into three categories: Identity, Service, and Location. Identity can include a user’s name, the upstream service provider, an enterprise network, university, or department. Services can include attributes such as a W-Fi network, cable, wireless, infrastructure, and enterprise. Finally, location attributes can identify city, state, zip codes, country, region, or geocodes. A collection of attributes would form objects with their associated values, and these objects can be related to an individual IP address or a range of addresses to create an IP addressing object. These IP address objects can also be tied to an IP address object in a parent child relationship to provide as much detail as desired by the source. This document provides a JSON object model and schema to represent how those attributes can be tied to an IP address in a common format for controlling the access to streaming video using geo-location data for IPv4 and IPv6 addressing.

Note: access controls, privacy, and the management of privileged information (PII) will not be defined here and will be left to other efforts.

Advertisement insertion into OTT streams is a critical part of the overall user experience. Breakdowns in services or delivery can have a detrimental impact on viewer churn. To provide users with the best possible Quality of Experience (QoE), content publishers must take into account the advertising workflow with regards to quality, duration, delivery, and failure. The best practices presented in this paper, developed by a number of contributing companies in the Streaming Video Alliance’s Advertising Working Group, address a myriad of considerations for any OTT service provider that is considering the inclusion of advertising in their offering.

As the video streaming industry continues to mature, QoE expectations continue to rise in importance both as a value proposition to the consumer as well as a differentiator between competing video streaming services. Yet, consistent, systematic, standardized, objectively measured, and business-rules-driven QoE assurance continues to be an elusive goal. This document outlines factors that impact consumer QoE, sheds light on some of the underlying challenges to diagnosing QoE impact and provides a set of best practices for end-to-end QoE monitoring in video streaming workflows.

The ability to prevent piracy, take down illegal content, and act against illegal sources are key objectives of content protection. Meeting these objectives requires the use of a variety of technologies including watermarking, Digital Rights Management (DRM), fingerprinting, and cryptography. This document examines and discusses the streaming video system to provide best practices for protecting and securing streaming video content for both content providers and distributors to ensure content is being used as intended by those who it was intended.

This paper, originally published by SCTE ISBE, outlines a collaborative integration of manifest delivery, analytics, quality metrics, visual dashboard, and reporting methods while highlighting several demonstration use-cases. This proof-of-concept study will prove helpful for ad operations teams to enable a reliable Quality of Service (QoS) across streaming devices while validating advertiser’s investments.

Over-the-Top (OTT) video streaming is accelerating towards a tipping point where broadcasters are simulcasting their content to both OTT and traditional broadcast customers. This has raised concern with the latency delta between broadcast and OTT streams. In addition, new OTT use cases have emerged that demand the lowest possible latency. This paper explores techniques available to streaming video distributors to reduce the latency of their streaming content from encoder to screen.

The Streaming Video Technology Alliance Open Caching Application Programming Interfaces (APIs) are described in several documents, each related to a particular interface. This document is the starting point for anyone implementing these APIs. It describes the Open Caching model and includes modes of operations necessary for implementation.

This document identifies the vulnerability points inherent in streaming video players and proposes some of the industry best practices to ensure content is protected while not impeding viewer access or a high-quality viewing experience.

As more direct-to-consumer Over-the-Top (OTT) apps are making their way to the marketplace, it is helpful to provide a single checklist that contains a list of the security options in use by contemporary OTT services. This ensures that security options are taken into consideration every step of the way, from design and architecture, to development and test, and finally to live operation. This will also provide an understanding of potential security risks that may be presented when certain security options are foregone.

This document provides an end-to-end security checklist that an OTT service provider, technology vendor, and service developer can reference as they seek to improve content protection on OTT streaming services.