Scene Description
Live streaming with goods is an emerging e-commerce model that allows anchors to interact in real time with the audience via live streaming platforms, showcasing and promoting products, thereby selling them. In this scene, anchors typically present various products in the live streaming rooms, including clothing, cosmetics, and household items, and explain product features, discount information, and usage methods to the audience. Audiences can ask questions, comment, and purchase products in the live streaming rooms, achieving instant communication and transactions. By using Tencent Cloud Tencent Real-Time Communication (TRTC) combined with Instant Messaging (IM) and other products, you can easily set up a live shopping streaming room. Implementation Scheme
Typically, implementing a complete live streaming with goods scene involves several functional modules: Room Management, Seat Management, Product Management, Audio and Video Management, On-Cloud Recording, etc. The key actions and feature points under each functional module are shown in the table below. Each functional module will be introduced individually to provide a comprehensive understanding of the functionalities required for building a live shopping scene. |
Room Management | Create a room, enter a room, exit a room, and destroy a room. |
Seat Management | Request to speak, become a listener, invite a listener to speak, remove a speaker, and mute a speaker. |
Product Management | Product list management, product pop-up management, and jump and payment. |
Audio and Video Management | Local streaming, remote pull-streaming, and audience Mic connection. |
On-Cloud Recording | TRTC on-cloud recording. |
The overall business architecture of the live streaming with goods scene is shown in the figure below. The speaker creates a room, and other users can join the rooms they are interested in. Upon entering the room, users off the microphone can join the microphone to interact with the speaker via audio and video. The speaker is also responsible for maintaining the product list, and explaining and publishing products. Typically, for compliance requirements, the audio and video content in the live streaming room needs to be recorded and reviewed.
Note:
The solution shown here is the RTC real-time interactive live streaming solution. In actual applications, the RTC CDN live streaming solution may also be used. For details, please refer to Alternative Solutions. Room Management
The Room Management Module is primarily responsible for maintaining the room list and includes the following features:
Create Room: After users log in to the business system, they can create a room. The room list needs to be updated after a room is created.
Enter a Room: Users can choose to enter an existing room. Upon entering, the current list of room members should be updated.
Exit a Room: Users can choose to exit the current room. Upon exiting, the current list of room members needs to be updated with a delete operation.
Destroy a Room: After all users exit the room, it needs to be destroyed. Upon destruction, the room list needs to be updated with a delete operation.
Note:
Room Management is a necessary module for implementing live shopping, but it is not the main functional module. It can be implemented in conjunction with the business system and IM&TRTC SDK, see Voice Chat Room - Room Management for details. Seat Management
Seats in a live streaming room are generally ordered and limited. Seat Management is primarily responsible for defining the number of seats in a room based on the business scene, as well as managing the status of all seats in the current room. Seat Management mainly includes: request to speak, become a listener, invite a listener to speak, remove a speaker, and mute a speaker.
After users enter a room, only idle seats can be applied for.
After the anchor approves a user to become a speaker, the seat status needs to be changed to non-idle.
After becoming a listener, the co-anchoring user needs to stop local streaming and reset the seat status.
The anchor has the authority to lock the seat, invite a listener to speak, remove a speaker, mute a speaker, etc.
Note:
Seat Management is a necessary module for implementing live shopping, but it is not the main functional module. It can be implemented in conjunction with the business system and IM&TRTC SDK, see Voice Chat Room - Seat Management for details. Product Management
The Product Management Module is unique to live shopping scenes and generally includes product list management, product pop-up management, product link jump, and payment. The following image displays the basic process of product management:
Product List Management
Product list management is the basic feature of product management, mainly including the addition, deletion, modification, and query of products. Usually, we store various information about products in the backend database, such as product name, description, price, inventory, and images. On the frontend, we can obtain this information through APIs and display it to users in the form of a list.
Product Pop-up Management
During the process of live streaming with goods, as the anchor talks about and lists products, it's often necessary to pop up corresponding product information on the audience's end to prompt them to browse and purchase. The product information pop-up feature can be achieved in the following two ways. You can choose one based on your business needs:
Custom Message
Generally, product information pop-ups can be achieved by sending custom messages to the live streaming room, and parsed and displayed after the audience in the live streaming room receives the custom messages. The sending and receiving of custom messages can be implemented by the business side or through Tencent Cloud Instant Messaging (IM) Group Messages. For specific implementation, see Product Information Pop-up - Custom Messages. SEI Information
SEI (Supplemental Enhancement Information) provides a method to add additional information to a video stream. You can use Tencent Real-Time Communication (TRTC) Sending SEI Information to insert specified product information into the anchor's video stream. The audience in the live streaming room who are watching the stream can receive SEI messages, which will then be parsed and displayed. Based on the characteristics of SEI, this method can achieve precise synchronization between product information pop-ups and the anchor's live streaming screen. For specific implementation, see Product Information Pop-up - SEI Information. Product Link Jump and Payment
After selecting products in the live streaming room, the audience needs to click on the product link, and jump to the specific E-commerce shop for order confirmation and payment. The E-commerce shop here can be an in-platform store or an integrated third-party platform store. After the user completes the payment, we also need to obtain the payment result to update the sales status and inventory information of the product.
Note:
The above product management module is for reference only. In actual applications, you need to design and deploy according to your business needs.
Audio and Video Management
For standard live shopping scenes (audience size not exceeding 100,000 people), we recommend the RTC Real-time Interaction Solution: both the anchor and the audience use the RTC protocol for publishing/playback, minimizing end-to-end delay and ensuring a smoother experience for the audience when joining and leaving the mic, without abrupt changes such as image fast-forwarding or rewinding. Taking the example of multi-person co-anchoring interactive live streaming, the main architecture of pure RTC publishing/playback in a live shopping scene is as shown in the figure below:
The overall process of this solution architecture is as follows:
1. Both the anchor and audience connect through the signaling module, which is mainly responsible for controlling the live streaming process and synchronizing the live streaming status.
2. Regardless of whether there are mic-connecting audiences or not, both the anchor and the audience use the TRTC audio and video cloud service for publishing/playback.
3. After the audience requests to mic connect with the anchor, the signaling module will notify the anchor and synchronize the personal information of the co-speakers.
4. Once the anchor accepts the mic connection request, the mic-connecting audience starts streaming, and all members in the room receive stream update notifications and pull the audio-video stream of the mic-connecting audience.
5. When a mic-connecting audience member requests to disconnect, they stop streaming. All members in the room will receive stream update notifications and stop pulling that audience's audio and video stream.
Note:
The signaling module can be a custom-developed signaling channel, and it is also recommended to use Instant Messaging (IM) for signaling interaction. For large-scale live shopping scenes (with over 100,000 audience members in a single room), it is necessary to use the RTC CDN live streaming solution. For details, see Alternative Solutions. On-Cloud Recording
TRTC's newly upgraded on-cloud recording does not depend on cloud streaming services. It does not require a relayed push for cloud live streaming and uses TRTC's internal real-time recording cluster for audio and video recording, offering a more comprehensive and unified recording experience.
Single Stream Recording: With TRTC's on-cloud recording feature, you can record the audio and video stream of each user in the room into separate files.
Mix Stream Recording: Record the audio-video media streams of the same room as a single file.
Note:
For a detailed introduction and activation guide to TRTC On-Cloud Recording, see On-Cloud Recording. Key Business Logic
Product Explanation Replay
Product Explanation Replay is an essential feature for live shopping scenes, which is generally divided into In-live Replay and Post-live Replay. Product Explanation Replay helps latecomers and users who missed the live streaming to independently review the product explanation given during the live streaming by the anchor, thus increasing sales volume and improving the conversion rate. The Product Explanation Replay feature can be implemented in the following two ways.
Recorded Replay
Recorded Replay is a common way to implement the Product Explanation Replay feature, which is simple to implement and does not limit the timing of the replay. Below is the basic process for implementing Product Explanation Replay using Recorded Replay.
1. Record Explanation Material
Single Stream Recording: Record each anchor's audio and video stream in the room into separate audio and video files and upload them to the cloud storage platform.
Mixed Stream Recording: Mix all the audio and video streams of all anchors you subscribe to in the room into one audio and video file and upload it to the cloud storage platform.
Recording Format: When the file is stored in COS, the default recording format is HLS; you can modify the recorded file format through the OutputFormat parameter under RecordParams. When the file is stored in VOD, the default recording format is MP4; you can modify the recorded file format through the MediaType parameter under TencentVod. To start on-cloud recording, call the REST API (CreateCloudRecording) through your backend service. Pay special attention to the parameter Task ID (TaskId); this parameter is the unique identifier for this recording task. You need to save this Task ID as it will be required for subsequent operations related to this recording task. Note:
In the CreateCloudRecording API to initiate on-cloud recording tasks, you need to specify the parameters UserId and UserSig needed for assigning a recording Chatbot to enter the room (How to Obtain UserSig). Please ensure that the UserId is not duplicated with those of the regular anchors or audience in your room and does not match the UserId of a recording Chatbot already assigned to a room in the midst of recording; otherwise, it will lead to the failure of the recording task. You can timely stop on-cloud recording tasks by calling the REST API (DeleteCloudRecording) through your backend service, requiring the Task ID (TaskId) parameter returned when starting the recording task. 2. Obtain Playback Address
Method 1: Manual Search
After the recording task ends, the files recorded by the TRTC recording system will be uploaded to the cloud storage platform specified by you (Cloud Video on Demand (VOD) or Cloud Object Storage (COS)). You can directly go to the VOD Console or COS Console to locate the desired recorded media files and manually obtain the playback address. Method 2: Callback Reception
You can also configure the recording callback URL in the console, allowing the cloud platform to proactively push the message of new recording files to your server. After the recording file is successfully transferred, the cloud platform will send a notification to your server through the callback address (HTTP/HTTPS) set in the console. It will push the recording and related events to your server through the callback address you set. You can receive the playback address VideoUrl of the recording file by accepting the upload success callback with an event type of 311. The callback example information is as follows: {
"EventGroupId": 3,
"EventType": 311,
"CallbackTs": 1622191965320,
"EventInfo": {
"RoomId": "20015",
"EventTs": 1622191965,
"UserId": "xx",
"TaskId": "xx",
"Payload": {
"Status": 0,
"TencentVod": {
"UserId": "xx",
"TrackType": "audio_video",
"MediaId": "main",
"FileId": "xxxx",
"VideoUrl": "http://xxxx",
"CacheFile": "xxxx.mp4",
"StartTimeStamp": xxxx,
"EndTimeStamp": xxxx
}
}
}
}
3. Play Recorded Video
After completing the preliminary preparations, you can call startVodPlay
of TXVodPlayer to play the recorded product explanation video. TXVodPlayer will automatically recognize the playback protocol, and you only need to pass the playback URL to the startVodPlay
function. For more code examples, please see Quick Integration Guide - Product Explanation Replay.
String url = "http://1252463788.vod2.myqcloud.com/xxxxx/v.f20.mp4";
mVodPlayer.startVodPlay(url);
NSString* url = @"http://1252463788.vod2.myqcloud.com/xxxxx/v.f20.mp4";
[_txVodPlayer startVodPlay:url];
Note:
For on-demand playback, the Player SDK is needed, but there's no need for separate integration, and you just need to integrate the full feature version of LiteAVSDK, as detailed in Quick Access Guide - Import SDK. Live Streaming Time Shift
Live Streaming Time Shift can also achieve the product explanation replay feature, but it only supports revisiting the product explanation during the live streaming and does not support replay after the live streaming. Below is the basic process of using Live Streaming Time Shift for product explanation replay.
1. Enable Relayed Push
Global Automatic Relayed Push
If you need to automatically relay all anchors' audio and video streams in the room to live streaming CDN, you need to enable Relay to CDN in the TRTC console Advanced Features page. Relayed Push of the Specified Streams
If you need to manually specify the audio and video streams to be published to live streaming CDN, or publish the mixed audio and video streams to live streaming CDN, you can do so by calling the startPublishMediaStream API. In this case, you do not need to activate global automatically relaying to CDN in the console. For a detailed introduction, see Publish Audio and Video Streams to Live Streaming CDN. 2. Create Time Shift Template
3. Construct Play Request
Live Streaming Time Shift can only be distributed through the HLS protocol. Specify the time to revisit in the M3U8 request parameters, which is the time segment when the anchor explains the product.
The general HLS live streaming address format is http://domain/appname/stream.m3u8
. To support the time shift playback, time shift parameters need to be appended to this address, as shown in the table below:
|
txTimeshift | Value on: enable new live streaming time shift. | Yes | txTimeshift=on |
tsStart | Time shift start time, the interval between tsStart and tsEnd cannot be less than the duration of one Ts shard and cannot be more than 6 hours. | Yes | tsStart=20121010010101 |
tsEnd | Time shift end time, the interval between tsStart and tsEnd cannot be less than the duration of one Ts shard and cannot be more than 6 hours. | Yes | tsEnd=20121010010102 |
tsFormat | The value format for tsStart and tsEnd is {timeformat}_{unit}_{zone} . timeformat value: unix: unix timestamp. If 'unix' is selected, the 'zone' part can be ignored. human: human-readable time, 20121010010101 unit: s/ms, unit in seconds or milliseconds zone: Time zones are divided into East and West Zones: The range for the East Zone is 1 ~ 12. The range for the West Zone is -12 ~ -1. | Yes | tsFormat=unix_s tsFormat=human_s_8 |
tsCodecname | For transcoding streams, it's necessary to specify the template name. Original streams and watermark streams do not carry this field. | No | tsCodecname=hd |
Below are examples of playback requests for both time formats:
// Playback request with unix-format time
http://example.domain.com/live/stream.m3u8?txTimeshift=on&tsFormat=unix_s&tsStart=1675302995&tsEnd=1675303025&tsCodecname=test
// Playback request with human-format time
http://example.domain.com/live/stream.m3u8?txTimeshift=on&tsFormat=human_s_8&tsStart=20230202095635&tsEnd=20230202095705&tsCodecname=test
Note:
The Live Streaming Time Shift feature is a paid value-added service. Using the Live Streaming Time Shift feature will generate a time-shift bill, see Billing Documentation for billing rules. The Live Streaming Time Shift feature is only applicable to RTC CDN live streaming solutions. For more details on implementing the Live Streaming Time Shift feature, see Live Streaming Time Shift. Integrating Beauty Effect
In the live shopping scene, the beauty effect is also a frequently used feature. It not only improves the beauty of the anchor but also adds fun to live interaction through various sticker effects. TRTC supports the integration of Tencent Effect SDK as well as the integration of mainstream third-party beauty effect products in the market, such as Volcano Beauty, and FaceUnity. Beauty Effect Integration Process
API Call Sequence
Comparison of Beauty Products
|
| The basic effect is good, advanced effect for big eyes/slim faces is significant. | Moderately Low | Moderate | Supported | Android/iOS/PC/Flutter/Web/Mini Program |
| The basic effect is good, advanced effects like big eyes/slim faces are average. | Moderately High | Moderate | Supported | Android/iOS/PC/Untiy |
| The basic effect is good, advanced effects like big eyes/slim faces are relatively good. | Moderately High | Relatively High | Supported | Android/iOS/PC/Linux |
Cross-room Co-hosting Competition
Connecting anchors across rooms for cross-room competition is a novel approach in the live shopping scene. Interactive competition can enhance the entertainment value of live streaming and to some extent, and stimulate the audience's desire to shop. TRTC supports cross-room competition across multiple rooms and among multiple anchors. Below, we introduce specific implementation methods.
1. How It Works
By default, only users in the same room can have audio and video calls, and the audio and video streams between different rooms are isolated. Through the cross-room competition, the audio and video streams of an anchor in another room can be published in the current room, while the audio and video streams of the current anchor will also be published in the target anchor's room. This allows anchors in different rooms to share audio and video streams across rooms, enabling audiences in each room to watch the audio and video of both anchors.
The figure above shows the main process of cross-room competition. For example: After anchor A in room 101 establishes a cross-room call with anchor B in room 102 using ConnectOtherRoom()
:
Users in room 101 will receive two event callbacks from anchor B: onRemoteUserEnterRoom(B)
and onUserVideoAvailable(B,true)
. Therefore, users in room 101 can subscribe to the audio and video of anchor B.
Users in room 102 will receive two event callbacks from anchor A: onRemoteUserEnterRoom(A)
and onUserVideoAvailable(A,true)
. Therefore, users in room 102 can subscribe to the audio and video of anchor A.
Note:
Both local and peer users participating in cross-room competition must be in the anchor role and must have audio/video uplink capabilities.
Cross-room competition with multiple room anchors can be achieved by calling ConnectOtherRoom()
multiple times. Currently, a room can connect with up to three other room anchors at most, and up to 10 anchors in a room can conduct cross-room competition with anchors in other rooms.
TRTC cross-room competition can also be achieved by createSubCloud()
to create a sub-instance and join the publishing/playback of another room. Currently, there is no limit to the number of sub-instances, facilitating the future expansion of business scenes involving PK between multiple rooms or anchors.
2. Real-Time Interactive Cross-Room Competition Process
RTC real-time interaction solution The cross-room competition process is straightforward. Anchors and cross-room competition anchors mutually pull RTC single streams, and the audience simultaneously pulls the RTC single streams of both anchors and cross-room competition anchors. The audience can independently control the subscription logic of the media streams of anchors and cross-room connecting anchors. The RTC real-time interactive cross-room competition process is shown in the figure below: Note:
In real-time interactive cross-room competition scenes, audiences in the room can independently control the logic of subscribing to the media streams of cross-room connecting anchors, or it can be changed by the room owner to <1>change the uplink capability of a cross-room anchor in their rooms<1>.
Alternative Solutions
RTC CDN Live Streaming Solution
The anchor uses the TRTC protocol for publishing/playback and relayed push of Tencent Cloud Streaming Services or a third-party live streaming platform. General audiences pull the CDN stream to watch while mic-connecting audiences engage in interactive co-anchoring by switching to the TRTC protocol for streaming. This solution is a commonly used compromise, with a higher delay for both watching and mic connecting on the audience side. However, it offers advantages in terms of cost-effectiveness and audience scalability. The whole architecture is shown in the figure below:
The overall process of this solution is as follows:
1. The anchor enters the TRTC room, streams via the RTC protocol, and relays to Cloud Streaming Services.
2. Ordinary off-mic audiences pull CDN accelerated streams and watch through live streaming players.
3. Audiences can request to speak and become the mic-connecting audiences. They stop the CDN streaming and switch to the RTC protocol for publishing/playback.
4. Audiences off the mic become general audiences. They stop the RTC protocol publishing/playback and switch to the CDN streaming.
CDN stream playback addresses support multiple protocols such as RTMP/FLV/HLS/WebRTC, with splicing rules detailed in Splicing Playback URL. Different live streaming playback protocols have varying compatible platforms, play delays, and billing rules. See the table below for details:
|
FLV | Mature, suited for high-concurrency scenes | Requires integration of SDK for playback | 2s - 3s |
RTMP | Relatively low delay | Poor performance in high-concurrency scenes | 1s - 3s |
HLS(M3U8) | High support on mobile browsers | Very high delay | 10s - 30s |
WebRTC | Lowest delay | Requires integration of SDK for playback | < 1s |
Note:
Tencent Cloud Streaming Services supports multiple playback protocols. You can choose the appropriate pull stream solution based on your business needs. For example, for delay-sensitive businesses, LEB pulling stream is recommended. HLS and WebRTC playback protocols support the adaptive bitrate feature, which allows smooth switching of playback bitrate under different network conditions. See Adaptive Bitrate for details. Smooth Mic On/Off Handling
In single-anchor low-frequency mic connection live streaming scenes, due to cost considerations, RTC CDN live streaming solutions or third-party live streaming publishing/playback solutions are often used. In single-anchor streaming, the anchor streams via RTC or third-party live streaming, while audiences pull streams via CDN. In interactive co-anchoring scenes, both the anchor and audiences stream via RTC. This involves switching between publishing/playback tools while maintaining a seamless experience for users. Below are the specific methods for smooth mic on/off handling in both the RTC CDN live streaming and third-party live streaming publishing/playback solutions.
1. RTC CDN Live Streaming Solution
Under the RTC CDN live streaming solution, the anchor always uses the TRTC SDK for publishing/playback. During mic connects, only the mic-connecting audience needs to switch the publishing/playback tools, and the rendering control can be reused.
2. Third-Party Live Streaming Publishing/Playback Solution
In the third-party live streaming publishing/playback solution, during mic connects, both the anchor and the mic-connecting audience need to switch the publishing/playback control. It is recommended to use TRTC's custom capture and rendering features.
Note:
Smooth Mic on: To avoid screen interrupts when switching the stream puller, it is suggested to wait for the TRTC's first frame callback onFirstVideoFrame
before stopping the CDN streaming.
Smooth Mic off: To avoid screen interrupts when switching the stream puller, it is suggested to wait for the video play event onVideoPlaying
before stopping the RTC streaming.
CDN Live Streaming in Cross-Room Competition
In the RTC CDN live streaming scene, the process of cross-room competition is relatively complex. Anchors pull RTC single streams from each other and CDN audiences pull the mixed streams from both the anchor and the cross-room competition anchor. Audiences cannot independently control the subscription logic of the anchor and cross-room competition anchor's media streams. The process for cross-room competition in a CDN live streaming scene is shown in the figure below:
Note:
In the CDN live streaming in cross-room competition scene, CDN audiences cannot independently control the subscription logic of the cross-room connected anchor's media stream. It needs to be uniformly controlled by the anchor through updating and publishing the media stream. Scene Approach
Single-anchor Live Streaming with Goods
Single-anchor live streaming with goods is the most common and basic approach in live shopping scenes. In such a scene, there is only one anchor in the live streaming room, and roles such as co-anchor do not exist. Audiences can enter the live streaming room to watch the live streaming, interact, and shop. The single-anchor live streaming with goods scene is recommended to use the RTC CDN Live Streaming Solution. Multi-person Co-anchoring Interactive Live Streaming with Goods
Based on the single-anchor live streaming with goods scene, the multi-person co-anchoring interactive live streaming with goods scene provides the approach of inviting the audience to have a mic on for interaction with the anchor. Anchors can invite the audience to take the mic and control the seats; audiences can also actively request to speak for interaction with the anchor. This approach enhances the audience's sense of participation and motivates the audience. This scene is recommended to use the RTC Real-time Interaction Solution. Cross-room Competition and Mic Connection Live Streaming with Goods
Besides the traditional single-room anchor live streaming with goods, anchors can also engage in cross-room competition with another live streaming room's anchor to showcase their products, ignite the audience's purchasing enthusiasm, and increase the live streaming's entertainment value. Live streaming with goods in cross-room competition is a popular novel approach. In this scene, the RTC Real-time Interaction Solution or RTC CDN Live Streaming Solution can be selected based on business needs.
Supporting Products for the Solution
|
Access Layer | | Provides a low-delay, high-quality multi-person audio and video real-time interaction live streaming solution, which is a foundational capability for live shopping scenes. |
Access Layer | | Provides room management and seat management capabilities based on group features, enables the sending and receiving of rich media messages such as live streaming room-wide messaging, public screen messages, as well as custom signaling and other communication needs. |
Access Layer | | Provides real-time effects processing capabilities such as beauty, filtering, makeup, fun stickers, emojis, and virtual avatars. |
Cloud Services | | Provides real-time audio and video relayed push, along with accelerated media stream distribution services, as well as additional capabilities such as recording and pornography detection. |
Cloud Services | | Catering to media such as audio, video, and images, it offers an integrated high-quality media service that includes creation, upload, storage, transcoding, media processing service, media AI, accelerated distribution and playback, and copyright protection. |
Data Storage | | Provides storage services for audio and video recording files, as well as audio and video slicing files. |
Was this page helpful?