Live broadcast stream file switching method and device
By receiving client requests and aligning timestamps, the lag caused by live stream switching is solved, and unsensed smooth switching is achieved, and the continuity and fluency of live streams are improved.
Patent Information
- Application Number
- CN202510837329.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-20
- Publication Date
- 2025-08-08
AI Technical Summary
The existing live stream switching method causes user equipment to need to be reinitialized when the network conditions change, resulting in a stuttering and unsmooth viewing experience.
By receiving the client's handover request, return to the original and target clarity live stream and perform timestamp alignment, ensuring smooth switching to the target live stream without the user's perception.
It realizes no-perception switching of live streams, ensures the continuity and fluency of live streams, and improves user viewing experience.
Smart Images
Figure CN120455727A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the fields of artificial intelligence and cloud computing technology, and in particular to the fields of video cloud and audio and video live broadcast technology. Background Art
[0002] In live streaming scenarios, the host uses their device to push a live stream to the live streaming service. Users use their own devices to download the host's live stream and then play it. Since there is only one host, the data bitrate of the push stream is determined by the host. However, different users have different device types (e.g., high-end, mid-range, low-end, etc.) and network types (e.g., Wi-Fi, mobile data, etc.), and users' network status can change in real time (e.g., when entering an elevator). To accommodate different user needs, live streaming services typically transcode the host's push stream into live streams of different resolutions, allowing users to pull the appropriate live stream based on their device type and network conditions.
[0003] Live stream switching allows you to pull a high-definition live stream when network conditions improve, and a low-definition live stream when network conditions deteriorate. Currently, a common method for switching live streams is to re-initiate a stream pull to the new target resolution when the client detects that the network condition has improved or deteriorated. This newly initiated stream pull reinitializes all resources related to the client and playback. Summary of the Invention
[0004] The embodiments of the present disclosure provide a live streaming switching method, apparatus, device, storage medium, and program product.
[0005] In a first aspect, an embodiment of the present disclosure proposes a live stream switching method, comprising: receiving a switching request sent by a client, wherein the switching request includes a target clarity; returning to the original live stream and a target live stream corresponding to the target clarity, and sending the original live stream to the client; aligning the original live stream and the target live stream with timestamps; in response to determining that the alignment is successful, stopping sending the original live stream and sending the target live stream to the client.
[0006] In a second aspect, an embodiment of the present disclosure proposes a live stream switching device, comprising: a receiving module, configured to receive a switching request sent by a client, wherein the switching request includes a target clarity; a retrieval module, configured to retrieval the original live stream and a target live stream corresponding to the target clarity, and send the original live stream to the client; an alignment module, configured to align the timestamps of the original live stream and the target live stream; and a sending module, configured to stop sending the original live stream in response to determining that the alignment is successful, and send the target live stream to the client.
[0007] In a third aspect, an embodiment of the present disclosure proposes an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method described in the first aspect.
[0008] In a fourth aspect, an embodiment of the present disclosure proposes a non-transitory computer-readable storage medium storing computer instructions, where the computer instructions are used to enable a computer to execute the method described in the first aspect.
[0009] In a fifth aspect, an embodiment of the present disclosure proposes a computer program product, including a computer program, which implements the method described in the first aspect when executed by a processor.
[0010] The key or important features of the embodiments of the present disclosure are not intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Other features, objects, and advantages of the present disclosure will become more apparent upon reading the detailed description of the non-limiting embodiments made with reference to the following drawings. The drawings are provided for a better understanding of the present disclosure and do not constitute a limitation of the present disclosure. Among them: Figure 1 is a flow chart of an embodiment of a live streaming switching method according to the present disclosure; Figure 2 is a flowchart of another embodiment of the live streaming switching method according to the present disclosure; Figure 3 This is a flow chart of an application scenario in which the live streaming switching method according to an embodiment of the present disclosure can be implemented; Figure 4 This is the effect diagram of the live stream switching when the target live stream is slower than the original live stream; Figure 5 This is the effect diagram of the live stream switching when the target live stream is faster than the original live stream; Figure 6 1 is a structural diagram of an embodiment of a live streaming switching device according to the present disclosure; Figure 7 It is a block diagram of an electronic device used to implement the live streaming switching method according to an embodiment of the present disclosure. DETAILED DESCRIPTION
[0012] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding. These details should be considered as merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.
[0013] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in the present disclosure may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.
[0014] Figure 1 A process 100 of an embodiment of a live streaming switching method according to the present disclosure is shown. The live streaming switching method includes the following steps: Step 101: Receive a file switching request sent by a client.
[0015] In this embodiment, the execution subject of the live streaming switching method can receive a switching request sent by the client.
[0016] The live streaming switching method is typically performed by a server. The server can be either hardware or software. If the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers or as a single server. If the server is software, it can be implemented as multiple software programs or software modules (for example, to provide distributed services) or as a single software program or software module. This is not specifically limited here.
[0017] In live streaming scenarios, hosts can use their devices to push live streams to the live streaming service. The live streaming service can transcode the stream pushed by the host into live streams of different resolutions. Users can play and view the live stream at the corresponding resolution based on their client type and network conditions. While watching the live stream, if the client detects changes in network conditions, it can determine the target resolution based on the changed network conditions and send a request to switch the stream.
[0018] A time switching request can be a time switching signal sent by the client, which specifies the target resolution. For example, the time switching request can be a specially formatted message sent over a UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) connection. The message can carry text information, which can include the target resolution.
[0019] When the network condition deteriorates, the target clarity will be lower than the original live stream clarity to ensure smooth viewing for users. When the network condition improves, the target clarity will be higher than the original live stream clarity to enhance the user viewing experience.
[0020] Step 102: Return the original live stream and the target live stream corresponding to the target definition, and send the original live stream to the client.
[0021] In this embodiment, after receiving the switching request, the above-mentioned execution entity can return to the original live stream and the target live stream corresponding to the target definition, and send the original live stream to the client.
[0022] When the live streaming service transcodes the live stream pushed by the host into live streams of different resolutions, it can cache these live streams. Therefore, when the user returns to the target live stream, they first return to the cached target live stream. After a period of time, when the cached target live stream has been returned to the source, the live streaming service will return to the target live stream converted in real time. Because the live stream speed is determined by the real-time live stream, it is necessary to return to the original live stream and the target live stream simultaneously for a period of time to pass the stage of pulling the cached target live stream and enter the stage of pulling the real-time target live stream. Only then can the speed of the original live stream and the target live stream be compared.
[0023] In some embodiments, the original live stream and the target live stream are returned to the source until at least one of the following conditions is met, thereby ensuring that the stage of pulling the real-time target live stream is entered: First, the original live stream and the target live stream are simultaneously retrieved until a preset duration threshold is exceeded. The preset duration threshold can be an empirical value, such as 2 seconds. Typically, 2 seconds is sufficient to completely retrieve the cached target live stream.
[0024] Second, the original live stream and the target live stream are simultaneously replayed until the ratio of the playback timestamp interval to the reception timestamp interval of two consecutive frames of the target live stream is less than a preset ratio threshold. The preset ratio threshold can be an empirical value, such as 1.5.
[0025] Step 103: align the timestamps of the original live stream and the target live stream.
[0026] In this embodiment, the execution entity may align the timestamps of the original live stream and the target live stream, thereby aligning the same video frames in the original live stream and the target live stream to the same position.
[0027] Because live streams of different resolutions are re-encoded using a transcoding service compared to the live stream pushed by the host, there will be a certain delay between these streams and the live stream pushed by the host. When switching from a low-latency live stream to a high-latency live stream, or vice versa, by properly handling the delay, the original live stream can be aligned with the target live stream.
[0028] Step 104 : In response to determining that the alignment is successful, stop sending the original live stream and send the target live stream to the client.
[0029] In this embodiment, when the original live stream and the target live stream are successfully aligned, the sending of the original live stream can be stopped and the target live stream can be sent to the client, thereby achieving smooth switching from the original live stream to the target live stream without the user noticing, so that the live stream viewed by the user is continuous and smooth.
[0030] The disclosed embodiments provide a method for switching live streams. By aligning the timestamps of the original live stream back to the target live stream, the method can find the appropriate time to smoothly switch the original live stream to the target live stream. This ensures that the live stream viewed by users is continuous and smooth, without causing any lag on the client. Furthermore, the user is unaware of the switching operation, which can enhance the user's viewing experience.
[0031] Continue to refer Figure 2 , which shows a process 200 of another embodiment of a live streaming switching method according to the present disclosure. The live streaming switching method includes the following steps: Step 201: Receive a file switching request sent by a client.
[0032] Step 202: Return the original live stream and the target live stream corresponding to the target definition, and send the original live stream to the client.
[0033] In this embodiment, the specific operations of steps 201-202 are already described in Figure 1 In the illustrated embodiment, steps 101-102 are described in detail and will not be repeated here.
[0034] Step 203 : Determine whether the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream is less than a first preset time difference threshold.
[0035] In this embodiment, the live stream switching method may determine whether the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream is less than a first preset time difference threshold. If the difference is not less than the first preset time difference threshold, step 204 is executed; if the difference is less than the first preset time difference threshold, step 205 is executed.
[0036] The synchronization of the two live streams can be determined based on the timestamps of the latest video frames of the two live streams returned to the source. If the absolute value of the difference between the timestamps of the latest video frames of the two live streams is not less than a first preset time difference threshold, it indicates that the two live streams are significantly different and an abnormality may have occurred. If the absolute value of the difference between the timestamps of the latest video frames of the two live streams is less than the first preset time difference threshold, it indicates that the two live streams are basically synchronized.
[0037] Step 204: Determine that the alignment fails, and stop returning to the source target live stream.
[0038] In this embodiment, if the absolute value of the timestamp difference between the latest video frame of the original live stream and the latest video frame of the target live stream is not less than a first preset time difference threshold, it indicates that the original live stream and the target live stream differ significantly and an abnormality may have occurred. The execution entity may determine that the alignment has failed and stop returning to the target live stream. At this point, the original live stream continues to be sent to the client.
[0039] Step 205 : Determine whether the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream is greater than a second preset time difference threshold.
[0040] In this embodiment, if the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream is less than a first preset time difference threshold, indicating that the original live stream and the target live stream are substantially synchronized, the execution entity may determine whether the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream is greater than a second preset time difference threshold. If it is not greater than the second preset time difference threshold, step 206 is executed; if it is greater than the second preset time difference threshold, step 209 is executed. The second preset time difference threshold is less than the first preset time difference threshold.
[0041] Step 206: Determine that the timestamp of the latest key frame of the target live stream is the same as the timestamp of the latest key frame of the original live stream.
[0042] In this embodiment, if the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream is not greater than the second preset time difference threshold, the execution entity may determine whether the timestamp of the latest key frame of the target live stream is the same as the timestamp of the latest key frame of the original live stream. If the timestamp of the latest key frame of the target live stream is the same as the timestamp of the latest key frame of the original live stream, it indicates that the latest key frame of the original live stream is aligned with the latest key frame of the target live stream, and step 207 is executed.
[0043] Live streams are composed of groups of video frames. These groups typically consist of three types of frames: key frames, predictive coded frames, and bidirectional predictive coded frames. Key frames are independently coded frames that do not rely on other frames for decoding. They contain complete image information and can be decoded into a complete picture on their own. Each video frame group begins with a key frame. Predictive coded frames are encoded using motion prediction using the previous key frame or predictive coded frame. Predictive coded frames record changes relative to a reference frame. Bidirectional predictive coded frames are bidirectionally predictively coded using the previous and next key frames or predictive coded frames. Bidirectional predictive coded frames offer the highest compression ratio but require more computing resources for decoding.
[0044] Step 207 : Continue sending the original live stream until the next key frame of the target live stream is returned to the source, and the current video frame group of the original live stream is sent, and it is determined that the alignment is successful.
[0045] In this embodiment, if the timestamp of the latest key frame of the target live stream is the same as the timestamp of the latest key frame of the original live stream, the above-mentioned execution entity can continue to send the original live stream until it returns to the next key frame of the target live stream, and the current video frame group of the original live stream is sent, it is determined that the alignment is successful, and step 208 is executed.
[0046] When the latest key frame of the original live stream is aligned with the latest key frame of the target live stream, when the source returns to the next key frame of the target live stream, the current video frame group of the original live stream is also sent.
[0047] Step 208: Stop sending the original live stream, and start sending the target live stream to the client from the next key frame of the target live stream.
[0048] In this embodiment, when the alignment is successful, the execution entity may stop sending the original live stream and start sending the target live stream to the client from the next key frame of the target live stream.
[0049] It should be noted that, since the key frame is the beginning of the video frame group of the live stream, it is necessary to start switching from the key frame of the video frame group.
[0050] Step 209: Determine whether the timestamp of the latest video frame of the target live stream is greater than the timestamp of the latest video frame of the original live stream.
[0051] In this embodiment, if the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream is greater than a second preset time difference threshold, the execution entity may determine whether the timestamp of the latest video frame of the target live stream is greater than the timestamp of the latest video frame of the original live stream. If the timestamp of the latest video frame of the target live stream is greater than the timestamp of the latest video frame of the original live stream, it indicates that the speed of the target live stream is greater than the speed of the original live stream, and step 210 is executed. If the timestamp of the latest video frame of the target live stream is not greater than the timestamp of the latest video frame of the original live stream, it indicates that the speed of the target live stream is not greater than the speed of the original live stream, and step 213 is executed.
[0052] Step 210: Determine whether the timestamp of the latest key frame of the target live stream is close to the timestamp of the latest key frame of the original live stream.
[0053] In this embodiment, if the timestamp of the latest video frame of the target live stream is greater than the timestamp of the latest video frame of the original live stream, the execution entity may determine whether the timestamp of the latest key frame of the target live stream is similar to the timestamp of the latest key frame of the original live stream. If the timestamp of the latest key frame of the target live stream is similar to the timestamp of the latest key frame of the original live stream, it indicates that the target live stream is faster than the original live stream by no more than one video frame group, and steps 207-208 are executed. If the timestamp of the latest key frame of the target live stream is not similar to the timestamp of the latest key frame of the original live stream, it indicates that the target live stream is faster than the original live stream by more than one video frame group, and step 211 is executed.
[0054] If the target live stream is faster than the original live stream, but the difference is less than one video frame group, the next key frame returned to the source is the target live stream's key frame. The target live stream is cached starting from this key frame. When the next key frame of the original live stream is returned to the source, it is sent directly from this key frame.
[0055] Step 211: Continue sending the original live stream until the next key frame of the original live stream is returned to the source, and determine that the alignment is successful.
[0056] In this embodiment, if the timestamp of the latest key frame of the target live stream is not close to the timestamp of the latest key frame of the original live stream, the above-mentioned execution entity can continue to send the original live stream until it returns to the next key frame of the original live stream, determines that the alignment is successful, and executes step 212.
[0057] Step 212: Send the target live stream to the client starting from the latest key frame of the target live stream.
[0058] In this embodiment, when the alignment is successful, the execution entity may start sending the target live stream to the client from the latest key frame of the target live stream.
[0059] If the target live stream is faster than the original live stream, but the difference is longer than one video frame group, the target live stream will be cached starting from the latest key frame. After the current video frame group of the original live stream is sent, the target live stream will be sent starting from the latest key frame.
[0060] Step 213: reduce the sending speed of the original live stream and continue to send the original live stream until the timestamp of the latest video frame of the target live stream is greater than the timestamp of the latest video frame of the original live stream.
[0061] In this embodiment, if the timestamp of the latest video frame of the target live stream is not greater than the timestamp of the latest video frame of the original live stream, the above-mentioned execution entity can reduce the sending speed of the original live stream and continue to send the original live stream until the timestamp of the latest video frame of the target live stream is greater than the timestamp of the latest video frame of the original live stream, and execute steps 206-208.
[0062] If the target live stream is slower than the original live stream, the original live stream needs to be sent at a reduced speed and wait for the target live stream to catch up.
[0063] The disclosed embodiment provides a live streaming switching method, which performs timestamp alignment for various situations when the original live streaming stream is basically synchronized with the target live streaming stream, thereby improving the scope of application of seamless switching.
[0064] Figure 3 A flowchart is shown of an application scenario in which the live streaming switching method according to an embodiment of the present disclosure can be implemented.
[0065] Step 301, INIT.
[0066] In live streaming scenarios, use INIT to initialize the state. Upon receiving the first data packet, the corresponding RID (Record ID) is recorded. The INIT method is a special constructor that is automatically called when a new instance of a class is created. The INIT method's primary function is to initialize the object's state, ensuring that each object is correctly configured before use. The RID uniquely identifies the original live stream.
[0067] Step 302, NORMAL_SENDING.
[0068] NORMAL_SENDING indicates that the original live stream is playing normally, indicating that no time switching has occurred. The client initiates a time switching request when it receives the first data packet with a different RID from the original live stream.
[0069] Step 303, BURST_WAITING.
[0070] BURST_WAITING: When a client requests a switch, the target live stream is initially returned to its source, maintaining the current state for a period of time. This allows the target live stream to be pulled from the cached target stream and then to be pulled from the live target stream. This allows the target live stream to be compared to the original live stream, and the difference in speed. During this phase, the original live stream is sent normally, and the target live stream is cached normally.
[0071] Step 304: Check whether the two live streams differ greatly or have abnormal status values. If so, proceed to step 305; if not, proceed to step 307.
[0072] Step 305: Notify the listener to abandon the stream switching, delete the target live stream, and remove the relevant state and attributes of the target live stream.
[0073] If the timestamps of the latest video frames of the two live streams differ significantly, indicating that some abnormality has occurred, the switching behavior will be stopped, the return to the source target live stream will be stopped, and the original live stream will continue to be sent.
[0074] Step 306: Notify the listener that the switching process is complete, and continue to execute step 302.
[0075] Step 307: Check whether the absolute value of the timestamp difference between the latest received video frames of the two live streams is less than a threshold. If yes, proceed to step 308; if not, proceed to step 317.
[0076] If the timestamp difference between the latest video frames of the two live streams is very small, it means that the two live streams are basically synchronized.
[0077] Step 308, WAIT_FOR_LAST_SEND_KEYFRAME_EQUAL.
[0078] WAIT_FOR_LAST_SEND_KEYFRAME_EQUAL waits for the timestamp of the latest key frame received by the target live stream to be the same as the timestamp of the latest key frame received by the original live stream. During this period, the original live stream is sent at 1.0 times the speed.
[0079] Step 309: Check whether the timestamps of the latest key frames received by the two live streams are the same. If yes, go to step 310; if not, go to step 311.
[0080] Step 310 , NEXT_KEY_MUST_SWICTH, and execute step 312 .
[0081] NEXT_KEY_MUST_SWICTH means that when the next key frame of the target live stream arrives and the current video frame group of the original live stream is sent, it starts sending from the next key frame of the target live stream.
[0082] Step 311: Check if the timeout has occurred. If so, go to step 305; if not, go to step 308.
[0083] Step 312: Check whether the target live stream has received the next key frame after entering the NEXT_KEY_MUST_SWICTH state, and whether the original live stream has also seen the next key frame after entering the NEXT_KEY_MUST_SWICTH state. If so, send the entire current video frame group of the original live stream and execute step 313; if not, execute step 315.
[0084] Step 313 , ACCELRATE_NEW_SYNCING, and execute step 314 .
[0085] ACCELRATE_NEW_SYNCING is when sending the target live stream data. If there is a certain amount of buffer, it will be sent at an appropriate speed. During this period, the target live stream is sent at 1.3 times the speed.
[0086] Step 314: Check whether the target live stream buffer is exhausted. If so, go to step 306; if not, go to step 313.
[0087] Step 315: Check if the timeout has occurred. If so, go to step 316; if not, go to step 310.
[0088] Step 316 , notifying the listener to switch the target live stream RID, deleting the original live stream, updating the relevant attributes related to the stream name, and executing step 306 .
[0089] Step 317: Check whether the timestamp of the latest received video frame of the original live stream is greater than the timestamp of the latest received video frame of the target live stream. If not, it means that the target live stream is faster than the original live stream, and execute step 318; if so, it means that the original live stream is faster than the target live stream, and execute step 322.
[0090] Step 318: Check whether the timestamps of the latest key frames received by the two live streams are close. If so, the target live stream is faster than the original live stream by no more than one video frame group, and then proceed to step 310. If not, the target live stream is faster than the original live stream by more than one video frame group, and then proceed to step 319.
[0091] Step 319, CACHE_NEW_SYNCING.
[0092] CACHE_NEW_SYNCING is used to cache the target live stream data.
[0093] Step 320: Check whether a new key frame of the original live stream is received. If so, go to step 313; if not, go to step 321.
[0094] Step 321: Check if the timeout has occurred. If so, go to step 316; if not, go to step 319.
[0095] Step 322: Estimate whether the time required to send the original live stream slowly to complete the switching condition will exceed the limit. If so, execute step 305; if not, execute step 323.
[0096] Step 323, SLOW_OLD_SYNCING.
[0097] SLOW_OLD_SYNCING is the slow transmission of the original live stream data. During this period, the original live stream is sent at 0.75 times the speed.
[0098] Step 324: Check whether the timestamp of the latest video frame received by the target live stream is greater than the timestamp of the latest video frame received by the original live stream. If so, proceed to step 308; if not, proceed to step 325.
[0099] Step 325: Check if the timeout has occurred or if an abnormality has been detected in the target live stream return. If so, proceed to step 305; if not, proceed to step 323.
[0100] Figure 4 The effect diagram of the live stream switching when the target live stream is slower than the original live stream is shown. Figure 4 As shown in the figure, the horizontal axis of the coordinate system is the live stream reception timestamp, and the vertical axis is the live stream playback timestamp. The original live stream is first slowed down until it synchronizes with the target live stream. Then, the original live stream is sent back to normal speed until the target live stream is directly connected.
[0101] Figure 5 The effect diagram of the live stream switching when the target live stream is faster than the original live stream is shown. Figure 5 As shown in the figure, the horizontal axis of the coordinate system represents the live stream reception timestamp, and the vertical axis represents the live stream playback timestamp. After the original live stream is sent, the target live stream is sent starting from the connection point. Because the target live stream is fast, some buffer is already present from the connection point. After this buffer is consumed during accelerated transmission for a period of time, the target live stream resumes normal transmission.
[0102] Further references Figure 6 As an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of a live streaming switching device. Figure 1Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.
[0103] like Figure 6 As shown, the live stream switching device 600 of this embodiment may include: a receiving module 601, a back-to-source module 602, an alignment module 603, and a sending module 604. The receiving module 601 is configured to receive a time switching request sent by a client, wherein the time switching request includes a target definition; the back-to-source module 602 is configured to back-source the original live stream and the target live stream corresponding to the target definition, and send the original live stream to the client; the alignment module 603 is configured to align the timestamps of the original live stream with the target live stream; and the sending module 604 is configured to stop sending the original live stream in response to determining that the alignment is successful, and send the target live stream to the client.
[0104] In this embodiment, the specific processing of the receiving module 601, the return source module 602, the alignment module 603 and the sending module 604 and the technical effects thereof can be referred to in the respective embodiments. Figure 1 The relevant descriptions of steps 101-104 in the corresponding embodiment are not repeated here.
[0105] In some optional implementations of this embodiment, the back-to-source module 602 is further configured to: back-source the original live stream and the target live stream until a preset duration threshold is exceeded, and / or until the ratio of the playback timestamp interval to the reception timestamp interval of two consecutive frames of the target live stream is less than a preset ratio threshold.
[0106] In some optional implementations of this embodiment, the stop module is configured to determine that the alignment has failed and stop returning to the source target live stream in response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being not less than a first preset time difference threshold.
[0107] In some optional implementations of this embodiment, the alignment module 603 is further configured to: in response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being no greater than a second preset time difference threshold, and the timestamp of the latest key frame of the target live stream being the same as the timestamp of the latest key frame of the original live stream, continue to send the original live stream until it is returned to the next key frame of the target live stream, and the current video frame group of the original live stream is sent, and determine that the alignment is successful; the sending module 604 is further configured to: send the target live stream to the client starting from the next key frame of the target live stream.
[0108] In some optional implementations of this embodiment, the alignment module 603 is further configured to: in response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being less than a first preset time difference threshold but greater than a second preset time difference threshold, the timestamp of the latest video frame of the target live stream being greater than the timestamp of the latest video frame of the original live stream, and the timestamp of the latest key frame of the target live stream being close to the timestamp of the latest key frame of the original live stream, continue to send the original live stream until it is returned to the next key frame of the target live stream, and the current video frame group of the original live stream is sent, and determine that the alignment is successful; and the sending module 604 is further configured to: send the target live stream to the client starting from the next key frame of the target live stream.
[0109] In some optional implementations of this embodiment, the alignment module 603 is further configured to: in response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being less than a first preset time difference threshold but greater than a second preset time difference threshold, the timestamp of the latest video frame of the target live stream being greater than the timestamp of the latest video frame of the original live stream, and the timestamp of the latest key frame of the target live stream being not close to the timestamp of the latest key frame of the original live stream, continue to send the original live stream until returning to the next key frame of the original live stream, and determine that the alignment is successful; and the sending module 604 is further configured to: send the target live stream to the client starting from the latest key frame of the target live stream.
[0110] In some optional implementations of this embodiment, the alignment module 603 is further configured to: in response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being less than a first preset time difference threshold but greater than a second preset time difference threshold, and the timestamp of the latest video frame of the target live stream being not greater than the timestamp of the latest video frame of the original live stream, reduce the sending speed of the original live stream, and continue to send the original live stream until the timestamp of the latest video frame of the target live stream is greater than the timestamp of the latest video frame of the original live stream, and the timestamp of the latest key frame of the target live stream is the same as the timestamp of the latest key frame of the original live stream, continue to send the original live stream until it returns to the next key frame of the target live stream, and the current video frame group of the original live stream is sent, and determine that the alignment is successful; and the sending module 604 is further configured to: send the target live stream to the client starting from the next key frame of the target live stream.
[0111] In the technical solutions disclosed herein, the acquisition, storage, and application of user personal information involved comply with the provisions of relevant laws and regulations and do not violate public order and good morals.
[0112] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium, and a computer program product.
[0113] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein.
[0114] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. RAM 703 may also store various programs and data required for the operation of device 700. Computing unit 701, ROM 702, and RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to bus 704.
[0115] Various components in device 700 are connected to I / O interface 705, including an input unit 706, such as a keyboard, mouse, etc.; an output unit 707, such as various types of displays, speakers, etc.; a storage unit 708, such as a magnetic disk, optical disk, etc.; and a communication unit 709, such as a network card, modem, wireless communication transceiver, etc. The communication unit 709 allows device 700 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.
[0116] The computing unit 701 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as the live stream switching method. For example, in some embodiments, the live stream switching method may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed onto the device 700 via the ROM 702 and / or the communication unit 709. When the computer program is loaded into the RAM 703 and executed by the computing unit 701, one or more steps of the live stream switching method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform the live stream switching method via any other suitable means (e.g., via firmware).
[0117] Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
[0118] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.
[0119] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of machine-readable storage media may include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fibers, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0120] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).
[0121] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.
[0122] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server in a distributed system, or a server integrated with a blockchain.
[0123] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions provided by this disclosure can be achieved. This is not limited herein.
[0124] The above specific embodiments do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure shall be included within the scope of protection of this disclosure.
Claims
1. A method for switching a live stream, comprising: receiving a time switching request sent by a client, wherein the time switching request includes a target definition; Returning the original live stream and the target live stream corresponding to the target definition, and sending the original live stream to the client; Aligning the timestamps of the original live stream and the target live stream; In response to determining that the alignment is successful, stopping sending the original live stream and sending the target live stream to the client.
2. The method according to claim 1, wherein Before aligning the timestamps of the original live stream and the target live stream, the method further includes: The original live stream and the target live stream are returned to the source until a preset duration threshold is exceeded, and / or until the ratio of the playback timestamp interval to the reception timestamp interval of two consecutive frames of the target live stream is less than a preset ratio threshold.
3. The method according to claim 1 or 2, wherein: The method further comprises: In response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being not less than a first preset time difference threshold, it is determined that the alignment has failed, and returning to the target live stream is stopped.
4. The method according to claim 3, wherein: The aligning the timestamps of the original live stream and the target live stream includes: In response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being no greater than a second preset time difference threshold, and the timestamp of the latest key frame of the target live stream being the same as the timestamp of the latest key frame of the original live stream, the original live stream continues to be sent until the next key frame of the target live stream is returned to the source, and the current video frame group of the original live stream is completely sent, determining that the alignment is successful; and The sending the target live stream to the client includes: The target live stream is sent to the client starting from the next key frame of the target live stream.
5. The method according to claim 4, wherein The aligning the timestamps of the original live stream and the target live stream includes: In response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being less than a first preset time difference threshold but greater than a second preset time difference threshold, the timestamp of the latest video frame of the target live stream being greater than the timestamp of the latest video frame of the original live stream, and the timestamp of the latest key frame of the target live stream being close to the timestamp of the latest key frame of the original live stream, the original live stream continues to be sent until the next key frame of the target live stream is returned to the source, and the current video frame group of the original live stream is completely sent, determining that the alignment is successful; and The sending the target live stream to the client includes: The target live stream is sent to the client starting from the next key frame of the target live stream.
6. The method according to claim 5, wherein: The aligning the timestamps of the original live stream and the target live stream includes: In response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being less than a first preset time difference threshold but greater than a second preset time difference threshold, the timestamp of the latest video frame of the target live stream being greater than the timestamp of the latest video frame of the original live stream, and the timestamp of the latest key frame of the target live stream being not close to the timestamp of the latest key frame of the original live stream, continuing to send the original live stream until returning to the next key frame of the original live stream, and determining that the alignment is successful; and The sending the target live stream to the client includes: The target live stream is sent to the client starting from the latest key frame of the target live stream.
7. The method according to claim 6, wherein: The aligning the timestamps of the original live stream and the target live stream includes: In response to the absolute value of the difference between the timestamps of the latest video frame of the original live stream and the latest video frame of the target live stream being less than a first preset time difference threshold but greater than a second preset time difference threshold, and the timestamp of the latest video frame of the target live stream being no greater than the timestamp of the latest video frame of the original live stream, reducing the sending speed of the original live stream, and continuing to send the original live stream until the timestamp of the latest video frame of the target live stream is greater than the timestamp of the latest video frame of the original live stream, and the timestamp of the latest key frame of the target live stream is the same as the timestamp of the latest key frame of the original live stream, continuing to send the original live stream until the next key frame of the target live stream is returned to the source, and the current video frame group of the original live stream is completely sent, and determining that the alignment is successful; and The sending the target live stream to the client includes: The target live stream is sent to the client starting from the next key frame of the target live stream.
8. A live streaming switching device, comprising: a receiving module configured to receive a slot switching request sent by a client, wherein the slot switching request includes a target definition; a return-to-source module configured to return to the source an original live stream and a target live stream corresponding to the target definition, and send the original live stream to the client; an alignment module, configured to perform timestamp alignment between the original live stream and the target live stream; The sending module is configured to stop sending the original live stream and send the target live stream to the client in response to determining that the alignment is successful.
9. An electronic device comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.
10. A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are configured to cause the computer to execute the method according to any one of claims 1 to 7.
11. A computer program product comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 7.