On-Cloud Recording and Playback (Old)

Use Cases

In application scenarios such as remote education, showroom streaming, video conferencing, remote loss assessment, financial transaction recording, and online healthcare, it is often necessary to record an entire video call or live streaming session and save the recording files for purposes such as evidence gathering, quality control, auditing, archiving, and playback.
With TRTC’s on-cloud recording feature, you can record the audio/video streams of each user in a room into separate files.



You can also mix the audio/video streams in a room into one stream using On-Cloud MixTranscoding and then record the mixed stream into a single file.


Notes:
For users with an SDKAppID starting with 140, please refer to this cloud recording and playback operation guide for integration and usage. If your application's SDKAppID starts with 200, please refer to On-Cloud Recording (New) to initiate the cloud recording function.

Console Guide

Enabling on-cloud recording

1. Log in to the TRTC console and click Application Management on the left sidebar.
2. Find your application and click Function Configuration on the right. If you haven’t created an application yet, click Create Application, enter an application name, and click Confirm to create one.
3. Click

next to Enable On-Cloud Recording. A recording configuration window will pop up.

Selecting the recording mode

TRTC supports recording in two modes: Global Auto-Recording and Specified User Recording.

Global Auto-Recording The upstream audio/video streams of all users in all TRTC rooms are automatically recorded. The recording starts and stops automatically. Because no human intervention is needed, this mode is simple and easy to use. For detailed instructions, see Scheme 1: Global Auto-Recording.
Specified User Recording You can specify users whose streams you want to record. This is achieved using either the client-side SDK API or server-side RESTful API for on-cloud recording and requires additional development efforts. For detailed instructions, see Scheme 2: specified user recording (SDK API) and Scheme 3: specified user recording (RESTful API).

Select the file format

TRTC can record streams in four formats, namely HLS, MP4, FLV, and AAC. Their differences and application scenarios are listed in the table below.
Parameter
Description
File type
The following file types are supported:
HLS: Files in this format can be played back on most browsers and are ideal for scenarios in which videos need to be replayed multiple times. When this format is selected, recording can resume from breakpoints, and no upper limit is set on the recording length of a file.
FLV: Files in this format cannot be played back on browsers, but the format is simple and fault tolerant. You can use this format if you do not need to save recording files in VOD. Just download the files immediately after recording and delete the original files.
MP4: Files in this format can be played back on browsers, but the format is not fault tolerant. Any packet loss during a video call may affect the playback quality of the recording file.
AAC: Select this format if you want to record audio only.
Maximum file length (minutes)
You can set a maximum length for recording files based on your needs. The system will automatically segment files that exceed the limit. The value range is 1-120 (minutes).
When HLS is selected for File Type, there is no limit on the length of recording files, and this parameter becomes invalid.
File retention duration (day)
You can set for how many days you want VOD to save your recording files. The value range is 0-1500 (days). Files that expire will be deleted and cannot be retrieved. 0 indicates the files will be saved indefinitely.
Resumption timeout (second)</td>
By default, if a call/live streaming session is interrupted due to network jitter or other reasons, the call will be recorded into multiple files.
You can set this parameter to generate only one playback link for each call/live streaming session. When recording is cut off, if the interruption does not exceed the configured time period, only one file will be generated. You can get the file only after the timeout period elapses.
The value range of this parameter is 0-1800 (seconds). 0 indicates that breakpoint resumption is disabled.
Notes
HLS allows a maximum resumption timeout period of 30 minutes, making it possible to generate only one playback link for each lecture. What’s more, files in HLS format can be played back on most browsers, making the format ideal for video playback in online education scenarios.

Setting the path to save recording files

In TRTC, recording files are stored in Tencent Cloud’s VOD platform by default. If more than one of your businesses share a Tencent Cloud VOD account, you may want to separate their recording files, which you can achieve through VOD’s subapplication feature.
What are VOD primary applications and subapplications? Primary applications and subapplications offer a way to separate your resources in VOD. A primary application is essentially your VOD account. Multiple subapplications can be created under a primary application, each of which functions as a sub-account of the VOD account. The resources of subapplications are managed separately and assigned their own storage space.
How do I enable the subapplication feature in VOD? You can create subapplications in the VOD console as instructed in Subapplication System.

Configuring recording callback

Recording callback address: To receive notifications about the generation of new recording files in real time, set the Recording Callback Address to an HTTP or HTTPS address on your server. When a new recording file is generated, Tencent Cloud will send a notification to your server via this address.

Recording callback key: The callback key is used to generate authentication signatures for receiving recording callbacks. The key must consist of not more than 32 letters and digits. For details, see Common callback parameters.
Notes
For more details on receiving callbacks of recording files and how to interpret the callbacks received, see Receiving recording files below.

Recording Schemes

TRTC offers three on-cloud recording schemes, namely global auto-recording, specified user recording (SDK API), and specified user recording (RESTful API). We will explain the following for each of the scheme.
How do I select the scheme in the console?
How to start a recording task?
How to end a recording task?
How do I mix multiple streams in a room into one stream?
How is a recording file named?
What platforms does the scheme support?

Scheme 1: Global auto-recording

Selecting the scheme in the console To use this recording scheme, set On-Cloud Recording Mode to Global Auto-Recording in the console.
Starting a recording task The audio/video streams of each user in a TRTC room are recorded automatically, with no need for human intervention.
Ending a recording task A task stops automatically when an anchor stops sending audio/video data. However, if you have set the Resumption Timeout parameter when choosing the format for recording files, you will not receive the recording file until the timeout period elapses.
Mixing streams In the global auto-recording mode, you can mix streams by using either the server-side RESTful API or the client-side SDK API. These two methods for mixing streams should not be used at the same time.
Stream mixing via the server-side RESTful API: The stream mixing API must be called on your server. This method works regardless of the platform the SDK runs on.
Stream mixing via the client-side API: The stream mixing API can be called from the client. This method works on iOS, Android, Windows, macOS, and browsers. It does not work for Weixin Mini Programs.
Naming of recording files
If an anchor has set userDefineRecordId during room entry, recording files will be named userDefineRecordId_streamType__start time_end time (streamType has two valid values: main, which indicates the primary stream, and aux, which indicates the substream.)
If an anchor has set streamId, but not userDefineRecordId during room entry, recording files will be named streamId_start time_end time.
If an anchor has set neither userDefineRecordId nor streamId during room entry, recording files will be named sdkappid_roomid_userid_streamType_start time_end time (streamType has two valid values: main, which indicates the primary stream, and aux, which indicates the substream.)
Supported platforms Recording operations are initiated by your server and are not affected by the platform on which the SDK runs.

Scheme 2: Specified user recording (SDK API)

You can call APIs of the TRTC SDK to enable On-Cloud MixTranscoding, on-cloud recording, and CDN live streaming.
On-Cloud Capability
Enabling
Disabling
On-cloud recording
Specify userDefineRecordId in TRTCParams during room entry.
Recording stops automatically after the anchor leaves the room.
On-Cloud MixTranscoding
Call the SDK API setMixTranscodingConfig().
Stream mixing stops automatically after the anchor who starts it leaves the room. The anchor can also stop it manually by calling setMixTranscodingConfig() and setting the parameter to null/nil.
CDN live streaming
Specify the streamId field in TRTCParams during room entry.
Relaying stops automatically after the anchor leaves the room.

Selecting the scheme in the console To use this recording scheme, set On-Cloud Recording Mode to Specified User Recording in the console.
Starting a recording task If an anchor has set userDefineRecordId in the room entry parameter TRTCParams during room entry, the audio/video data sent by the anchor will be recorded on the cloud. The streams of anchors who have not set the parameter will not be recorded.
// Sample code: Record the streams of the user rexchang and set the recording ID to `1001_rexchang`
TRTCCloud *trtcCloud = [TRTCCloud sharedInstance];
TRTCParams *param = [[TRTCParams alloc] init];
param.sdkAppId = 1400000123; // The SDKAppID, which is generated after you create a TRTC application
param.roomId = 1001; // The room ID
param.userId = @"rexchang"; // The user ID
param.userSig = @"xxxxxxxx"; // The login signature
params.role = TRTCRoleAnchor; // The role: anchor
param.userDefineRecordId = @"1001_rexchang"; // The recording ID. Specify this parameter to enable specified user recording.
[trtcCloud enterRoom:params appScene:TRTCAppSceneLIVE]; // Please use the `LIVE` mode

Ending a recording task The task stops automatically after the anchor who has set userDefineRecordId during room entry stops sending audio/video. However, if you have set the Resumption Timeout parameter when choosing the format for recording files, you will not receive the recording file until the timeout period elapses.
Mixing streams You can call the SDK API setMixTranscodingConfig() to mix the audio/video streams of other users in a room with the current user's audio/video streams. For details, see On-Cloud MixTranscoding.
Notes
Make sure that the setMixTranscodingConfig API is called by just one anchor (preferably the anchor who created the room) in a TRTC room. Calling of the API by multiple anchors may cause errors.
Naming of recording files Recording files are named userDefineRecordId_start time_end time.
Supported platforms Recording tasks can be initiated on iOS, Android, Windows, macOS, Electron, and web. Weixin Mini Programs are not supported currently.

Scheme 3: Specified user recording (RESTful API)

TRTC's server provides a pair of RESTful APIs (StartMCUMixTranscode and StopMCUMixTranscode) for the implementation of On-Cloud MixTranscoding, on-cloud recording, and CDN live streaming.
On-Cloud Capability
Enabling
Disabling
On-cloud recording
Call StartMCUMixTranscode from your server, specifying OutputParams.RecordId.
Recording will stop automatically. You can also call StopMCUMixTranscode to manually stop it.
On-Cloud MixTranscoding
Call StartMCUMixTranscode, specifying LayoutParams (which determines the video layout).
Stream mixing will stop automatically. You can also call StopMCUMixTranscode to manually stop it.
CDN live streaming
Call StartMCUMixTranscode, specifying OutputParams.StreamId.
Relaying will stop automatically. You can also call StopMCUMixTranscode to manually stop it.
Notes
The two RESTful APIs work via TRTC’s core stream mixing MCU and send mixed streams to the recording system and live streaming CDNs, hence the name Start/StopMCUMixTranscode. In addition to stream mixing, the APIs can also be used to enable on-cloud recording and CDN live streaming.

Selecting the scheme in the console To use this recording scheme, set On-Cloud Recording Mode to Specified User Recording in the console.
Starting a recording task Specify OutputParams.RecordId when calling StartMCUMixTranscode from your server to enable stream mixing and recording.
// Sample code: Call the RESTful API to start an On-Cloud MixTranscoding and on-cloud recording task
https://trtc.tencentcloudapi.com/?Action=StartMCUMixTranscode
&SdkAppId=1400000123
&RoomId=1001
&OutputParams.RecordId=1400000123_room1001
&OutputParams.RecordAudioOnly=0
&EncodeParams.VideoWidth=1280
&EncodeParams.VideoHeight=720
&EncodeParams.VideoBitrate=1560
&EncodeParams.VideoFramerate=15
&EncodeParams.VideoGop=3
&EncodeParams.BackgroundColor=0
&EncodeParams.AudioSampleRate=48000
&EncodeParams.AudioBitrate=64
&EncodeParams.AudioChannels=2
&LayoutParams.Template=1
&<Common request parameters>
Notes
The RESTful API works only when at least one user has entered the room (enterRoom).
The RESTful API cannot be used to record single streams. If you want to record single streams, choose Scheme 1 or Scheme 2.
Ending a recording task The task stops automatically. You can also call StopMCUMixTranscode to stop it manually.
Mixing streams Set LayoutParams when calling StartMCUMixTranscode to enable On-Cloud MixTranscoding. The API can be called multiple times during live streaming, meaning that you can modify the LayoutParams parameter to change the layout of video images. Make sure you use the same OutputParams.RecordId and OutputParams.StreamId for each call; otherwise the recording will be interrupted and multiple recording files will be generated.
Notes
For more information about On-Cloud MixTranscoding, see On-Cloud MixTranscoding.
Naming of recording files Recording files are named OutputParams.RecordId_start time_ end time. OutputParams.RecordId is set when StartMCUMixTranscode is called.
Supported platforms Recording operations are initiated by your server and are not affected by the platform on which the SDK runs.
When recording is enabled, files recorded in TRTC are saved in Tencent Cloud’s VOD platform. You can search for files in the VOD console or use a RESTful API on your server for scheduled filtering.

Searching for files in the VOD console

1. Log in to the VOD console and click Media Assets on the left sidebar.
2. Click Search by prefix above the list, select Search by prefix, enter a keyword such as 1400000123_1001_rexchang_main in the search box, and click the search icon.
3. You can also filter files by creation time.

Searching for files via a RESTful API

You can use the SearchMedia API to query files in VOD. Specify the request parameter Text for fuzzy searches or StreamId for exact searches. RESTful request sample code:
https://vod.tencentcloudapi.com/?Action=SearchMedia
&StreamId=stream1001
&Sort.Field=CreateTime
&Sort.Order=Desc
&<Common request parameters>

Receive Recording Files

In addition to [#search!a41705a4893cb9904429d608433f5092), you can configure a callback address to have Tencent Cloud push notifications to your server when new recording files are generated. When the last user exits the room, Tencent Cloud will stop recording and save the recording file in VOD. This normally takes about 30-120 seconds. If you have set a resumption timeout period (for example, 300 seconds), then the process will take 300 seconds longer. After saving the file, Tencent Cloud will send a notification to your server via the specified (HTTP/HTTPS) callback address.
Tencent Cloud sends information about all recording events to your server via the specified callback address. Below is an example of a callback message:

The fields in the table below help you determine which call/live streaming session a callback is about.
No.
Field
Description

event_type
The event type. 100 indicates that a recording file has been generated.

stream_id
The stream ID for CDN live streaming, which you can set by specifying the streamId field in TRTCParams during room entry (recommended), or when calling the startPublishing API of TRTCCloud.

stream_param.userid
The Base64-encoded user ID.

stream_param.userdefinerecordid
<td>A custom field. You can set this field by specifying the userDefineRecordId field in TRTCParams.

video_url
The URL of the recording file, which can be used for replay.
Notes
For information about other fields, see CSS-Recording Event Notification.

Deleting Recording Files

VOD provides a series of RESTful APIs for the management of audio/video files. You can call the DeleteMedia API to delete a file. RESTful request sample code:
https://vod.tencentcloudapi.com/?Action=DeleteMedia
&FileId=52858907988664150587
&<Common request parameters>

Playing Back Recording Files

In application scenarios such as online education, live streaming sessions are often replayed to make the best of teaching resources.

Select the file format (HLS)

Select HLS as the file format. HLS supports a maximum timeout period of 30 minutes for breakpoint resumption, making it possible to generate only one playback link for each live streaming session/lecture. What’s more, files in HLS format can be played back on most browsers, making it an ideal format for replay.

Get the playback address (video_url)

After receiving a recording file callback, you can get the playback address of the file by looking for the video_url field in the callback message.

Integrate the VOD player

Integrate the VOD player. For detailed directions, see the following documents.
Notes
We recommend using the All-in-One SDK, which integrates the player component as well as Mobile Live Video Broadcasting (MLVB). This integrated edition adds less to the size of the application package than two independent SDKs do because the Tencent Cloud services share many of their underlying modules. It also allows you to avoid duplicate symbol issues.

Costs

The on-cloud recording and playback feature is powered by TRTC’s on-cloud recording capability and VOD’s storage, video processing, and playback capabilities. It also relies on the VOD playback capability of the SDKs.

Cloud service fees

Cloud service fees include the fees incurred for recording videos on the cloud and playing back recording files.
Notes
The prices used in the examples in this document are for reference only. In case of any inconsistencies, the prices specified in Billing of On-Cloud Recording, CSS Pricing and VOD Pricing will apply.
Recording fee: The computing cost of transcoding or remuxing Because server computing resources are needed to transcode or remux audio/video streams during recording, a recording fee is charged based on the computing resources used for recording.
Notes
For Tencent Cloud accounts that created their first TRTC applications on or after July 1, 2020, on-cloud recording fees are charged as described in Billing of On-Cloud Recording.
For Tencent Cloud accounts that created applications before July 1, 2020, live recording fees will continue to apply.
Live recording fees are calculated based on the peak number of concurrent recording channels. The higher the number, the higher the fee. For details, see CSS > Live Recording.
Formula:
Percentage of recording days = Number of days the recording feature is used in a month / Total number of days in that month.
Recording fees = Peak number of concurrent recording channels in a month x Percentage of recording days x Recording channel unit price.

Assume that you had 1,000 anchors in April. During peak times, you recorded the audio/video streams of 500 anchors at the same time, and the recording feature was used on four days that month (percentage of recording days is 6/30). If the service is priced 5.2941 USD per channel per month, then the live recording fee incurred in April would be 500 channels x 5.2941 USD/channel/month = 2,647.05 USD/month. If you select two file formats, both the recording and storage fees will double. If you select three, they will triple. To reduce cost, you are advised to select only one file format.
Transcoding fee: Incurred for using On-Cloud MixTranscoding Because stream mixing involves encoding and decoding, an additional transcoding fee will be incurred if you enable On-Cloud MixTranscoding. The fee varies with the resolution used and the transcoding duration. The higher resolution used for anchors, and the longer co-anchoring (the most common application scenario for On-Cloud MixTranscoding) lasts, the higher the cost. For more information, see Live Transcoding.
Assume that you called setVideoEncoderParam() to set the bitrate (videoBitrate) for anchors to 1,500 Kbps and resolution to 720p, and the anchor co-anchored with a viewer for one hour, during which On-Cloud MixTranscoding was enabled. The transcoding fee incurred would be 0.0057 USD/min x 60 min = 0.342 USD.
Storage fee: Incurred for storing files with VOD Because storage requires disk resources, if you save recording files in VOD, a storage fee will be charged based on the disk resources used. The longer you save a file, the higher the cost. To reduce cost, you are advised to keep the storage duration as short as possible or store recording files on your own server. Storage fees are charged in the daily pay-as-you-go mode.
Assume that you called setVideoEncoderParam() to set the bitrate (videoBitrate) of an anchor to 1000 Kbps and recorded the anchor's stream (one file format) for one hour. The size of the recording file generated would be approximately (1,000/8) KBps x 3,600s = 450,000 KB = 0.45 GB. If you store the file with VOD, the storage fee per day would be 0.45 GB x 0.0009 USD/GB/day = 0.000405 USD.
Playback fee: Incurred for playing back a file** Playing back a recording file relies on VOD’s CDN playback feature and consumes CDN traffic. By default, a video acceleration fee is charged based on the traffic consumed by playback. The larger audience you serve, the higher the cost. Playback fees are charged in the daily pay-as-you-go mode.
Assume that you recorded a 1 GB file on the cloud and played it back to 1,000 users from beginning to end. The traffic consumed amounted to 1 TB, and according to VOD’s tiered pricing system, the playback fee incurred would be 1,000 x 1 GB x 0.0794 USD/GB = 79.4 USD. If you have bought a traffic package, 24.5 USD would be deducted. If you download files from Tencent Cloud to your server, a relatively small amount of traffic will also be consumed, which is billed on a monthly basis.

SDK playback license

TRTC All-in-One offers powerful player capabilities based on VOD. If you use our mobile SDK and its version is 10.1 or later, you need to buy a license to use the player capabilities.
Notes
You don’t need a license for playback within TRTC.