Object Storage Service:Create HLS streams based on OSS

Prerequisites

A bucket is created. For more information, see Create buckets.

Basic operations

OSS allows you to use RTMP to upload H.264-encoded video streams and Advanced Audio Coding (AAC)-encoded audio streams to OSS buckets. You can obtain uploaded audio and video data by accessing the PlayURL of a LiveChannel.

• Upload audio and video data

  1. Call the PutLiveChannel operation to create a LiveChannel.

     After the LiveChannel is created, a PublishURL and a PlayURL are returned. The PublishURL is used to ingest streams by using RTMP, and the PlayURL is used to obtain audio and video data.

  2. Use PublishURL to ingest video and audio streams.

     OSS stores an uploaded audio or video file as an M3U8 index object and multiple video objects in the TS format based on the HLS protocol. For more information, see Stream ingest over RTMP.

• Obtain audio and video data

  To obtain audio and video data that is uploaded by using a LiveChannel, you can access the PlayURL of the LiveChannel from a browser to access the M3U8 index object.

  You can use Android and iOS mobile devices and some browsers on PCs, such as Microsoft Edge and Safari, to access the M3U8 index object to play video objects. If you use other browsers such as Google Chrome, you must embed JavaScript scripts such as Video.js in the browser to play video objects.

If you upload audio and video data to a public-read-write bucket, all users can read and write your data in the bucket, which may lead to data leaks and incur additional traffic fees. The default access control list (ACL) of a bucket is private, and the bucket denies all cross-origin requests. We recommend that you use one or more of the methods described in the following sections to ensure data security based on your business scenarios.

CORS

If you request an audio or video object stored in an OSS bucket by using a link embedded in a third-party website rather than by using the object URL directly from the address bar of a browser, the requested audio or video may fail to be played due to cross-origin access limitations. The browser identifies the request as a cross-origin request because the web server of the third-party website and the bucket that stores the audio or video object have different origins. The browser enforces the same-origin policy for security reasons and denies this cross-origin request if the web server is not one of the allowed origins for the bucket.

You can configure CORS for the bucket to allow cross-origin access to video and audio resources that are stored in an OSS bucket.

1. Log on to the OSS console.

2. In the left-side navigation pane, click Buckets. On the Buckets page, click the name of the bucket.

3. In the left-side navigation tree, choose Content Security > CORS.

4. On the CORS page, click Create Rule.

5. In the Create Rule panel, configure CORS parameters.

   In this example, the value of the Source parameter is set to http://192.168.xx.xx:8080. For more information about CORS settings, see Configure CORS.

   • If you want to specify an origin by using a domain name, enter the complete domain name. For example, enter www.example.com and do not shorten the domain name to example.com.

   • If you want to specify an origin by using an IP address, enter the complete origin URL that includes the protocol type, IP address and port number. For example, enter http://xx.xx.xx.xx:80 and do not specify only the xx.xx.xx.xx part.

   A browser takes tens of seconds to a few minutes to cache the CORS configurations. To allow the CORS configurations to take effect immediately, you can clear your browser cache and then refresh the page.

Hotlink protection

CORS can prevent your audio or video resources from being embedded in third-party websites. However, CORS configurations cannot prevent your audio or video resources stored in OSS buckets from being directly accessed. In this case, you can configure hotlink protection and specify a Referer whitelist for your buckets to prevent unauthorized access to your audio or video resources.

By default, a bucket allows requests in which the Referer field is empty. You can use a browser to access the PlayURL of a LiveChannel to view a video object stored in a bucket. To prevent your audio or video resources from being accessed by unauthorized users, you can configure hotlink protection for the bucket to deny requests in which the Referer field is empty and add trusted domain names or IP addresses to the Referer whitelist. In this case, requests from third-party domain names or IP addresses that are not included in the Referer whitelist fail with a 403 Forbidden error.

1. Log on to the OSS console.

2. In the left-side navigation pane, click Buckets. On the Buckets page, click the name of the bucket.

3. In the left-side navigation tree, choose Content Security > Hotlink Protection.

4. On the Hotlink Protection page, turn on Hotlink Protection.

   • In the Referer Whitelist field, enter the domain names or IP addresses. Example: *.aliyun.com.

     You can configure different Referer fields based on your business scenarios. For Referer configuration examples, see Configure hotlink protection for a bucket.

   • Select No for Allow Empty Referer to deny requests in which the Referer field is empty.

     Note

     • If you select No for Allow Empty Referer and configure a Referer whitelist, only requests that include one of the Referers specified in the whitelist can access your resources in the bucket.

     • If you select No for Allow Empty Referer and do not configure a Referer whitelist, the effect of the hotlink protection configuration is that requests with an empty Referer field are also allowed.

5. Click Save.

Signature mechanism for private buckets

For data security, the ACL of a bucket is private by default. Therefore, when you send a request to a private bucket to read data from or write data to the bucket, you must add a signature in the request to declare your operation permissions to OSS.

When you want to ingest streams to a private bucket, you must sign the PublishURL to upload audio or video objects to the bucket. For more information, see RTMP ingest URLs and signatures.

The following sample code provides an example on how to use OSS SDK for Python to obtain the signed PublishURL to ingest streams to a bucket:

import os
import oss2

access_key_id = "your_access_key_id"
access_key_secret = "your_access_key_secret"
bucket_name = "your_bucket_name"
endpoint = "your_endpoint"

# Create a bucket. 
bucket = oss2.Bucket(oss2.Auth(access_key_id, access_key_secret), endpoint, bucket_name)

# Create and configure a LiveChannel. 
# The index object includes three TS objects, and each of the TS object has a duration of 5 seconds. The duration of 5 seconds in this example is for reference only. The actual duration depends on the keyframe. 
channel_name = "your_channel_name"
playlist_name = "your_playlist_name.m3u8"
frag_count_config = 3
frag_duration_config = 5
create_result = bucket.create_live_channel(
        channel_name,
        oss2.models.LiveChannelInfo(
            status = 'enabled',
            description = 'your description here',
            target = oss2.models.LiveChannelInfoTarget(
                playlist_name = playlist_name,
                frag_count = frag_count_config,
                frag_duration = frag_duration_config)))

# Obtain the signed PublishURL used to ingest streams by using RTMP. 
# The value of expires in the example indicates the length of time in seconds from the current time to the expiration of the URL. 
# After you obtain signed_url, you can use data ingestion tools to ingest streams to OSS. OSS checks the value of expires only when it establishes a connection for stream ingest. A stream that is connected to OSS is not suspended even if the URL expires during the stream ingest process. 
signed_rtmp_url = bucket.sign_rtmp_url(channel_name, playlist_name, expires=3600)
print(signed_rtmp_url)

When you access an object in a private bucket by using the object URL, a signature must be added to the URL. When you access an HLS stream, a request is sent first to dynamically access the M3U8 index object, and then multiple requests are sent to download the latest TS objects based on the content of the index object. A signature must be added to the URL in each request.

To provide more convenience, OSS provides a dynamic signature mechanism for accessing audio and video data. You need to add the x-oss-process=hls/sign parameter to the URL when you access an M3U8 file for the first time, and OSS automatically signs all ts addresses in the returned playlist in the same manner that OSS signs the URL for the M3U8 object.

The following sample code provides an example on how to use OSS SDK for Python to dynamically add signatures to requests when you access audio or video objects:

# Obtain the signed URL used to view the stream. 
your_object_name = "test_rtmp_live/test.m3u8"
style = "hls/sign"
# By default, OSS identifies the forward slashes (/) in the full path of an object as escape characters when a signed URL is generated. In this case, you cannot use the signed URL directly. 
# Set the slash_safe parameter to True. This way, OSS does not identify the forward slashes (/) in the full path of the object as escape characters. In this case, you can use the generated signed URL to download the object. 
signed_download_url = bucket.sign_url('GET', your_object_name, 3600, params={'x-oss-process': style}, slash_safe=True)
print(signed_download_url)