tencent cloud

Use Cases

TRTC uses UDP to transfer audio/video data, but standard live streaming CDNs use protocols such as RTMP, HLS, and FLV. As a result, the audio/video data in TRTC needs to be relayed to live streaming CDNs for viewers to watch.

It is often necessary to relay from TRTC to live streaming CDNs in the following two scenarios.

• Scenario 1: ultra-high-concurrency watching
  In each TRTC room, up to 100,000 viewers can watch live streams at low latency at the same time. CDN live streaming has a higher latency, but it allows more concurrent viewers and is more cost-effective.
• Scenario 2: playback on mobile browsers
  TRTC can be accessed through WebRTC, but WebRTC works mainly for desktop Chrome and is poorly supported by mobile browsers, especially on Android. Therefore, if you want to stream on mobile browsers, we recommend that you use the HLS (m3u8) protocol, which requires the support of live streaming CDNs.

How It Works

Tencent Cloud uses a relayed transcoding cluster to relay TRTC’s audio/video data to live streaming CDNs. The cluster converts the UDP streams of TRTC to the standard RTMP streams.

Relaying and streaming single-channel streams
If there is only one anchor in a TRTC room, relayed push in TRTC is the same as direct push over the standard RTMP, but UDP, which TRTC uses for data transmission, adapts better to poor network conditions than RTMP does.

Relaying and streaming streams mixed from multiple channels
The biggest strength of TRTC is audio/video co-anchoring. If there are multiple anchors in a room but a CDN viewer wants to pull only one channel of audio/video streams, TRTC can use the On-Cloud MixTranscoding feature to mix multiple channels of streams into one channel. Here is how it works:

Why not play back multiple channels of video images via CDNs?
For one, it is difficult to synchronize multiple channels of streams played back via CDNs; for another, pulling multiple channels of streams consumes more traffic than downloading single-channel streams. Therefore, it is common in the industry to mix streams in the cloud before playback.

Prerequisites

You have activated Tencent Cloud CSS and, according to the requirements of the regulator, you must have a playback domain name for live streaming. For details, see Adding Domain Name.

Directions

Step 1. Enable relayed push.

1. Log in to the TRTC console.
2. Select Application Management in the navigation pane on the left, find your application, and click Function Configuration.
3. In Relayed Push Configuration, click next to Enable Relayed Push, and click Enable Relayed Push in the dialog box that pops up.

Step 2. Configure the playback domain name and CNAME record.

1. Log in to the CSS console.
2. In the navigation pane on the left, select Domain Management and you will see that a push domain name in the format of xxxxx.livepush.myqcloud.com has been added to the list. xxxxx is bizid, which is a numeric string and can be found in TRTC console > Application Management > Application Info.
3. Click Add Domain, enter a playback domain name for which you have obtained an ICP license. For Type, select Playback Domain, choose an acceleration region, and click Confirm.
4. Once your domain name is added, the system will automatically assign to it a CNAME, which ends with .liveplay.myqcloud.com. The CNAME can be accessed only after you configure it at your domain name service provider. You will be able to use CSS services once the configuration takes effect. For detailed directions, see Configuring CNAME for Domain Name.

Note：

You do not need to add a push domain name. After you enable relayed push in step 1, Tencent Cloud will add a push domain name in the format of xxxxx.livepush.myqcloud.com to the domain list of the CSS console, which is the default push domain name used by CSS and TRTC and cannot be modified.

Step 3. Associate TRTC streams with CSS streamId.

After relayed push is enabled, each stream in a TRTC room will be assigned a playback address in the following format:

http://playback domain name/live/[streamId].flv

streamId uniquely identifies a live stream. You can specify a streamId or use the default one.

Method 1: specifying a streamId

You can specify a live stream ID by setting streamId in TRTCParams when calling the enterRoom function in TRTCCloud.
Below is an example of the setting code using Objective-C on iOS.

TRTCCloud *trtcCloud = [TRTCCloud sharedInstance];
TRTCParams *param = [[TRTCParams alloc] init];
param.sdkAppId = 1400000123;     // `SDKAppID` in TRTC, which is generated after the creation of an application
param.roomId   = 1001;           // Room ID
param.userId   = @"rexchang";    // User ID
param.userSig  = @"xxxxxxxx";    // Login signature
params.role     = TRTCRoleAnchor; // Role: anchor
param.streamId = @"stream1001";  // Stream ID
[trtcCloud enterRoom:params appScene:TRTCAppSceneLIVE]; // Please use the `LIVE` mode.

For how to calculate userSig, see UserSig

Method 2: using the default streamId

After relayed push is enabled, if you do not specify a streamId, the system will automatically generate one according to the following rules.

• Fields included

  • SDKAppID, which can be found in TRTC console > Application Management > Application Info.
  • bizid: which can be found in TRTC console > Application Management > Application Info.
  • roomId, which is specified in TRTCParams when you call enterRoom.
  • userId, which is specified in TRTCParams when you call enterRoom.
  • streamType, which is main if the camera image is streamed and aux if the screen sharing image is streamed. WebRTC supports only one upstream channel, so in WebRTC, streamType is main too if the screen sharing image is streamed.

• Format

  `streamId` Generation	Applications created on or after January 9, 2020	Applications created and used before January 9, 2020
  Format	streamId = urlencode(sdkAppId_roomId_userId_streamType)	StreamId = bizid_MD5(roomId_userId_streamType)
  Example	If `sdkAppId` is `12345678`, `roomId` is `12345`, `userId` is `userA`, and the camera image is streamed, the `streamId` will be `12345678_12345_userA_main`.	If `bizid` is `1234`, `roomId` is `12345`, `userId` is `userA`, and the camera image is streamed, the `streamId` will be `1234_MD5(12345_userA_main)`, i.e. `1234_8D0261436C375BB0DEA901D86D7D70E8`.

Step 4. Select a stream mixing scheme.

To play mixed streams, enable On-Cloud MixTranscoding by calling the setMixTranscodingConfig API in TRTCCloud. The TRTCTranscodingConfig parameter of the API allows you to configure:

• The position and size of each image
• The image quality and encoding parameter of the mixed stream

For more information on how to configure the image layout, see On-Cloud MixTranscoding. For the modules involved in the process and their relations, see How It Works.

Note：

setMixTranscodingConfig does not mix streams at the viewer end. Instead, it uploads configurations to the cloud, and mix and transcode streams in cloud servers. The process may take a while as both stream mixing and transcoding involve the decoding and re-encoding of the original audio/video data. Consequently, the latency of playing mixed streams is often 1 or 2 seconds longer than that of playing individual streams.

Step 5. Get the playback address and integrate the player.

After configuring the playback domain name in step 2 and the streamId in step 3, you will get a playback address for live streaming in the following format.

http://playback domain name/live/[streamId].flv

Suppose your playback domain name is live.myhost.com, and you set the live stream ID (streamId) of user A in room 1001 to streamd1001 in the room entry parameter.
You will get three playback addresses:

RTMP: rtmp://live.myhost.com/live/streamd1001
FLV: http://live.myhost.com/live/streamd1001.flv
HLS: http://live.myhost.com/live/streamd1001.m3u8

We recommend http - flv addresses that start with http and end with .flv, as they feature high stability and reliability, low playback latency, and good instant playback performance.
For players, we recommend the integration methods in the following documents.

Platform	Integration Document	API Overview	Supported Format
iOS app	Integration instructions	TXLivePlayer (iOS)	FLV is recommended.
Android app	Integration instructions	TXLivePlayer (Android)	FLV is recommended.
Web browser	Integration instructions	-	Desktop Chrome supports FLV. Safari on macOS and mobile browsers support only HLS.

Step 6. Reduce playback latency.

When relayed push is enabled, because streams are distributed via live streaming CDNs, playback via http - flv addresses tends to have higher latency than direct playback in TRTC call rooms.
The table below lists the average latency of playback via TXLiveplayer using Tencent Cloud’s live streaming CDN technology.

Stream Type	TXLivePlayer Playback Mode	Average Latency	Test Result
Individual streams	Ultrafast mode (recommended)	2-3s	See the left figure (orange) below.
Mixed streams	Ultrafast mode (recommended)	4-5s	See the right figure (blue) below.

If you experience higher latency than the above test results, try reducing the latency by following the steps below.

• Use the built-in TXLivePlayer of the TRTC SDK
  Average players such as ijkplayer or players based on FFmpeg are incapable of controlling latency, but TXLivePlyer comes with a player engine developed in-house by Tencent Cloud, which gives it the ability to control latency.

• Set TXLivePlayer to the ultrafast mode
  You can switch to the ultrafast mode by configuring three parameters of TXLivePlayerConfig. Below is an example of configuration on iOS.
  Example of the configuration code using Objective-C on iOS:

  // Set TXLivePlayer to the ultrafast mode.
   TXLivePlayerConfig * config = [[TXLivePlayerConfig alloc] init];
   config.bAutoAdjustCacheTime = YES;
   config.minAutoAdjustCacheTime = 1; // Min. buffer time: 1s
   config.maxAutoAdjustCacheTime = 1; // Max. buffer time: 1s
   [player setConfig:config];
   // Start playback.
  

Billing

The costs of CDN relayed live streaming include playback fees and transcoding fees. Playback fees are basic service fees, and transcoding fees are charged only if On-Cloud MixTranscoding is enabled.

Note：

The prices used in this document are for reference only. In case of any inconsistencies, the prices specified in CSS > Pricing Overview shall prevail.

Playback fees: cost of playing live streams via CDNs

LVB charges you for playing streams via CDNs based on the downstream traffic generated or bandwidth used. You can choose whichever billing mode fits your need. By default, the bill-by-traffic mode is used. For details, see CSS > Billing of LVB.

Transcoding fees: cost of mixing multiple channels of streams

Stream mixing involves data decoding and encoding, so if you enable stream mixing, an additional stream mixing and transcoding fee will be incurred, which is charged based on the resolution and duration of the streams transcoded. The higher resolution an anchor uses, and the longer co-anchoring (the most common application scenario for stream mixing) lasts, the higher the cost. For details, see CSS > Billing of LVB.

Suppose you use setVideoEncodrParam() to set the bitrate (videoBitrate) for anchors to 1,500 Kbps and resolution to 720p, and an anchor co-anchored with a viewer for 1 hour, during which stream mixing was enabled. The transcoding fee incurred will be 0.0057 USD/min × 60 min=0.342 USD.

FAQ

Why is the video choppy and blurry when there is only one user in the room?
Please set the TRTCAppScene parameter in enterRoom to TRTCAppSceneLIVE.
The VideoCall mode is optimized for video calls, so when there is only one user in a room, TRTC tends to maintain a low bitrate and frame rate to reduce traffic usage, which makes the video choppy and blurry.