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.
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.
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.
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..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.
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.
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
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
TRTCParams
when you call enterRoom
.TRTCParams
when you call enterRoom
.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`. |
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:
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.
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. |
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.
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.
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.
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 be0.0057 USD/min × 60 min=0.342 USD
.
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.
Was this page helpful?