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.
xxxxx.livepush.myqcloud.comhas been added to the list.
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 LVB services once the configuration takes effect. For detailed directions, see Configuring CNAME for Domain Name.
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.comto the domain list of the LVB console, which is the default push domain name used by LVB and TRTC and cannot be modified.
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.
You can specify a live stream ID by setting
TRTCParams when calling the
enterRoom function in
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
After relayed push is enabled, if you do not specify a
streamId, the system will automatically generate one according to the following rules.
TRTCParamswhen you call
TRTCParamswhen you call
mainif the camera image is streamed and
auxif the screen sharing image is streamed. WebRTC supports only one upstream channel, so in WebRTC,
maintoo if the screen sharing image is streamed.
|`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
TRTCTranscodingConfig parameter of the API allows you to configure:
setMixTranscodingConfigdoes 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.
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.
The prices used in this document are for reference only. In case of any inconsistencies, the prices specified in LVB > Purchase Guide > LVB 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 LVB > Purchase Guide > Basic Services > Billing Details > Traffic and Bandwidth.
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 LVB > Purchase Guide > Basic Services > Billing Details > LVB Transcoding.
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.
Why is the video choppy and blurry when there is only one user in the room?
Please set the
TRTCAppScene parameter in
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.