CDN Description

Print

1. Overview

This guide describes standard procedures required to set up main and optional CDNvideo network services. The procedures include step-by-step instructions and list necessary initial data. Overall architecture and major network components are described in the manual for a better understanding of the process of connection to services.

2. Network architecture and services

To provide services, CDNvideo uses its own content delivery network (Content Delivery Network, CDN). Functionally, CDNvideo network is composed of two domains: the core and content distribution servers.
Content distribution servers are installed in the locations with the highest concentration of end users. In general, the content is first aggregated in the CDNvideo network and then delivered to the end user from the nearest server. The term “closest” refers to the server that has the best integrated metric (an optimum server needs not be the closest geographically). Redirecting user’s requests to optimum content distribution servers is a responsibility of a redirector, which operates as described in Section 3. The redirector is a part of the network core and is actually a DNS-server where an intelligent software assistant that is operationally bound with the DNS service is launched. In the case of real-time online broadcasting (Live Streaming) the stream is first delivered to the publishing servers within the network core and then transmitted to the distribution servers.

“The main CDN purpose is to bring the content, primarily video, as closer to end users as possible.”

Basic CDN services are:

  • Live video streaming (Live Streaming). Allows to perform live video broadcasting of events for large Internet audiences.Broadcasting can go from a content provider server or directly from an IP-camera. Another area of the Live Streaming application is broadcasting of live TV channels over the Internet (implemented by almost every major television channel).
  • Distribution of audio streams
  • Video On Demand Streaming. Viewing video content at any time that is convenient to the end user. Viewing a video clip is possible from any time point without having to download the entire content.
  • HTTP caching. HTTP content is cached on servers on an as-needed basis and released from an optimum server at user request.

Optional CDN services are:

  • Authorization of access to the content.
  • Access to the network programming interface (API).
  • Screenshot generation.
  • Stream transcoding.
  • Over-the-air browsing (DVR).

3. User request redirection

Redirecting user requests to optimal distribution servers occurs at the DNS level. Distributable content should be available by domain names in the CDNvideo responsibility zone. To do this a domain name in the CDNvideo zone (e.g., customer.cdnvideo.ru), is allocated to the content provider. That name should be used when referencing the content. Access to the content by a domain name in the provider responsibility zone (e.g., cdn.customer.com), is also possible. In this case, the supplier should create on their DNS servers a CNAME (alias) resource record of the following kind:
cdn.customer.com. CNAME customer.cdnvideo.ru.

At the provider site, references are specified for distributed content, using the domain name in the CDNvideo responsibility zone (e.g., http://customer.cdnvideo.ru/goal.flv) or using the alias name specified in the CNAME record (e.g., http://cdn.customer.com/goal.flv). A simplified diagram for redirecting the requests is shown in Figure 1.

Схема перенаправления запросов

Redirection of user requests is performed by the redirector within the network core, while the result is an IP address of the chosen content distribution server. To choose the optimum distribution server an intelligent software assistant is used that handles multiple availability metrics and operates in conjunction with the DNS service. Continuous monitoring of server availability is carried out that prevents from redirecting of requests to an unavailable server.

4. Main Services

4.1 Live Video Streaming

4.1.1 Basic Principles

To carry out live broadcast, a stream should first be delivered to the CDNvideo publishing servers. A server, IP camera, notebook computer with special software and/or any other encoding device (encoder) can be a source of the broadcast. There are several ways to deliver the stream to the CDNvideo publishing server; the issue is addressed in more details in Section 4.1.3.
The stream will be copied, converted to the desired format and broadcasted to the end users fromthe optimal distribution nodes in the CDNvideo network. Broadcast is initiated upon request from theuser’s player to the content distribution server. No restrictions on the type of the user’s player is imposed.
Broadcast is possible in multiple bitrates that is addressed in more details in Section 4.1.4.
Upon initial configuring you will be provided with the URL of the page with a test player wherebroadcast of stream over the CDNvideo network may be evaluated.

Encoding Requirements

The stream to be published should meet the following requirements:

  • Video codec: H.264;
  • Audio codec: AAC or MP3.

Arranging the published stream with key frames is strongly recommended, particularly, a small fixed interval between key frames (1-2 seconds) should be specified in H.264 settings. For compatibility with most HTML5 players AAC codec should be used.

Stream publishing

Possible ways to publish stream in the CDNvideo network are:

  • RTMP-publish
  • RTMP-pull
  • RTSP-publish
  • RTSP-pull
  • MPEG_TS-publish
  • HTTP-pull

RTMP-publish
This is a preferable method of publishing. The encoder must support the RTMP protocol (e.g., Adobe FMLE, Apple QuickTime Broadcaster, ffmpeg). Two URLs (a primary and a backup) and the stream name with authorization token are allocated for publication. E.g.:
URL primary: rtmp://pub1.rtmp.test.cdnvideo.ru/test
URL backup: rtmp://pub2.rtmp.test.cdnvideo.ru/test
Stream: test.sdp?auth=261016ClEq

Backup URL should be used only if there is a sufficient transmission bandwidth.
The stream name in encoder settings must be specified together with the authorization token, otherwise the publishing attempt will be declined.
Recommended settings when using the Adobe FMLE software (for other encoders the situation is similar):

  • Format: H.264
  • Frame Rate: 30 fps
  • Input Size: 640×480
  • Bit Rate: 700 Kbps
  • Output Size: 640×480
  • Audio: 64k AAC mono 44100 Hz

In the case of broadcasting a single event in multiple bitrates simultaneously, up to 3 streams can be created on the “Encoding Options” tab by specifying a bit rate and output resolution for each of them. Stream names are arbitrary and are to be indicated in the “Stream:” string separated by a semicolon:
Example of specifying of several streams

The system requirements for Adobe FMLE can be found here:
Flash Media Encoder


RTMP-pull
This method can be used if there is a ready RTMP stream (origin). The URL of the stream of the following kind should be provided:
rtmp://origin.server/app/stream
Two URLs (a primary and a backup) can be specified. The CDNvideo server will be configured to draw and rebroadcast the stream.


RTSP-publish
This method can be used if the encoder supports stream publishing by use of the RTSP protocol (e.g., Apple QuickTime Broadcaster). Two URLs (a primary and a backup) are allocated for publication of the following kind:
rtsp://01.domain.cdnvideo.ru:PORT/domain-publish
rtsp://02.domain.cdnvideo.ru:PORT/domain-publish

Backup URL should be used only if there is a sufficient transmission bandwidth. A Login/Password pair is also allocated (to be requested when connecting to the publishing server). Stream can have any name.


RTSP-pull
This method can be used if the encoder (typically IP-camera) supports the RTSP streaming distribution protocol. The following conditions should be met in advance:

  • Availability of the encoder at the permanent public IP address;
  • The port 554/tcp should be available in the encoder for incoming connections.

The following information should be provided for configuration:

  • URL RTSP-источника;
  • Name of the stream, e.g., cam1.stream

Example of URL of the RTSP-source for Axis camera:
rtsp://login:secret@10.1.1.1:554/axis-media/media.amp
where the login: secret – – pair consists of login and password, respectively, for access to the camera. The URL should use the public IP address of the encoder.

The CDNvideo publishing servers will be configured to draw the stream at the specified URL


MPEG_TS-publish
This method is used to publish in the MPEG_TS over UPD format. The following information should be provided:

  • Number of streams to be published;
  • If you wish to name distributed streams, please, inform us of the name of each stream (e.g., «stream1», «stream2»). This is optional

Addresses of the two servers (primary and backup) are allocated for publishing, and a separate UDP port is assigned to each stream. For example:

  • Stream stream1, UDP-port 1111, IP: 1.2.3.4 primary, 2.3.4.5 backup
  • Stream stream2, UDP-port 2222, IP: 1.2.3.4 primary, 2.3.4.5 backup

Encoder should be configured to send the stream (streams) to the specified addresses and ports. Streams will be distributed under the specified names.


HTTP-livestream pull
This method can be used if there is a ready HTTP-based live streams:

  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS)
  • MPEG-DASH.

The URL of the stream of the following kind should be provided:

  • http://origin.server/app/stream/manifest.f4m;
  • http://origin.server/app/stream/playlist.m3u8;
  • http://origin.server/app/stream/Manifest;
  • http://origin.server/app/stream/manifest.mpd.

Stream is pulled from the origin server to CDNvideo distribution server at the first request of the user and served from CDN cache for subsequent requests. The object received by the distribution server is cached for a specified time:

  • Time for storing the object in the distribution server cache is determined by the HTTP headers Cache-Control (with a ‘max-age’ value) and Expires.
  • If these headers are not available, then, by default, time for storing the object in the cache is assumed by CDNvideo with the features and content of additional requirements.

For backup you can use multiple server source. With this method, repackage streams in a other formats and protocols is not possible.

Delivery to end users

The following protocols are applied for delivery to the end users:

  • RTMP/RTMPT;
  • RTSP;
  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS);
  • MPEG-DASH.

In case of problems with broadcasting of stream using the RTMP protocol toward users of corporate networks with strict security policies, it is recommended to consider the following options:

  • Broadcasting over the RTMP protocol, while a tcp/80 port typically in use by Web servers is actuated on the distribution server. Standard RTMP packets are transmitted. This method allows to bypass most filters
  • Broadcasting over the RTMPT protocol (RTMP tunneling over HTTP). RTMP traffic is encapsulated into HTTP, the distribution server sends out packets from the tcp/80 port. From the point of view of network firewall, such packets do not differ from standard Web traffic.

Broadcast using multiple bitrates is possible with the ability to switch between them in the player. Switch between bitrates manually or automatically in adaptive mode, depending on the player. In this case multiple bitrates for HTTP protocols (HLS/HDS/MSS/MPEG-DASH) can be combined within a single manifest file, that provides the ready-to-use solution for adaptive broadcasting.
Possible options for broadcasting in multiple bitrates:

  • A separate stream is published for each bitrate.
  • Single high quality stream is published that is converted into multiple bitrates at output. This option is implemented through use of the “Transcoding output streams” service, described in section 5.6.

Configuration procedure

1. A domain in the CDNvideo responsibility zone of the customer.cdnvideo.ru kind will be allocated to you for posting references to broadcasting. For this domain, you can create an alias (CNAME) record in your DNS responsibility zone of the cdn.customer.ru (optional).
2. Estimate the maximum number of concurrent viewers and assumed average bitrate and report these parameters to us to reserve transmission bandwidth (if assumed maximum number of concurrent viewers exceeds 1000).
3. Choose a method for publishing the stream and notify us. Depending on the method chosen we will request or provide information required.
4. Configure the encoder.
5. Check display of the broadcast on the page with a test player (we will provide the URL of the page).
6. Configure your player to display streams through the CDNvideo network.

4.2 Video On Demand Streaming

Basic Principles

On-demand streaming involves upload of files to the CDNvideo distribution server from the source server. File is uploaded in segments, as necessary, and, only in case of the absence of relevant segment, in the distribution server cache that is processing the user’s request. For example, upload of the file to the distribution server will begin when the first user’s request is sent to this server. HTTP protocol is used for uploading, the received segments are stored in the distribution server cache and used when users are accessing subsequently.
Requirements for source files: container type:

  • FLV;
  • MP4.

Requirements for source files: codeсs:

  • Video codec – H.264;
  • Audio codec – AAC or MP3.

Delivery to end users

The following protocols are applied for broadcasting to end users:

  • RTMP/RTMPT;
  • RTSP;
  • HTTP (pseudo-streaming, see in more detail in section 4.2.3);
  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS).

In case of problems with video broadcasting using the RTMP protocol toward users of corporate networks with strict security policies, it is recommended to consider the following options:

  • Broadcasting over the RTMP protocol, while a tcp/80 port typically in use by Web servers is actuated on the distribution server. Standard RTMP packets are transmitted. This method allows to bypass most filters.
  • Broadcasting over the RTMPT protocol (RTMP tunneling over HTTP). RTMP traffic is encapsulated into HTTP, the distribution server sends out packets from the tcp/80 port. From the point of view of network firewall, such packets do not differ from standard Web traffic.

Pseudo-streaming

Our network supports pseudo-streaming of video files over HTTP protocol with ability to seek within the file (“rewinding”). Support of the seek feature also needs to be available in user’s player.
The first variant of implementing the seek feature is by use the start argument in the query string. Start time is specified in seconds. An example of the requested URL:
http://customer.cdnvideo.ru/filetoplay.mp4?start=300

Supported video containers for such variant are MP4 and FLV; the extensions .FLV or .MP4, respectively, should be used in the file names.
The second variant of implementing the seek feature is requesting the byte ranges of the file (byte-range requests); there are no special requirements for the video format in this case
Regardless of the implementation variant, the files should be prepared for pseudo-streaming. Firstly, key frames should be inserted properly when encoding; fixed 1-2 second range is recommended. Secondly, metadata should be put at the beginning of the file. You can find more information on file preparation at the following links:
http://flash.flowplayer.org/plugins/streaming/pseudostreaming.html#prepare
http://nginx.org/ru/docs/http/ngx_http_mp4_module.html

Both variants support the file download speed limit option that allows to control the amount of transmitted traffic. By default, the download speed is not limited.

Configuration procedure

1. A domain in the CDNvideo responsibility zone of the customer.cdnvideo.ru kind will be allocated to you for posting references to content. For this domain, you can create an alias (CNAME) record in your DNS responsibility zone of the cdn.customer.ru (optional).
2. Estimate and tell us the total amount of content.
3. Provide the URL of the content source (e.g., http://origin.customer.ru/video/).
4. If pseudo-streaming is used, identify the need to limit the file download speed, and specify the limit value, should the case be. By default, the download speed is not limited.
5. Upon receiving confirmation from the technical support service, please, verify that video is displayed on a test site/domain correctly.
6. Configure your player to display streams through the CDNvideo network.

4.3 Audio streams distribution

Basic Principles

Our network supports three options for serving the audio streams to end users:

1. Broadcasting in the Internet radio station format using the Icecast protocol. All standard features of the Icecast protocol are available. The source audio stream should be initially published on the SHOUTcast/Icecast-server, which will be the source for the CDNvideo distribution servers.
Warning: We do not provide server for initial publication, the client is responsible for selection of the server for initial publication.

2. Broadcasting source is in Icecast format, broadcast to end users over the RTMP, RTSP, HDS, HLS,MPEG-DASH protocols
Warning: The Microsoft Smooth Streaming Protocol does not support the audio-only streams.
Supported codecs: AAC, AAC-LC, HE-AAC (aacPlus), MP3. In this case the initially published Icecast-stream is taken (similar to the first option) and converted to the appropriate format.

3. Publishing the audio-only streams using standard means (RTMP, RTSP, MPEG-TS), as described in section 4.1.3. Broadcasting to end users over RTMP, RTSP, HDS, HLS, MPEG-DASH.
A domain in the CDNvideo responsibility zone of the customer.cdnvideo.ru kind will be allocated to you for posting references to broadcast. For this domain, you can create an alias (CNAME) record in your DNS responsibility zone of the cdn.customer.ru (optional).
The statistics of current connections to audio streams is available through API, for more detailed information please see sections 5.3.1. and 5.3.2.

Configuration procedure (Variant 1)

1. Please provide us with the URL of the stream on the SHOUTcast/Icecast source server. Example of the URL: http://icecast.abc-customer.ru:8000/
2. Check the audio broadcast on the page with the test player (we will provide the URL of the page).
3. Configure your player to present the audio streams through the CDNvideo network. The final reference to the stream that is used to broadcast through our network will look like this: http://icecast.customer.cdnvideo.ru:8000/stream_name

Configuration procedure (Variant 2)

1. Please provide us with the URL of the stream on the SHOUTcast/Icecast source server. Example of the URL: http://icecast.abc-customer.ru:8000/
2. Check the audio broadcast on the page with the test player (we will provide the URL of the page).
3. Configure your player to present the audio streams through the CDNvideo network.

Configuration procedure (Variant 3)

1. Please select a stream publish method and let us know. Depending on the method chosen we will provide additional information.
2. Configure your encoder.
3. Check the audio broadcast on the page with the test player (we will provide the URL of the page).
4. Configure your player to present the audio streams through the CDNvideo network.

4.4 HTTP caching

Basic Principles

HTTP content is referred to static images, HTML files, CSS, Java-scripts, video files and other objects used in creating websites. Basic principle is that the content is cached on servers on an as-needed basis and released from the optimum server at the user’s request. Not only the data, but the object itself and its associated HTTP headers are stored when caching.

Content is uploaded according to the HTTP protocol to the distribution server cache from the source server at the first request of the user and is used for serving the subsequent requests. The object received by the distribution server is stored in the cache for a specified time (please see section 4.4.3. for details). When the cache is full the object is substituted on a rotational basis, i.e. the least popular objects are replaced first. Repeated upload from the source occurs only when there is no the requested object in the distribution server cache.

Caching algorithm

Features:

  • Only selected objects are cached;
  • References at the website should be changed for cached objects.

How it works. Let’s assume that there is a picture with full URL like www.mycompany.com on your website http://www.mycompany.com/images/logo.gif. A domain name like customer.cdnvideo.ru will be assigned to you for modification of the domain part of the references to cached objects. Thus, a new reference to the picture will look like this:
http://customer.cdnvideo.ru/images/logo.gif
Please note that the relative path of the object has not been changed. User access to such object at the website will go to one of the distribution servers. If it was the first access, the object will be requested from the source server, released to the user and stored in the cache for subsequent requests.
Note:In order to change the domain part of the links to the cached objects quickly, some CMS provide a mechanism for automating the process. It is necessary to find a function that is responsible for an indication of the ways to the site objects. Let us look at the example of a mechanism of automation on WordPress SEO plugin:

1. For example, change the path to all images in the Sitemap file. In order to do this, go to the section Appearance​ in WordPress and click on the “Editor”​.
wordpress

2.Open the functions.php​ file and place the following code at the bottom (save the original functions.php, if you are not familiar with editing the file) with your domain:
function wpseo_cdn_filter( $uri ) {
return str_replace( ‘http://yourdomain.ru’, ‘http://cdn.yourdomain.ru’, $uri );
}
add_filter( ‘wpseo_xml_sitemap_img_src’, ‘wpseo_cdn_filter’ );

3. Then click on Sitemap in the plugin, right-click “View source”​ in your browser, and make sure that all the paths to the images on your website are pointed to the CDN.
4. The same method should be applied to other objects on your site.

Caching time managing

Time for storing the object in the distribution server cache is determined by the HTTP headers Cache-Control (with a ‘max-age’ value) and Expires. Headers should be set on the source server; it is sufficient to specify only one of them. The simultaneous use of both headers is not prohibited, though it is redundant; in this case, make sure that their values do not contradict each other. If these headers are not available, then, by default, time for storing the object in the cache is assumed to be 24 hours. Particular attention should be paid to the correct setting of the HTTP headers in the case of dynamically changing content, as it directly affects validity of the version of the object that is stored in the cache.
High level of relevance of dynamic content can be achieved by use of using the CDNvideo network API to delete certain objects from the cache of all content distribution servers. In this case, the object will be uploaded from the source again when the user accesses for the first time. Clearing the cache is described in more details in section 5.3.2.

Processing the query string

When serving the objects with URLs containing the parameter string (query string) of the kind:
http://server/path/program?query_string

Please note that by default, when caching such an object, the ‘query string’ is deleted form the HTTP header Request URI. On subsequent requests the first cached object with such an URL will be issued to the user without considering for the ‘query string’ value in the query. If such a mode of operation is unacceptable for you and the ‘query string’ should be saved in the URL, please, let us know and we will activate this option.

Robots.txt file

The robots.txt file is designed for search engine robots. Our network supports three options of the file usage:

  1. We use our own robots.txt, which prohibits all cached content to all search robots. This option is set by default.
  2. We proxy your robots.txt from origin server without any changes.
  3. We use custom robots.txt that you send us.

In order to prevent multiple indexing content, we use Option 1 by default. Nevertheless, in some cases (e.g., when caching CSS and scripts), using Option 1 can lead to undesirable effects which can result in loss of position of the site in search results. In this case, it would be better to use Option 2 or 3. The final decision is up to you, based on the structure of the site and the nature of the cached content.
Yandex and Google recommendations are available on the links:
Yandex
Google

CORS headers

In certain cases, the request for content placed on the CDN is regarded as a cross-domain request by the browser and can be blocked, especially this applies to the fonts. The problem can be solved by setting up CORS (Cross-Origin Resource Sharing) headers for cached objects. There are two options:
1. You set up CORS headers on the origin server by yourself.
2. We add Access-Control-Allow-Origin CORS header in our system. We set up the header according to your requirements. Access-Control-Allow-Origin: * header is set by default and allows you to open resources from any domain.

Please inform us if you have selected the second option, as the CORS headers for cached object are not added by default.
You can read the detailed information about CORS headers by clicking the following link:
enable-cors.org

TLS/SSL servic

We offer TLS/SSL service for web resources that are using HTTPS connections. HTTPS is an updated version of the HTTP protocol that transfers web traffic encrypted. The transmitted date is protected from audio interception (confidentiality) and substitution (integrity). Furthermore, the identity of the server is verified (server authentication), when establishing HTTPS connections. In order to establish HTTPS connection TLS protocol is used, which was formerly known as SSL. Hereinafter, we use TLS term.
The important condition of TLS performance is the availability of digital certificate on the server. There are two options of certificate usage in our network and the option choice depends on what domain name you use for the cached content.
The first option is when the cached content is in the *.cdnvideo.ru area. We use our own certificate signed by one of the trusted international certification authorities (CA), the certificate details can be discussed with our technical support. CDNvideo certificate has already been placed on all the servers of our content delivery network, no additional steps are required. Please note that our certificate is valid only for third-level domains. The certificate does not support forth- and following level domains.
domain customer.cdnvideo.ru – OK!
domain static.customer.cdnvideo.ru – FAIL!

CDNvideo certificate usage

The second option is when the cached content is located in your domain area with CNAME usage. The corresponding private key and your certificate signed by a trusted CA are used. We will need two files from you to place them on all the CDNvideo servers:
A digital certificate in PEM format, usually the file has .crt extension. The certificate must be valid, signed and recognized by a trusted CA with unexpired date and valid domain name that matches CNAME. Check these conditions in advance. If you have doubts, send a certificate to our technical support for verification.
Certificate private key in PEM format, usually the file has .key extension. Do not use passphrase when generating the key, we will not able to use this key!

Your own certificate usage

Example of selection options:
Content in customer.cdnvideo.ru zone – use CDNvideo certificate.
Content in static.yourcompany.com zone – use your own certificate.

In our network TLS termination means that a secure connection is established between the user and CDNvideo distribution server. Usually the standard HTTP protocol is used between distribution servers and the origin server and in most cases it is enough. If you need to use TLS in “distribution server – origin” area, make sure that the origin server has a valid certificate signed by a trusted CA.

5. Optional services

Stream access authorization

The service is applicable for both live streaming and VOD. Authorization is supported for all protocols that are available in our network: RTMP, RTSP, HLS, HDS, MSS, MPEG-DASH. Two authorization mechanisms are provided:

1. External authorization when the decision on access to the stream is made by means of the content owner.
2. Local authorization, when a decision on access to the stream is made by means of our network on the basis of criteria designated by the content owner.

External authorization

In such case, the authorization of requests to streams occurs outside the CDNvideo network, for example, by using the authorization script on the side of the content owner.
Each time a user accesses a protected stream, the CDNvideo Server sends the HTTP request HEAD to the authorization script on the side of the content owner. The following parameters are
transmitted in the request headers:
x-cdn-method : type of requested stream;
x-cdn-stream-name : name of requested stream;
x-cdn-client-ip : user IP address;
x-cdn-query : authorization parameters of the request; in the case of HTTP it is queryString, in the case of RTMP it is NetConnect arguments specified after the ‘?’ character;
x-cdn-uri : URI of the stream;
x-cdn-referrer : URL of the Flash-Player (Flash only);
x-cdn-user-agent : user’s player name and version;
x-cdn-page-url : URL of the page containing Flash-Player code (Flash only);
x-cdn-session-id : session ID;
x-cdn-event : event.

Possible values for the x-cdn-method header:
flash : Adobe Flash Player/RTMP;
http : HTTP-protocols(HDS, HLS, MSS);
rtp : RTSP

Possible values for the x-cdn-event header:
play : request for the stream playback;
publish : request for the stream publishing (RTMP only).

The content owner can generate references by specifying authorization parameters after the ‘?’ character that will be transferred in the x-cdn-query header. Below is an example for RTMP:
rtmp://flash.cdnvideo.ru/live?auth_id=13211
Stream name: stream.sdp

Summarizing, for the reference cited as the example, the headers can be as follows:
x-cdn-method: flash
x-cdn-stream-name: stream.sdp
x-cdn-client-ip: 212.2.11.117
x-cdn-query: auth_id=13211
x-cdn-uri: rtmp://flash.cdnvideo.ru/live
x-cdn-referrer: http://www.cdnvideo.net/aloha/wowza-examples/LiveVideoStreaming/client/live.swf
x-cdn-user-agent: MAC 10,1,85,3
x-cdn-page-url: http://www.cdnvideo.net/aloha/wowza-examples/LiveVideoStreaming/client/live.html
x-cdn-session-id: 921547595
x-cdn-event: play

In response, the CDNvideo server is awaiting the HTTP response with a status of ‘200 OK that contains the following headers:
x-cdn-status-int : result of the authorization;
x-cdn-status-text : text description of the response;
x-cdn-msg : text for transmission of error to Flash Player (only Flash/RTMP).

Possible values for the x-cdn-status-int header:
0 : access is allowed;
1 : access is denied.

Example of an allowing answer:
x-cdn-status-int: 0
x-cdn-status-text: OK

Example of a denying answer:
x-cdn-status-int: 1
x-cdn-status-text: Access forbidden, auth_id not exist.

To configure authorization, the URL of an external script should be provided.
A simplified diagram for successful authorization is presented in Figure 5.
A simplified diagram for successful authorization

Local authorization

In this case, the user request authorization is done exclusively on the CDNvideo network; external resources are not used.
At the time when the user is requesting protected resource the content owner should create a special reference. Example for RTMP:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516

The reference contains two authorization parameters:
‘md5=’ – is a MD5 hash in Base64 format for URL that is generated based on the URI of the requested resource, lifetime of the reference, secret key, user’s IP address (optional);
‘e=’ – is time of reference expiration in the POSIX time format.

When accessing the stream using the generated reference CDN calculates the MD5 value and compares it with the received value. If the values do not match or the current time is greater than the “e” value, a response code ‘403 Forbidden’ (playback is denied) is returned to the user.

An algorithm for calculating the MD5 hash using the user’s IP address as one of the input parameters is as follows:
md5 = base64_url(md5(SECRET:1382106248:1.2.3.4:/app_name/stream_name.sdp))

Please note that the domain part of the URI while computing the hash is not used!

Example of URL generation:

1. The following input data is available:
secret key: zah5Mey9Quu8Ea1k
IP address of the user: 1.2.3.4
URI of the resource for RTMP: RTMP:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4

2. Calculation of the timeline of reference validity. In the above example it is a week from the time of generation.
php -r ‘print time() + (7 * 24 * 60 * 60) . “\n”;’
1387984516

3. Calculation of the MD5 hash in Base64 format for URL:
php -r ‘print str_replace(“=”, “”,strtr(base64_encode(md5(“zah5Mey9Quu8Ea1k:1387984516:1.2.3.4:/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4”, TRUE)), “+/”, “-_”)) . “\n”;’
xs1YG76uMJF2kfkpg_cRlg

4. Resulting reference:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516

Important note: MD5 hash computed for RTMP is the base for this resource. That is, the same hash will be used for references to the video clip by RTMP, RTSP, HLS, HDS, MSS, MPEG-DASH protocols in spite of the fact that the URIs for different protocols may differ slightly. Once again –a) hash for all references to this file will be the same; b) hash is computed based on the URI for RTMP. For the example shown the HLS-reference will look like this:
http://customer.cdnvideo.ru/mc10/_definst_/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4/playlist.m3u8?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516

Please note that despite that the URI differs, the MD5 hash is the same as for RTMP.
In local authorization the following parameters are controlled:
1. URI of the resource being requested. It is verified whether the reference was established for exactly this stream.
2. Secret key. It is verified whether the reference is established exactly by the content owner.
3. Expiration time of reference validity.
4. IP address of the user (optional). It is verified whether the stream is requested exactly from the IP address for which the reference was established.

Moreover, other parameters of the user request may be verified too:
1. Geographical affiliation of the user (IP-based) broken down in detail to the level of the city.
2. URL of the page containing Flash-Player code (Flash only). Allows to control on which sites the player code can be placed.
The following information should be provided for settings:
1. secret key;
2. the MD5 calculation option (with or without user IP address);
3. the need to perform authorization using the additional settings (GeoIP, binding to domains).

HTTP content access authorization

Two methods for restricting access to the HTTP content are implemented:
1. External authorization by referring the script at the content supplier’s side. This method is good for static content (large files), but we emphasize that it is not recommended for dynamically generated content – HLS, HDS, MSS, MPEG-DASH files (chunks and manifests).
2. Local authorization that implies checking at MD5-hash distribution servers and the reference expiration time. This is a recommended method for authorization of HLS, HDS, MSS, MPEG-DASH content. It also suits statics well.

External authorization

Entire protected content is allocated to a separate directory on the content supplier’s source server, for example:
http://origin.client.ru/secure/
Access to this directory should be allowed only to the CDNvideo servers (We will provide IP addresses). This directory is excluded from access through direct references of http://client.cdnvideo.ru/secure/file kind.

The protected files may be delivered through mandatory testing by special reference with the authorization parameters, for example:
http://client.cdnvideo.ru/secure/path/to/file?parameter=value

The references are generated by the content provider. When receiving such request, the distribution server queries by proxy to the authorization script on the content provider’s side. The following headers are added to the query:
X-Real-IP : IP-user address;
X-CDN-Query : requested URI.

For example:
X-Real-IP: 1.2.3.4
X-CDN-Query: /secure/file.mp4?parameter=value

Authorization script should check validity of the request and return the HTTP response:
Response with code 403 or 401 denies access;
Response with code 200 allows access.

Information to be provided by the content provider for configuring the external authorization:
Path to the directory with the protected web-content on the source server;
URL of the authorization script.

Local authorization

All protected content is separate out into an individual directory on the source server, for example:
origin.client.ru/secure/

Access to this directory should be allowed only to CDNvideo servers (We will provide IP addresses). The directory is excluded from access through direct references of http://client.cdnvideo.ru/secure/file kind. Protected files are released through mandatory testing by a special reference with the authorization parameters, for example:
http://client.cdnvideo.ru/secure/file.mp4?md5=TJwAm-lsft38vJEdDh-Kbg&e=1306830000

The URL contains two authorization parameters:
md5 – MD5-hash that is generated on the basis of URI, lifetime and secret key.
e – is the time of reference expiration (in the POSIX time format).

The algorithm for calculating the MD5 hash can also use the IP address of the user as input data. An example of calculating the MD5-hash without use of IP address:
md5 = base64_url(md5(SECRET:1306830000:/secure/file.mp4))

An example of calculating the MD5-hash using IP address:
md5 = base64_url(md5(SECRET:1306830000:1.2.3.4:/secure/file.mp4))

Example of generating MD5 hash using PHP:
php -r ‘print str_replace(“=”,
“”,strtr(base64_encode(md5(“SECRET:1306830000:1.2.3.4:/secure/file.mp4”, TRUE)),
“+/”, “-_”)) . “\n”;’
TJwAm-lsft38vJEdDh-Kbg

The resulting reference would be as follows:
http://client.cdnvideo.ru/secure/file.mp4?md5=TJwAm-lsft38vJEdDh-Kbg&e=1306830000

Information needed to set up the local authorization:
path to the directory with the content to be protected on source server;
secret key;
MD5 calculation algorithm (with or without use of IP address).

For dynamically generated content – HLS, HDS, MSS, MPEG-DASH – similar procedure is used, but with some differences. First, it is not necessary to allocate the content into separate directory. Second, immutable part of URI is used when calculating MD5. Let’s consider HLS example. Query of HLS resource initiates serial access of the player to master playlist, chunk list and, finally, media chunks:
http://hls.client.cdnvideo.ru/app1/stream1/playlist.m3u8
http://hls.client.cdnvideo.ru/app1/stream1/chunklist.m3u8
http://hls.client.cdnvideo.ru/app1/stream1/media_40.ts
http://hls.client.cdnvideo.ru/app1/stream1/media_41.ts
Immutable part of the URI: /app1/stream1/

Each content unit will pass through authorization process – playlists, chunk lists and media chunks.

5.3 CDNvideo API

The programming interface allows to view the statistics and status of streaming video distribution, view and clear the HTTP cache on distribution servers.

The CDNvideo API has two authorization methods:

  • Access token (see Sections 5.3.1, 5.3.2). For view the statistics and status of streaming video (see Sections 5.3.3, 5.3.4)
  • IP whitelist. For view and clear the HTTP cache on distribution servers (see Sections 5.3.5, 5.3.6). To use, send a list of allowed ip

Get access token

Access token is used to request API statistics and status of streaming video distribution (see Sections 5.3.3, 5.34). Access token lifetime is 6 hours, a new access token don’t rewrite still alive access tokens and have personal lifetime. A template for the request is:

Method: POST
POST-params: username,password
URL: https://api.cdnvideo.ru/app/oauth/v1/token/

An example of query execution: $ curl -s -d “username=testuser@testemail.ru&password=test” “https://api.cdnvideo.ru/app/oauth/v1/token/” {“person_id”: 65745670, “status”: 200, “token”: “cdn1_VGO1T5G11785ODJZP4VJ260ZI4V7FP”}

The response body will contain:
person_id: personal client id
status: HTTP status code
token: access token

Access token should be provided in cdn-auth-token HTTP header to request API statistics and status of streaming video (see Sections 5.3.3, 5.34). The user and password fields must contain email and password that are used to access the CDNvideo personal account. If you do not have a personal CDNvideo account, please contact your manager.

Get account list

List of accounts available for the current person_id. The uid account is used to request API statistics and status of streaming video distribution (see Sections 5.3.3, 5.34). A template for the request is:

Method: GET
URL: https://api.cdnvideo.ru/app/inventory/v1/accounts

An example of query execution:

$ curl -H ‘cdn-auth-token:cdn1_VGO1T5G11785ODJZP4VJ260ZI4V7FP’
‘https://api.cdnvideo.ru/app/inventory/v1/accounts’
[{“uid”: “1-1-test”, “name”: “test”}, {“uid”: “1-1-cdntest”, “name”: “cdntest”},]

The response body will contain:
uid: the unique identifier of the account
name: account name

To search for an individual object in the distribution servers’ cache a list1 command is used. This command checks for availability of the object in the cache of at least one of the distribution servers. For a file with the URL of the http://origin/path/to/file.jpg type on the source server the query template looks as follows:
http://api.cdnvideo.ru:8888/0/list1?id=num_name&type=http&object=http://origin/path/to/file.jpg

A value of the ID allocated to you shall be indicated in the id field of the real query. The HTTP 200 OK response sends over a X-cdn-command header that contains information on the status of the command execution with value range from 0 to 9. A non-zero value indicates an error of execution.

An example of successful command execution:
HTTP/1.1 200 OK
X-cdn-command: 0

The result of the command execution is sent within the body of the response. When the object available in the cache of one or more (or all) distribution servers the response body contains the URL of the object.
An example of executing the list command for the http://test/7/5/4/754_45966.flv object, where the client’s ID is 01_test, the object being found in the cache:
curl -v ‘http://api.cdnvideo.ru:8888/0/list1?id=01_test&type=http&object=http://test/7/5/4/754_45966.flv’
< HTTP/1.1 200 OK < X-cdn-command: 0 { "01_test": { "http": { "object": [ { "name": "http://test/7/5/4/754_45966.flv" } ] } } }

To perform object search with the QueryString, all “&” symbols after “?” should be replaced by “%26”. Example:
will not be activated:: curl -v ‘http://api.cdnvideo.ru:8888/0/list1?id=01_test &type=http&object=http://www.shop.test.ru/pictures/image.php?width=427&height=500&image=/upload/mediabank/619602-106/front_belyy.jpg’
will be activated:: curl -v ‘http://api.cdnvideo.ru:8888/0/list1?id=01_test &type=http&object=http://www.shop.test.ru/pictures/image.php?width=427%26height=500%26image=/upload/mediabank/619602-106/front_belyy.jpg’

Statistics and status of streaming video

The API allows to get the current number of connections to streams. Origin streams can be published in CDNvideo network with the usage of streaming protocols (see Section 4.1.3) or proxied from the HTTP origin . A template for request is:

curl -H ‘cdn-auth-token:TOKEN’
‘https://api.cdnvideo.ru/app/streamstat/v1/accounts/UID/activesessionsummary’

The TOKEN and UID fields must contain real access token (see Section 5.3.1) and real uid account (see Section 5.3.2.).

An example of query execution:

$ curl -H ‘cdn-auth-token:cdn1_VGO1T5G11785ODJZP4VJ260ZI4V7FP’
‘https://api.cdnvideo.ru/app/streamstat/v1/accounts/1-1-cdntest/activesessionsummary’

The body of the response contains a list of current connections for each of the published stream broken down by protocols:

{
“streams”: {
“test/_definst_/airstream0012” : {
“sessionsFlash” : 91,
“sessionsTotal” : 91
},
“test/_definst_/airstream0011” : {
“sessionsFlash” : 34,
“sessionsHLS” : 31,
“sessionsTotal” : 65
}
}

Protocols:

SanJose HDS
Smooth Microsoft Smooth Streaming
Flash RTMP
RTSP RTSP
Icecast Icecast
HLS HLS

Detailed list of current connections to streams

List of connections to streams with the detailed information on each connection. Query template:

curl -H ‘cdn-auth-token:TOKEN’ ‘https://api.cdnvideo.ru/app/streamstat/v1/accounts/UID/activesessiondetail’

The TOKEN and UID fields must contain real access token (see Section 5.3.1) and real uid account (see Section 5.3.2.). An example of query execution:

$ curl -H ‘cdn-auth-token:cdn1_VGO1T5G11785ODJZP4VJ260ZI4V7FP’
‘https://api.cdnvideo.ru/app/streamstat/v1/accounts/1-1-cdntest/activesessiondetail’

The body of the response contains a list of current connections to steams:


{
“streams” : {
“live/_definst_/stream1” : [
{
“SessionType” : “HLS”,
“SessionId” : “7a8899e2a72573593c415e8d1c892728”,
“UserId” : “50f8c986a2c4ec4e12f2438d719549a5”,
“IpAddress” : “151.33.12.11”,
“UserAgent” : “HLS Client/2.0 (compatible; LG NetCast.TV-2012)”
},

],
“stream2” : [
{
“SessionType” : “Icecast”
},

],

}
}

To identify user/session you can use all fields, particularly, SessionId, UserId, IpAddress, UserAgent.

Checking HTTP cache

To search for an individual object in the distribution servers’ cache a list1 command is used. This command checks for availability of the object in the cache of at least one of the distribution servers. For a file with the URL of the http://origin/path/to/file.jpg type on the source server the query template looks as follows:

http://api.cdnvideo.ru:8888/0/list?id=num_name&type=http&object=http://origin/path/to/file.jpg

A value of the ID allocated to you shall be indicated in the id field of the real query.

The HTTP 200 OK response sends over a X-cdn-command header that contains information on the status of the command execution with value range from 0 to 9. A non-zero value indicates an error of execution.

An example of successful command execution:
HTTP/1.1 200 OK
X-cdn-command: 0

The result of the command execution is sent within the body of the response. When the object available in the cache of one or more (or all) distribution servers the response body contains the URL of the object.

An example of executing the list command for the http://test/7/5/4/754_45966.flv object, where the client’s ID is 01_test, the object being found in the cache:


curl -v ‘http://api.cdnvideo.ru:8888/0/list?id=01_test&type=http&object=http://test/7/5/4/754_45966.flv’
< HTTP/1.1 200 OK < X-cdn-command: 0 { "01_test": { "http": { "object": [ { "name": "http://test/7/5/4/754_45966.flv" } ] } }

To perform object search with the QueryString, all “&” symbols after “?” should be replaced by “%26”. Example:
will not be activated: curl -v ‘http://api.cdnvideo.ru:8888/0/list1?id=01_test
&type=http&object=http://www.shop.test.ru/pictures/image.php?width=427&height=500&image=/upload/mediabank/619602-106/front_belyy.jpg’
will be activated: curl -v ‘http://api.cdnvideo.ru:8888/0/list1?id=01_test
&type=http&object=http://www.shop.test.ru/pictures/image.php?width=427%26height=500%26image=/upload/mediabank/619602-106/front_belyy.jpg’

Clearing HTTP cache

To delete an individual object from CDNcache delete command should be used. For a file with the URL of the http://origin/path/to/file.jpg type on the source server the query template looks as follows: http://api.cdnvideo.ru:8888/0/purge1?id=num_name&type=http&object=http://origin/path/to/file.jpg

A value of the ID allocated to you should be specified in the id field of the query.
The HTTP 200 OK response sends HTTP headers:
X-cdn-command header that contains information on the status of the command execution with value
range from 0 to 9. If value equals to zero, it means that the object was successfully deleted from cache of
all distribution servers. A non-zero value indicates a runtime error.
X-cdn-command-id header contains command ID task queue.
X-cdn-comment header that contains a text comment can be sent too.

An example of the response after successful deleting of the object:
HTTP/1.1 200 OK
X-cdn-command: 0
X-cdn-comment: OK
X-cdn-command-id: aa29e3a8-e711-11e6-9af6-00259006bb2eX-cdn-comment: OK

An example of unsuccessful command execution:
HTTP/1.1 200 OK
X-cdn-command: 1
X-cdn-comment: Fail. Retry later.

An example of deleting the http://test/7/5/4/754_45966.flv object from cache of all distribution servers (command purge1), with customer ID of 01_test:
curl -v ‘http://api.cdnvideo.ru:8888/0/purge1?id=01_test&type=http&object=http://test/7/5/4/754_45966.flv’
>
< HTTP/1.1 200 OK < X-cdn-command: 0

To delete all the objects from CDN cache (complete purge of the cache) a delete command has to be used with special parameter object=*. The query template looks as follows:
http://api.cdnvideo.ru:8888/0/purge?id=num_name&type=http&object=*

A value of the ID allocated to you shall be indicated in the id field of the real query.
Response format and header values are the same as for the delete command.

To delete objects with the QueryString, all “&” symbols after “?” should be replaced by “%26”. Example:
Bad encoding:: curl -v ‘http://api.cdnvideo.ru:8888/0/purge1?id=01_test &type=http&object=http://www.shop.test.ru/pictures/image.php?width=427&height=500&image=/upload/mediabank/619602-106/front_belyy.jpg’
Good encoding:: curl -v ‘http://api.cdnvideo.ru:8888/0/purge1?id=01_test &type=http&object=http://www.shop.test.ru/pictures/image.php?width=427%26height=500%26image=/upload/mediabank/619602-106/front_belyy.jpg’

Download of statistics logs using of get_log.py software

Download the script​

1. service​ – filter log records by type
Possible values:

  • static​. Only static files (mp3, jpg, …) Such data are represented in tab “Web-content load acceleration” in the Statistics web interface.
  • media Only streams (HLS, ..) Such data are represented in tab “Live streaming and VOD” in the Statistics web interface​.
  • all Represents static + media. Such data are represented in tab “Total” in the Statistics web interface​.

2. date​. Defines the date filter for log records. The log can be uploaded with hour accuracy.
Warning: time parameter is specified in GMT
Possible values:

  • 2013​. A log for 2013 is downloaded.
  • 2013-12. A log for December 2013 is downloaded.
  • 2013-12-23. A log for December 23, 2013 is downloaded.
  • 2013-12-23-04. A log for December 23, 2013, as of 4 A.M. GMT is downloaded.

The script write a stream of gzipped logsto stdout.

Installation

1. Install pip (example of installation at RHEL, CentOS, Fedora): sudo yum install python-pip
2. Install a library of requests: pip install requests
3. Put get_log.py in respective directory

Settings

Open get_log.py script with any text editor and fill out all fields account_name, username, password:
1. username, password – login/password pair at login
2. account_name – account name in the user account

Execution

The software is a simple console python-script that accepts 2 arguments: service and date (Please see the details in the section above). It outputs a stream in gzip format

Possible usage scenario:
1. Download a log of static files for December of 2013, unzip it and put to file python get_log.py static 2013-12 | gzip -d > static_2013-12.txt
2. Download complete log for 2014 and put it to archive python get_log.py all 2014 > all_2014.gz

Log file record description

Log file structure is represented in the table, each column contains the following field described below. Fields are following each other. Every row of log file corresponds to single request.

Field name Field description Example
timestamp Date and time in UNIX timestamp format 1417135813.178
remote_addr User’s IP-address 81.19.133.15
remote_user (service field)
time_local Date and time in a readable format 28/Nov/2014:03:50:13 +0300
request Path to a file or a video stream /live/smil:chanel1.smil/m_b1600000_126952.ts
status Response status 200
body_bytes_sent Total bytes sent (without header) 80840
out_bytes Total bytes sent (including header) 81076
referrer Referrer, request source address http://site1.ru/
useragent Agent/browser of web user Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.65 Safari/537.36
http_x_forwarded_for Content of HTTP-header X-Forwarded-For, source IP-address of user can be contained in 192.168.7.114, 192.168.0.205
host Requested host name site1.cdnvideo.ru
torso_id (service field)
duration Duration of full request or duration of part of request in progress, in seconds 0.616
upstream_status Origin response status (if cache miss) 200
upstream_response_time Origin response time in seconds 0.021
country Country code from ISO_3166-1 RU
service Service type (static-“Web content acceleration”, media-“Live streaming and VOD”) media
logtype (service field)
custom_field (optional) some additional value

Errors

1. “Error: A connection error occurred”
Possible reasons: Failure of Internet connection, network problems. Server went down

Actions:
1. Make sure that you are connected to Internet (ping google.com)
2. If it did not help, please contact the helpdesk

2. “Timeout: page connection timeout more than seconds: 5”
Possible reasons: Server does not respond, network problems.

Actions:
1. Check network connection.
2. Contact the helpdesk.

3. “Error: Wrong username or password”
Possible reasons: Specified login/password pair is invalid (fields username, password in get_log.py)

Actions:
1. Make sure that username and password are filled out correctly in get_log.py script.
2. If the error remains, please, contact the helpdesk.

4. “Error: We don’t have any log for this date”
Reason: We don’t have any log for this period or for such service.

Actions:
As the new log upload feature was introduced in the middle of September, 2014, logs will be available
since that date and further

5. “Error: Problem with server/page down”
Possible reasons: Problems with server.

Actions:
1. Contact the helpdesk

5.4 Screenshot generation

Basic Principles

This service allows to obtain “snapshots” (screenshots) of the livestream. Conditions of the service applicability:

  • Only for broadcasts in real time mode (live);
  • Livestream is pre-published in the CDNvideo network.

The screenshot is a static JPEG image of pre-specified size. Screenshots are generated at specified intervals (default is 1 minute). Multiple screenshots of different size may be generated at the same time. Current screenshots of the stream are available for download via HTTP, and permanent URL is provided for each size. When the stream is stopped the last recorded screenshot will be available.

Configuration procedure

1. Tell us the URL of the published livestream.
2. Provide the required size of screenshots (by default a single screenshot with a size equal to the size of the original video stream is formed).
3. Let us know the screenshot update frequency (default is 1 time per minute).
4. Permanent URL for each the selected size will be provided.

5.5 Input streams transcoding

Basic Principles

There are two transcoding services in our network: “Transcoding the input stream,” and “Transcoding the output streams”; these two kinds can be combined, if required. These services are applicable only to livestreams.

Input stream transcoding is used when you cannot release the stream to us using methods that are standard for our network, as described in sections 4.1.2 and 4.1.3, i.e., requirements to encoding and means of delivery are not met. In this case we take responsibility for “normalization” of stream by making it understandable by our streaming servers. Concurrently, other characteristics of the stream, such as bitrate and resolution can change. Upon transcoding is completed the stream is broadcast to the end-user side by the standard means of our network, as described in section 4.1.4. Important note: you release one stream to the input and also get one stream at the output.

Configuration procedure

1. Provide us with the URL of the livestream.
2. Let us know the required bitrate values and resolution of the stream after transcoding (optional; by default, the original settings are preserved).
3. Check the broadcast on the page with a test player (we will provide the URL of the page).
4. Configure the player to be placed on your website to display the stream through the CDNvideo network

5.6 Output streams transcoding

Basic Principles

There are two transcoding services in our network: “Transcoding the input stream,” and “Transcoding the output streams”; these two kinds can be combined, if required. These services are applicable to livestreams only.

Output stream transcoding is converting a single input livestream to multiple output streams with different bitrate and resolution. In this case key frames in streams are ordered that allows to seamlessly switch between bitrates in the player (automatically in adaptive mode or manually).

Important note: in most cases a single input stream is converted into multiple streams with different bitrates at the output. Nevertheless, it is possible to use this service for transcoding according to the “one to one” scheme with single stream at the output.

Conditions of the service applicability:

  • Only for broadcasts in real time mode (live);
  • Video codec for input stream – H.264;
  • Audio codec for input stream – AAC or MP3;
  • Stream publication by methods that are standard for our network – RTMP, RTSP, MPEG_TS-publish.

Available protocols for the broadcast towards the end users:

  • RTMP/RTMPT;
  • RTSP;
  • Apple HLS;
  • Microsoft Smooth Streaming – MSS;
  • MPEG-DASH.

Warning: Adobe HDS protocol for broadcasting in multiple bitrates is not supported.

For HLS, MSS and MPEG-DASH protocols this service allows not only to create a set of streams with different bitrates, but to combine such streams in the manifest file, that is, to get a complete solution for adaptive broadcasting.

Configuration procedure

1. Publish the original stream.
2. Define particular protocols for the broadcast towards the end users.
3. Let us know the required parameters of output streams: bitrate, resolution, H.264 codec profile, etc.
4. Check the broadcast on the page with a test player (we will provide the URL of the page).
5. Configure the player to be placed on your website to display streams through the CDNvideo network.

5.7 Network video recording (DVR)

Basic Principles

Purpose of this service is to ensure a permanent recording of livestream within a certain sliding time window with the possibility of navigation within that window. The window size is called a DVR depth. The window continuously “slides”, that is, when the DVR depth is about 2 hours “rewinding” back in the player is possible for maximum 2 hours from the current time.
Conditions of the service applicability:

  • Only for live broadcasts;
  • Video codec for input stream: H.264;
  • Audio codec for input stream: AAC or MP3;
  • The stream should be published by RTMP-publish scheme.

For normal operation of this service the published stream should be ordered by key frames, namely as follows:

  • Interval between key frames should be permanent;
  • Interval between key frames should be small (1-2 seconds).

For broadcasting to end-users only HTTP protocols are supported:

  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS).

Streaming protocols RTMP and RTSP are not supported
Available DVR-enabled broadcast patterns:
1. Single bitrate broadcasting. Single stream is published.
2. Multiple bitrate broadcast with the ability to switch between bitrates. Each bitrate is published as individual stream. Switching between bitrates is manual or automatic depending on the player.
3. Multiple bitrate broadcast with the ability to switch between bitrates. This option is implemented through use of the “Output streams transcoding” service, described in section 5.6. A single high quality stream is published that is converted at output into multiple streams with different bitrates. Switching between bitrates is manual or automatic depending on the player. There are limitations described in section 5.6 – HDS protocol is not supported when broadcasting is in multiple bitrates.

As part of providing this service two DVR recording strategies are available:

  • append. When the stream stops the DVR content is not deleted. When the stream resumes the content is seamlessly added to the previously recorded one.
  • delete. When the stream stops for more than 5 minutes the recorded DVR content is deleted. When the stream resumes the DVR record begins again.

Configuration procedure

1. Publish a stream(s) according to the algorithm described in section 4.1.5

2. Provide us with the following information:
Name of the stream(s);
Required DVR depth;
Chosen recording strategy;
Protocols for the broadcast towards the end users.

3. Check the broadcast on the page with a test player; we will provide the URL of the page.

4. Configure player to query streams through the CDNvideo network.

6. Technical support

In case of technical problems please contact our technical support:

  • Phone +7 (499) 502 42 29
  • E-mail support@cdnvideo.com

Please give the following information when contacting the technical support: company name and/or contract number, name and contact phone of the communicating person, problem description and other relevant information. Time of response is:

  • 4 hours for phone requests;
  • 12 hours for email requests.

Базовые принципы

Смысл сервиса – запись live-трансляций в виде файлов с их последующей выгрузкой в облачное хранилище.

Условия применимости сервиса:

  • только для live-трансляций;
  • видеокодек входного потока – H.264;
  • аудиокодек входного потока – AAC или MP3;
  • протокол – RTMP или HLS.

На выходе получаем файлы в формате MP4, длительность отдельного файла не более 3-х часов.

Запись файлов может осуществляться следующими способами:

  • “По кнопке” – запись инициируется пользователем из личного кабинета.
  • По расписанию – запись осуществляется по заранее созданному расписанию.
  • При помощи API вызовов.

Print
TRY FREE