In RTMP-based mic connect, the MLVB SDK of Tencent Video Cloud Toolkit offers the MLVBLiveRoom component to help you quickly implement the host competition feature. To better cater to your needs, Tencent Cloud has launched an RTC-based host competition scheme and offered simpler and more flexible V2 APIs.
MLVB’s V2 APIs support publishing/host competition via RTMP as well as RTC. You can choose whichever scheme fits your needs. Below is a comparison of the two schemes.
Item
RTMP
WebRTC
Protocol
Based on TCP
Based on UDP (more suitable for streaming)
QoS
Poor adaptability to bad network connection
Video streaming unaffected with 50% packets loss; audio mic connect unaffected with 70% packets loss
The MLVB SDK provides new V2 APIs via V2TXLivePusher (publishing) and V2TXLivePlayer (playback) to power larger-scale live streaming scenarios with greater flexibility and lower latency. Hosts can use the capabilities provided by the APIs for RTC-based publishing. Audience, by default, play streams via CDNs, whose cost is relatively low. To compete, hosts only need to play each other’s stream. To enable RTC-based host competition, you must activate TRTC.
Below are the UI views of the MLVB-API-Example demo.
UI demonstration
Before streaming
Host A (Phone A)
Host B (Phone B)
Audience of Host A (Phone C)
Competing
Host A (Phone A)
Host B (Phone B)
Audience of Host A (Phone C)
Implementation
As shown in the figure below, both host A and host B have their audience. To compete, they only need to do the following:
Host A starts playing host B’s stream and initiates a stream mixing task to mix his or her stream with host B’s so that his or her audience can watch them compete.
Host B starts playing host A’s stream and initiates a stream mixing task to mix his or her stream with host A’s so that his or her audience can watch them compete.
Audience A and B can continue to play streams via CDNs and will see the competing videos of host A and host B after stream mixing.
1. Host A starts publishing
Host A calls V2TXLivePusher to publish a stream. For how to splice a publishing URL, please see Publish/Playback URL.
Host A and host B call V2TXLivePlayer to play each other’s stream and start RTC-based competition. For how to splice a playback URL, please see Publish/Playback URL.
java
Objective-C
// Host A
V2TXLivePlayer player =newV2TXLivePlayerImpl(mContext);
After host competition starts, audience can watch via one of two methods.
1. Host A’s audience calls V2TXLivePlayer to play host B’s stream, and host B’s audience calls V2TXLivePlayer to play host A’s stream.
2. Host A and host B mix their streams, and audience use the original URL to play the mixed stream.
Host A and host B each initiate a stream mixing task to mix their streams so that their audience can watch them complete. To achieve this, the hosts need to call setMixTranscodingConfig to start On-Cloud MixTranscoding, specifying audio-related parameters including audioSampleRate, audioBitrate, and audioChannels.
remoteA.streamId = @"remoteStreamIdA"; // `streamID` is required for the remote user but not for the local user
remoteA.x = 400; // For reference only
remoteA.y = 800; // For reference only
remoteA.width = 180; // For reference only
remoteA.height = 240; // For reference only
remoteA.zOrder = 1;
// Specify the streams to mix
config.mixStreams = @[local,remoteA];
// Start On-Cloud MixTranscoding
pusher.setMixTranscodingConfig(config);
Note:
Since you need to maintain room and user status by yourself, the new RTC-based scheme may seem more complicated than the old one. In fact, there isn’t an always better scheme, only one that better suits your needs.
You can stick to the old scheme if your application scenarios do not require low latency or high concurrency.
If you want to use V2 APIs without having to manage a room and users, try using Tencent Cloud’s IM SDK to implement the necessary logic.
1. Why is publishing and playback using the same streamid on the same device possible with TXLivePusher and TXLivePlayer but not with V2TXLivePusher and V2TXLivePlayer?
V2TXLivePusher and V2TXLivePlayer are based on Tencent Cloud’s TRTC protocol. This is a UDP-based private protocol that features ultra-low latency and does not support using the same streamid for ultra-low-latency publishing and playback on the same device. We have determined that it’s not necessary to support this given the current use cases, but may consider optimizing the protocol in the future.
2. What are the parameters mentioned in Activate TRTC?
SDKAppID identifies your application, and UserID your user. UserSig is a security signature calculated based on the two parameters using the HMAC SHA256 encryption algorithm. Attackers cannot use your Tencent Cloud traffic without authorization as long as they cannot forge a UserSig. UserSig calculation involves hashing crucial information such as SDKAppID, UserID, and ExpireTime, as shown below.
// UserSig formula, in which `secretkey` is the key used to calculate UserSig
The error code -5 means failure to call an API due to invalid license. The enumerated value is V2TXLIVE_ERROR_INVALID_LICENSE. For other error codes, please see V2TXLiveCode.
5. What is the typical latency of RTC-based mic connect?
In the new RTC-based mic connect scheme, the mic connect latency is lower than 200 ms, and the latency for hosts and audience is 100-1,000 ms.
6. What should I do if the 404 error occurs when I try to play streams via CDNs after successfully publishing streams over RTC?
Check if you have enabled TRTC’s relayed push feature. The feature is needed because, after publishing streams via RTC, to enable CDN playback, you need to relay the streams to CDNs.
Yes
No
Was this page helpful?