The content of this page has been automatically translated by AI. If you encounter any problems while reading, you can view the corresponding content in Chinese.

On-Cloud Recording and Playback

Last updated: 2025-11-26 12:22:51

Scenario Description

In application scenarios such as remote education, showroom streaming, video conferencing, remote loss assessment, financial dual recording, and online medical consultation, considering the needs for evidence collection, quality inspection, review, archiving, and playback, it is often necessary to record and store the entire video call or interactive live streaming process.
Note:
This document provides instructions on using the newly launched On-Cloud Recording feature for Real-Time Audio and Video. Starting from August 1, 2022, the recording feature type for newly created applications (SdkAppId) is the new version of On-Cloud Recording. If your current TRTC application (sdkappid) uses the old version of On-Cloud Recording, see Legacy On-Cloud Recording for details. To determine the type of On-Cloud Recording for your current application and how to switch from the old version of On-Cloud Recording to the new version, see Console > On-Cloud Recording Instructions.

Feature Description

With TRTC’s on-cloud recording feature, you can record the audio and video stream of each user in the room into separate files (single-stream recording), or mixed-stream record the audio-video media streams in the same room into one file (mixed-stream recording).
Subscription stream: We support specifying the media stream of the user you need to subscribe to by formulating a blocklist/allowlist for subscribed users (API recording only).
Transcoding parameters: In the scenario where streams are merged, we support specifying the quality of the recorded video file by setting encode/decode parameters.
Confluence parameters: In the scenario where streams are merged, we support various flexible and variable automatic multi-screen layout templates and custom layout templates.
File storage: Support storing in Video on Demand (VOD) or Cloud Object Storage (COS).
Callback notification: We support the ability of callback notifications. By configuring your callback domain, the event status of cloud recording will be notified to your callback server.

Single Stream Recording and Mixed Stream Recording Descriptions

Single Stream Recording

As shown below is a scenario of single stream recording. In Room 1234, Anchors 1 and 2 both uplink their audio and video streams. Assume that you subscribe to the audio and video streams of Anchors 1 and 2, and set the recording mode to single stream recording. The recording backend will separately pull the audio and video streams of Anchors 1 and 2, and record them into independent media files including:
An audio and video recording file of anchor 1.
An audio and video recording file of anchor 2.
The recording backend will upload these files to your designated cloud storage platform (VOD or COS). The specific recording process is as follows:



Mixed Stream Recording

As shown below is a scenario of mixed-stream recording. In Room 1234, Anchors 1 and 2 both uplink their audio and video streams. Assume that you subscribe to the audio and video streams of Anchors 1 and 2, and set the recording mode to mixed-stream recording. The recording backend will separately pull the audio and video streams of Anchors 1 and 2, merge their video streams according to your configured layout template, mix their audio streams, and finally mix the media streams into one media file. It includes: one mixed audio and video recording file. For specific initiation methods, see Manual API Recording.
The recording backend will upload these files to your specified cloud storage platform. The specific recording process is as follows:



Recording File Naming and File Segmentation Descriptions

Naming Rule for Recording MP4/AAC File Names

Single Stream Recording MP4/AAC filename rules: <SdkAppId>_<RoomId>_UserId_s_<UserId>_UserId_e_<MediaId>_<Index>.mp4/aac
Mixed Stream Recording MP4/AAC filename rules: <SdkAppId>_<RoomId>_<Index>.mp4/aac

HLS Recording File Naming Convention

Single Stream Recording HLS filename rules: <SdkAppId>_<RoomId>_UserId_s_<UserId>_UserId_e_<MediaId>_<Type>.m3u8
Mixed Stream Recording HLS filename rules: <SdkAppId>_<RoomId>.m3u8
The fields are defined as follows:
Field
Meaning
<SdkAppId>
SdkAppId of the recording task
<RoomId>
For the recorded room number, if the RoomId here is a string room ID, we will first perform a base64 operation on the room number, and then replace the symbol '/' in the base64-encoded string with '-' (hyphen) and the symbol '=' with '.'.
<UserId>
User ID of the recording user. The UserId will first be subjected to a base64 operation, and then replace the symbol '/' in the base64-encoded string with '-' (hyphen) and the symbol '=' with '.'.
<MediaId>
Main and auxiliary stream identification. Main represents the mainstream (camera), and aux represents the auxiliary stream (screen sharing).
<Index>
If the slicing logic is not triggered (size exceeds 2 GB or exceeds the set segment duration), this field is not present; otherwise, it is the Index Number of the segment, starting incrementing from 1.
<Type>
recording file stream type, audio/video/audiovideo
Note:
Custom settings file name prefix: When using API recording to store to VOD, you can customize the file name prefix through the UserDefineRecordId parameter in TencentVod. The prefix is separated from the default recording file name by __UserDefine_u_.

Recording File Segmentation Descriptions

Conditions for file segmentation of recorded MP4/ACC files:
The configurable range for recording split duration is 1-1440 minutes, with a default of 1440 minutes.
An individual MP4/AAC file size reaches 2GB.
Conditions for HLS file segmentation of recordings:
When the recording task duration exceeds 14 days, the HLS file will be split.

Recording and Uploading to Cloud Storage Description

The recording backend will upload the recorded file to the cloud storage platform (VOD or COS) in the way you specify after the recording ends, and send the playback address to you in the form of a callback. If the recording mode is single-stream recording mode, each subscribed anchor will have a corresponding playback address; if the recording mode is merge recording mode, there is only one playback address for the media after merging.
1. Initiate recording through API: In the storage parameters StorageParams, you must specify the parameters for CloudVod (store to VOD) or CloudStorage (store to COS or Third-party Cloud Storage). Please ensure that the corresponding cloud storage service has been enabled and is not in arrears.
2. During the upload task, using DescribeCloudRecording can only query the status of the recording task in progress and will not carry information about the recording files.
Note:
After file recording, it will be uploaded to your designated cloud storage platform (VOD or COS). To ensure the successful uploading of recorded files, please ensure that the VOD or COS service you designated is available.

API Interface and Recording Concurrency Limits

The call rate limit of the recording API is 20 qps (if needed, increase QPS by submitting a ticket).
The API timeout duration is 6 seconds for each API.
<0>For a single application, <1>the default concurrency recording supports 500 streams</1> (the sum of global auto-recording and API recording tasks). Tasks exceeding the concurrency limit will fail. If you need more concurrent push streams, please <3>submit a ticket</3> to contact us.
A single recording task supports a maximum of 25 room anchors subscribing at the same time. Even if an anchor only upstreams audio, it will separately occupy a channel.

Recording Control Scheme

TRTC provides two cloud recording solutions, which are global automatic recording and manual API recording. These two solutions do not conflict and can be used simultaneously, but two sets of recording files and fees will occur. Compared with global automatic recording, the advantage of API recording is that the recording is flexible and the functionality is complete. Customers can specify the anchors in the subscribed room for recording, customize the mixed-stream layout, update the layout and subscribe during the recording, etc. The advantage of global automatic recording is that the recording does not require the customer to start and stop, and the TRTC backend manages the recording tasks.

Solution 1: Global Auto-Recording

TRTC provides an automatic recording method that does not require manual initiation and management of recording tasks. To use this recording scheme, please go to TRTC Console >  Application Management  > Recording Management to enable the on-cloud recording feature, complete the global automatic recording template configuration, and enable global automatic recording.
After it takes effect (waiting for 5 - 10 minutes), the recording task will be triggered when the streamers in the TRTC room uplink the audios and videos. After the streamers in the room check out and the waiting time for continuation is exceeded, the stop recording task will be triggered.



Before enabling the global automatic recording feature, configure the global automatic recording template. Global automatic recording supports single stream recording (i.e., each anchor records one file individually). Once enabled, it is only valid for newly created rooms and does not take effect for rooms that were already created before the automatic recording feature was enabled.

Global Single Stream Recording

The recording format of global single-stream recording supports audio and video recording, audio-only recording, and video recording. The recording files support MP4, HLS, and AAC (in the case of audio-only recording format). Please refer to File Splitting Instructions for Recording Files for the recording file slicing strategy.
Configuration Item
Description
Recording Mode
Single stream recording: The video footage of each anchor in the room will be saved as a separate file.
If you need to record the mixed visuals of multiple anchors, please use API manual merging recording.
recording format
Audio/video format: The audio and video streams in the recording room are suitable for video calls and interactive live streaming scenarios.
Pure audio format: Only record the audio stream in the room.
file format
Support MP4, HLS and AAC (in pure audio format).
Max Recording Time Per File
Used to specify the recording file slice duration. The configurable range is 1-1440 minutes, with a default of 1440 minutes.
Wait time for resumption
Set the timeout period for resuming recording. When the interruption interval does not exceed the set timeout period for resuming recording, only one file will be generated for one call (or live stream). However, you need to wait until the timeout period for resumption elapses before receiving the recording file. Unit: seconds. Value range: 1 - 86400 (default: 30s).

Note: During the renewal waiting period, single stream recording will charge recording fees according to audio duration. Please set it reasonably.
Recording file storage
Support storing in Video on Demand (VOD) or Cloud Object Storage (COS). VOD: It is required to support specifying the vod application, the storage time of recording files in VOD, and binding the vod task flow. COS: The service of storing in COS is jointly provided by VOD. If you need to store in VOD, you need to authorize the read and write permissions of the related COS bucket to VOD. And you need to complete the binding of your bucket and the vod application. After binding, VOD will create an application for you. By selecting this bound application, you can complete the settings of the specified bucket.
Callback address and callback key
The updated cloud recording feature provides detailed recording event functionality. You can configure an available server url to receive recording callback events. At the same time, it supports configuring a callback key to verify the security of callback events. For more information, see.
Note:
In single-stream recording mode, the audio and video streams in the room will be separately recorded based on the streaming parameters. No need to set transcoding.
The wait time for resumption within the period, the recording chatbot will continue to wait inside the room for the broadcaster upload and then complete the recording, and will not immediately end after the anchor exits the room. Please set it reasonably.
Single stream recording can record up to 25 anchors in a room. If there are more than 25 anchors, they will be ordered from first to last by the time of entering the room, and the first 25 anchors will be recorded. (If you need single stream recording for more than 25 anchors, please see API recording.)




Option 2: Manual API Recording

Start Recording

Call the REST API (CreateCloudRecording) through your backend service to start cloud recording. Pay special attention to the parameter - Task ID (TaskId); this parameter is the unique identifier for this recording task. You need to save this Task ID as input parameters for subsequent operations on this recording task interface.
Note:
1. In the CreateCloudRecording API for initiating cloud recording tasks, you need to specify the parameters needed for assigning a recording Chatbot to enter the room, UserId and UserSig (how to obtain UserSig). Please ensure they do not duplicate the UserId of regular anchors or the audience in your room, and must not align with the UserId of the designated recording Chatbot in rooms where recording is in progress, otherwise lead to recording task failure.
2. During manual recording, you can go to the console to configure the callback address to accept recording callback events. See Recording Callback Description.

Recording Mode (RecordMode)

Single stream recording: Real-time record the audio and video of each anchor in the room as an audio-video file and upload it to a cloud storage platform (VOD or COS).
Mixed stream recording: Mix all the audio and video streams of the anchors you subscribe to in the room into one audio-video file and upload it to a cloud storage platform (VOD or COS).

Specify Recording User (SubscribeStreamUserIds)

By default, cloud recording will record all media streams (up to 25) inside the room. If there are more than 25 users, the first 25 streamers to enter the room will be recorded by default. You can also specify the allowlist and blacklist information of streamer users you want to record or not through the parameter SubscribeStreamUserIds. Of course, we also support update operations during the recording process. In the single-stream recording scenario, if there are more than 25 streamers in the room, multiple recording tasks can be initiated by setting the subscription list.

Specify Storage Location and Recording Format (StorageParams)

Storage Location: Supports storage to Cloud Video on Demand (VOD) or Cloud Object Storage (COS). Specify your storage parameters through the CloudVod parameter in StorageParams.
Recording Format: The default recording format is MP4. If you need to record in HLS format, you can set the format to HLS by setting MediaType to 1 in TencentVod under CloudVod. If you need to record in AAC format, you can set the format to AAC by setting MediaType to 2 in TencentVod under CloudVod (valid only when StreamType=1 for audio-only recording).

Retrieval of Start Time of Recording

Subscribe to the subscription callback to listen to the recording callback event. In the StartTimeStamp field of event type 311, you can obtain the recording start timestamp corresponding to the recording file. The EndTimeStamp field can obtain the corresponding end timestamp.
{
"EventGroupId": 3,
"EventType": 311,
"CallbackTs": 1622186289148,
"EventInfo": {
"RoomId": "xx",
"EventTs": "1622186289",
"UserId": "xx",
"TaskId": "xx",
"Payload": {
"Status": 0,
"TencentVod": {
"UserId": "anchor1",
"TrackType": "video",
"MediaId": "main",
"FileId": "xxxxx",
"VideoUrl": "http://xxxxx",
"CacheFile": "xxxxxx",
"StartTimeStamp": 1622186279,
"EndTimeStamp": 1622186811
}
}
}
}

Mixed Stream Recording Layout Mode Parameter (MixLayoutMode)

- Floating layout
The video image of the anchor who enters the room first by default (you can also specify an anchor) will fill the entire screen. The video images of other anchors are arranged horizontally in sequence starting from the bottom-left corner according to the room entry sequence and displayed as small pictures. The small pictures are suspended above the large picture. When the number of pictures is less than or equal to 17, there are 4 pictures in each row (4 × 4 arrangement). When the number of pictures is greater than 17, the small pictures are rearranged to have 5 pictures in each row (5 × 5 arrangement). A maximum of 25 pictures are supported. If the user only sends audio, it will still occupy a screen position.
The floating layout changes as the subscribed sub-screens increase according to the figure below.
Sub-Screens: Up to 17
The width and height of each small picture are 0.235 of the width and height of the entire canvas respectively.
The left-right and vertical spacing between adjacent small pictures are 0.012 of the width and height of the entire canvas respectively.
The horizontal and vertical margins between the small picture and the canvas are also 0.012 of the width and height of the entire canvas respectively.



When the Number of Sub-Screens Is Greater Than 17
The width and height of each small picture are 0.188 of the width and height of the entire canvas respectively.
The left-right and vertical spacing between adjacent small pictures are 0.01 of the width and height of the entire canvas respectively.
The horizontal and vertical margins between the small picture and the canvas are also 0.01 of the width and height of the entire canvas respectively.




Screen sharing layout:

Specify an anchor for the large picture position on the left side of the screen (if not specified, the large picture position will be the background color). Other anchors are arranged vertically from top to bottom on the right side. When the number of pictures is less than 17, a maximum of 8 people are in each column on the right side, and a maximum of two columns are occupied. When the number of pictures is more than 17, anchors with pictures exceeding the 17th are arranged horizontally starting from the bottom-left corner. A maximum of 24 pictures are supported. If an anchor only sends audio, it will still occupy a screen position.
The screen sharing layout changes as the subscribed sub-screens increase according to the figure below.
When the Number of Sub - Pictures Is Less Than or Equal to 5
The width of the small picture on the right is 1/5 of the width of the entire canvas, and the height of the small picture on the right is 1/4 of the height of the entire canvas.
The width of the large screen on the left is 4/5 of the width of the entire canvas, and the height of the large screen on the left is the height of the entire canvas.



Sub-Screens: More Than 5 and Up to 7
The width of the small screen on the right is 1/7 of the width of the entire canvas, and the height of the small screen on the right is 1/6 of the height of the entire canvas.
The width of the large screen on the left is 6/7 of the width of the entire canvas, and the height of the large screen on the left is the height of the entire canvas.



Sub-Screens: More Than 7 and Up to 9
The width of the small screen on the right is 1/9 of the width of the entire canvas, and the height of the small screen on the right is 1/8 of the height of the entire canvas.
The width of the large screen on the left is 8/9 of the width of the entire canvas, and the height of the large screen on the left is the height of the entire canvas.



Sub-Screens: More Than 9 and Up to 17
The width of the small screen on the right is 1/10 of the width of the entire canvas, and the height of the small screen on the right is 1/8 of the height of the entire canvas.
The width of the large screen on the left is 4/5 of the width of the entire canvas, and the height of the large screen on the left is the height of the entire canvas.



Sub-Screens: More Than 17
The width of the small screen on the right (bottom) is 1/10 of the width of the entire canvas, and the height of the small screen on the right (bottom) is 1/8 of the height of the entire canvas.
The width of the large screen on the left is 4/5 of the width of the entire canvas, and the height of the large screen on the left is 7/8 of the height of the entire canvas.



nine-grid layout
Automatically adjust the size of each picture according to the number of anchors. The picture sizes of each anchor are the same. A maximum of 25 pictures are supported. The nine-grid layout changes as the subscribed sub-screens increase according to the figure below.
Sub-Screen: 1
The width and height of each small picture are the width and height of the entire canvas respectively.



Sub-Screens: 2
The width of each small picture is 1/2 of the width of the entire canvas.
The height of each small picture is the height of the entire canvas.



Sub-Screens: Less Than or Equal to 4
The width and height of each small picture are 1/2 of the width and height of the entire canvas respectively.



Sub-Screens: Up to 9
The width and height of each small picture are 1/3 of the width and height of the entire canvas respectively.



Sub-Screens: Up to 16
The width and height of each small picture are 1/4 of the width and height of the entire canvas respectively.



When the Number of Sub-Pictures Is Greater Than 16
The width and height of each small picture are 1/5 of the width and height of the entire canvas respectively.



Custom layout
Customize the layout information of each anchor's picture within MixLayoutList according to your business needs. 

Mixed Stream Recording Watermark Parameters (MixWatermark) 

We support adding image watermarking in mixed-stream recording. The maximum supported count is 25. You can add watermark at any position on the canvas.
Field Name
Explanation
Top
Vertical offset of the watermark relative to the top-left corner
Left
Horizontal offset of the watermark relative to the top-left corner
Width
Width of watermark display
Height
Height of watermark display
url
Storage URL of the watermark file

Querying Recording (DescribeCloudRecording)

If necessary, you can call this API to query the status of recording services.
Note:
Information can only be queried when a recording task exists. An error will be returned if the recording task has already ended.
If it is an upload VOD task, the StorageFile returned by this API is empty.

Updating Recording (ModifyCloudRecording)

If necessary, you can call this API to modify the parameters of the recording service, such as the subscription blocklist and allowlist SubscribeStreamUserIds (valid for single-stream and mixed-stream recordings) and the template parameters for recording MixLayoutParams (valid for mixed-stream recordings).
Note:
The update operation is a full coverage operation, not an incremental update operation. You need to carry the full amount of information every time you update, including the template parameter MixLayoutParams and the blocklist/allowlist SubscribeStreamUserIds. Therefore, you need to save the parameters of the previous start shooting or recalculate the complete recording-related parameters. 

Stopping Recording (DeleteCloudRecording)

After recording ends, you need to call the stop recording (DeleteCloudRecording) API to end the recording task. Otherwise, the recording task will wait until the predefined timeout period MaxIdleTime is reached and then end automatically.
Note:
The definition of MaxIdleTime is that the state where there is no anchor in the room continuously exceeds the duration of MaxIdleTime. Here, if there is an anchor in the room but the anchor has no upstream data, it will not enter the timeout timing state. At this time, the backend recording will continue to work. It is recommended that the business call this API to end the recording task when the recording ends. 

Recording Callback Event

We provide multiple callback events for the on-cloud recording feature to help you timely understand the handling and completion status of recording tasks. For callback address configuration and event descriptions for recording, see cloud recording callback.

Recording File Management

Searching Recording Files

After the recording task in the room is completed, the files recorded by the TRTC recording system will be uploaded to the cloud storage platform specified by you (VOD or COS). You can directly go to the VOD Console or COS Console to search, or your backend server can use REST API to perform scheduled filtering.

Method One: Manual Search in VOD Console

1. Log in to the VOD Console, and select Media Asset Management in the left sidebar.
2. Click Prefix Search at the top of the list, select Prefix Search, enter keywords in the search box, fill in according to Recording file naming rules, for example, fill in under mixed-stream recording: 1400000123_1001, click
img

, and videos with names matching the prefix will be shown.



3. Log in to the COS Console and select the specified Bucket for searching:



Alternatively, you can go to Tencent Real-Time Communication Console > Recording Management > Recording File Management and filter the corresponding on-demand application to view the corresponding recording files.




Method Two: Search Via VOD REST API

Tencent Cloud VOD system provides a series of REST APIs to manage audio and video files on it. You can query the files on the on-demand system through the search media information REST API. You can perform matching search through the TrtcSdkAppIds (corresponding to the SdkAppid of the application initiating recording) or TrtcRoomIds (corresponding to the room number Roomid of the application initiating recording) parameters. REST API Request Example:
https://vod.tencentcloudapi.com/?Action=SearchMedia
&TrtcSdkAppIds=1400xxxx123
&TrtcRoomIds=1234
&Sort.Field=CreateTime
&Sort.Order=Desc
&<common request parameters>
Note:
If you need to download recording files, please go to VOD Console - Media Asset Management, find the corresponding recording files, and perform download in "Operation".

Receiving Recording Files

Besides searching recording files, you can also configure the callback address in the console, allowing Tencent Cloud to proactively push messages of new recording files to your server. After the last audio and video stream in the room exits, this process will approximately take 30 seconds to several minutes by default (the specific time depends on the size of the file you are recording. If you set the resumption time to 300 seconds, the waiting time will be superimposed with an additional 300 seconds on the default basis). After the transfer is completed, Tencent Cloud will send a notification to your server through the callback address (HTTP/HTTPS) you set in configuring the recording callback.

Tencent Cloud will push recording and recording-related events to your server through the callback address you set. You can obtain the playback address VideoUrl of the recording file by receiving the upload success callback with an event type of 311. The specific callback information is as follows:
{
"EventGroupId": 3,
"EventType": 311,
"CallbackTs": 1622191965320,
"EventInfo": {
"RoomId": "20015",
"EventTs": 1622191965,
"UserId": "xx",
"TaskId": "xx",
"Payload": {
"Status": 0,
"TencentVod": {
"UserId": "xx",
"TrackType": "audio_video",
"MediaId": "main",
"FileId": "xxxx",
"VideoUrl": "http://xxxx",
"CacheFile": "xxxx.mp4",
"StartTimeStamp": xxxx,
"EndTimeStamp": xxxx
}
}
}
}

Deleting Recording Files

Tencent Cloud VOD system provides a series of REST APIs to manage audio and video files on it. You can delete a specified file through the DeleteMedia API. REST Request Example:
https://vod.tencentcloudapi.com/?Action=DeleteMedia
&FileId=52858907988664150587
&<common request parameters>

Playback Recording File

In other scenarios such as online education, recording files usually need to be played back multiple times after live streaming ends so that educational resources can be fully utilized.

Get Video on Demand URL (VideoUrl)

When receiving recording files, you can obtain the VideoUrl field in the callback message, which is the current recording file's on-demand address on Tencent Cloud.

Integrate On-Demand Player

Integrate the use platform with the on-demand player. For specific operations, refer to as follows:
Note:
Recommend using the Professional Edition TRTC SDK. The Professional Edition integrates features such as player (Player+) and Mobile Live Video Broadcasting SDK. Due to the high reuse of underlying modules, the volume increment of integrating the Professional Edition is less than that of integrating two independent SDKs simultaneously, and it can avoid the trouble of symbol conflict (symbol duplicate).

Relevant Fees

The features used by the On-Cloud Recording and Playback feature include: Cloud Recording Service, playback file storage and processing of VOD or COS, playback service of VOD or COS, and the ability of terminal SDK to play on-demand videos. The following fees may occur according to actual needs.

Cloud Recording Fees

On-cloud recording fees depend on the duration and video resolution of your recording. At the same time, the pricing is distinguished according to different recording modes (single stream or merge). The computational formula for recording costs is as follows:
On-cloud recording fees = Audio recording fees + Video recording fees = Audio input duration usage of single or multiple streams × Corresponding Audio Unit Price + Input duration usage of each video resolution tier of single or multiple streams × Corresponding video resolution tier unit price
Note:
For more detailed cloud recording fees description and billing examples, please see Billing explanation of on-cloud recording.

CFS Fees

The recorded video files are stored in VOD or COS services. Since storage itself causes disk resource consumption, fees are charged according to the resource occupancy of storage. The longer the storage time, the higher the fees. Therefore, if there is no special need, you can shorten the storage time of files to save costs, or store the files on your own servers. For VOD storage fees, you can choose Daily Pricing for Video Storage for daily billing, or purchase Storage Resource Packages; for COS storage fee details, see Pay-as-you-go (postpaid).
Note:
Special note: If you select storage to COS, you will be charged for the delivery of recording files to COS. For details, see Delivery fee explanation. No charge will be collected for storage to VOD.

File Playback Costs

If the recorded video files are to be used for playback, the CDN playback feature of VOD or COS will be used. Since viewing itself generates CDN traffic consumption, fees need to be billed according to the pricing of VOD or COS. By default, billing is performed based on traffic. The more people watch, the higher the fees. For VOD playback fees, you can choose Daily Pricing for Video Acceleration for daily billing, or purchase Traffic Package. For COS playback fees, see Traffic Fees.

SDK Playback License

The full-featured version SDK of Audio/Video Call (TRTC) provides comprehensive features and high-performance video playback capabilities, which can easily cooperate with VOD or COS to realize video playback functions. The Mobile SDK version 10.1 and above can unlock video playback capabilities by obtaining the specified License.
Note:
TRTC audio and video calls and live stream playback capabilities do not require License authorization.
You can directly purchase a player License, or obtain a player License or Short Video License for free through the purchased VOD traffic package. Both kinds of Licenses can be used to unlock the video playback feature of the SDK. And the on-demand resource pack can offset the daily traffic generated by VOD playback. For more information, please refer to Prepaid Packages for VOD. For license billing description, see Tencent Cloud Video Cube License. After purchasing the License, you can refer to License Operation Guide to perform operations such as adding and renewing.

Best Practice

To guarantee the high availability of recording, it is recommended that customers pay attention to the following points while integrating RESTful API.
After calling the CreateCloudRecording request, pay attention to the HTTP response. If the request fails, then you need to adopt an appropriate retry policy according to the specific status code. The error code is composed of a "primary error code" and a "secondary error code". For example: InvalidParameter.SdkAppId.
If the returned Code is InValidParameter.xxxxx, it means the input parameter is incorrect. Please check the parameters according to the prompts.
If the returned Code is InternalError.xxxxx, it means a server error has occurred. You can retry multiple times with the same parameters until a normal response is received and the taskid is obtained. It is recommended to use a backoff retry strategy, such as retrying after 3 seconds for the first time, 6 seconds for the second time, 12 seconds for the third time, and so on.
If the returned Code is FailedOperation.RestrictedConcurrency, it means that the customer's concurrent recording task count exceeds the backend reserved resources (500 channels by default). Please contact Tencent Cloud Technical Support to adjust the highest concurrency limit.
If you have a subscription recording callback, when the EVENT_TYPE_CLOUD_RECORDING_RECORDER_STOP callback event is received and the LeaveCode is 500, it means the recording and anchor data have been disconnected for a long time. Please initiate the recording task again to ensure the availability of the recording.
When calling the CreateCloudRecording API, the specified UserId/UserSig is the ID for the recording to join the room as a separate bot user. Please do not duplicate it with other users in the TRTC room. At the same time, the room type joined by the TRTC client must be consistent with the room type specified by the recording API. For example, if the SDK creates a room using a string Room Number, then the room type for cloud recording also needs to be set to a string Room Number accordingly.
Recording status inquiry. Customers can obtain the corresponding recording file information in several ways:
About 15 seconds after successfully initiating the CreateCloudRecording task, call the DescribeCloudRecording API to query the corresponding information of the recording file. If the status queried is idle, it means the recording has not pulled the uplink audio and video stream. Please check whether there is broadcaster upload in the room.
After successfully initiating CreateCloudRecording, under the condition that the room has upload audio and video, you can concatenate the recording file name according to the generation rule of the recording file name. For specific filename rules, please refer to recording file naming convention.
The status of the recording file will be sent to the customer's server through callback. If you have subscribed to the relevant callback, you will receive the status information of the recording file. For specific callback information, please see callback API.
The UserSig expiration time of the recording user (userid) should be set to a longer time than the task lifecycle of the recording task to prevent the recording task from failing due to UserSig expiration when the machine of the recording task is disconnected from the network and the internal high availability takes effect and resumes the recording.