WO2020029935A1

WO2020029935A1 - Video live-broadcast processing method, apparatus and terminal

Info

Publication number: WO2020029935A1
Application number: PCT/CN2019/099343
Authority: WO
Inventors: 李剑峰
Original assignee: 南京中兴软件有限责任公司
Priority date: 2018-08-06
Filing date: 2019-08-06
Publication date: 2020-02-13
Also published as: CN110809168A

Abstract

Disclosed is a video live-broadcast processing method. The method comprises: live-broadcasting a first video; caching video data of a second video during the live-broadcast of the first video; and when a switching instruction is detected, stopping the live-broadcast of the first video, and live-broadcasting the second video by using the cached video data. Further disclosed are a video live-broadcast processing apparatus, terminal and system.

Description

Video live processing method, device and terminal

This application claims priority from Chinese patent application CN201810887571.X entitled "Video Live Stream Processing Method, Device, Terminal, and Storage Medium" filed on August 6, 2018, the entire contents of which are incorporated herein by reference.

Technical field

The present invention relates to the field of multimedia technology, and in particular, to a method, device and terminal for processing live video.

Background technique

Video live broadcast is becoming more and more popular among video users, and it meets people's needs for social, adventure, and other forms of interactive content. With the development of Internet technology, users who currently use video services tend to have more surplus on package traffic and more monthly monthly traffic; and, with the introduction of higher compression encoding algorithms, traffic is no longer a service experience for video services Focus. The focus of today's video service experience is mainly reflected in three parts: resolution, initial buffer time and stall rate. Among them, the shorter the initial buffer time and the lower the stall rate, the better the user experience. However, the above problems have not been solved at present, which leads to a poor video service experience.

Summary of the invention

In view of this, the main object of the present invention is to provide a method, device and terminal for processing live video, which can at least partially solve the problems of long initial cache time and high stall rate.

The technical solution of the present invention is implemented as follows:

A live video processing method, the method includes:

Broadcast the first video;

Buffering video data of the second video when the first video is live broadcasted;

When a switching instruction is detected, the live broadcast of the first video is stopped, and the second video is broadcast live using the cached video data.

A video live processing device, the device includes:

A video live broadcast module for live broadcast of the first video; and also for stopping the live broadcast of the first video when a switching instruction is detected, and live broadcast of the second video by using the cached video data;

The buffering module is configured to buffer video data of the second video when the first video is broadcast live.

An embodiment of the present invention further provides a terminal, where the terminal includes a processor and a memory for storing a computer program capable of running on the processor; wherein, when the processor is used to run a computer program, any one of the present invention is implemented The live video processing method provided in the embodiment.

An embodiment of the present invention further provides a live video processing system, where the system includes: a terminal and a media server;

The terminal is configured to implement a live video processing method provided by any embodiment of the present invention;

The media server is configured to send video data of a first video and / or video data of a second video to the terminal.

The method, device and terminal for processing live video provided by the embodiments of the present invention, by buffering video data of the second video during live broadcast of the first video, it is beneficial to quickly play the second video when switching to the second video Video content. By stopping the live broadcast of the first video when the switching execution is detected, and using the cached video data of the second video to broadcast the second video, the live broadcast device can pass as soon as it switches to the second video Play the pre-buffered video data of the second video. Compared with the lack of time to obtain the video data, such as the black screen caused by the direct switching without pre-buffering, it takes almost 1s to switch to the abnormal state of playback. Seeing that the picture has a shorter time, the display screen can be switched to the display picture of the second video in a shorter time, and the switching rate of the live video is faster and the switching efficiency is higher. In addition, the method provided by the embodiment of the present invention also reduces the time required for the first appearance of a non-first live video, reduces the stall rate of the entire live broadcast process, and brings a better video live experience to users.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic flowchart of buffering video data according to an embodiment of the present invention;

FIG. 2 is a schematic flow chart of Embodiments 1, 2, 3, 4, and 5 of a method for processing a live video broadcast according to the present invention; FIG.

3 is a schematic flowchart of a sixth embodiment of a live video processing method according to the present invention;

4 is a schematic flowchart of a seventh embodiment of a live video processing method according to the present invention;

5 is a schematic flowchart of Embodiment 8 of a live video processing method according to the present invention;

6 is a schematic flowchart of a ninth embodiment of a live video processing method according to the present invention;

7 is a schematic flowchart of a tenth embodiment of a live video processing method according to the present invention;

8 is a schematic flowchart of Embodiment 11 of a live video processing method according to the present invention;

9 is a schematic structural diagram of a live video processing apparatus according to an embodiment of the present invention;

FIG. 10 is a schematic diagram of a hardware structure of a live video processing apparatus according to an embodiment of the present invention; FIG.

FIG. 11 is a schematic structural diagram of a live video processing system according to an embodiment of the present invention.

detailed description

The live video processing method provided by the example of the present invention is mainly applied to the field of live video. The current live video system includes a media server and a terminal. The terminal is equipped with a live video software APP. For example, it can be Yingke live software, peppercorn. Live software, Huya live software, Douyu live software, live bar software, Fengyun live software, etc .; the terminal may be a mobile phone, iPad, PC, or other electronic devices. The implementation, functional characteristics, and advantages of the present invention will be further described with reference to the embodiments and the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

As shown in FIG. 1, a method for pre-caching video data is provided. A streaming device pushes a video stream to a media server, and the media server forwards the video stream to other media servers or directly to the terminal APP, which is decoded by the terminal APP. Output. For the live broadcast platform, there are many live streaming devices that push the live broadcast videos of each anchor to the media server, and terminal APP users select favorite anchors and content to watch for a long time according to personal preferences. Over time, users may continue to change video content in search of more preferred content. During the switching process, the user often slides the interactive screen to change the next video.

In some embodiments, live video is the real-time acquisition and encoding of live signals (such as cameras) and television signals (such as TV programs and videotapes) into standard streaming data for management, classification, etc. , For end users to watch live programs or TV programs in real time. The specific implementation process is: when the user sends a live broadcast request, the server will tell the user the broadcast address of the live broadcast channel according to the live broadcast information, and the user joins the corresponding multicast group according to the address to receive the live broadcast channel. Stream.

Video live streaming evolved on the basis of video on demand.

Video on demand broadcasts programs according to the requirements of the end user. The specific implementation process is: When the end user sends an on demand request, the streaming media server system will retrieve the program information stored in the source library according to the on demand information. Audio stream and video stream files are transmitted to user terminals for playback through the network.

In some embodiments, because the live video is collected in real time for playback, for the download mode of live video, it may only need to cache a part of the video content to be played, the download time of the video content is short, and the retention time is short; and Because video on demand must be downloaded to a local cache before it can be played, it often requires a large amount of video content to be played, which often requires a large amount of storage resources.

In some embodiments, the video data in the live video broadcast is not collected in advance, but is played while collecting; and video on demand generally collects the video in advance and stores it in a video server or a video database. When the video is on demand At this time, the video data of the video has been completely collected, and the playback terminal can directly obtain the video data of the entire video.

Example one

As shown in FIG. 2, an embodiment of the present invention provides a live video processing method. The method includes the following steps.

Step 101: broadcast the first video;

Optionally, the interactive display screen of the touch terminal enters the live APP page, and clicks to enter the first video to live broadcast the first video.

Here, when the first video is being broadcast live, the terminal sends a request to pull the video data of the first video to the media server; after the terminal receives the video data of the first video, the terminal APP decodes the video data of the first video, so that the first The video content of the video is presented on a display interactive screen.

Here, the video data of the first video is specifically a video stream.

Step 103: when the first video is broadcast live, buffer the video data of the second video;

Optionally, when the terminal broadcasts the first video, the terminal further sends a request for pulling the video data of the second video to the media server, so that the media server sends the video data of the second video to the terminal based on the request; The terminal may buffer the video data of the second video.

If the second video is transmitted based on a streaming media protocol (for example, real-time streaming media protocol (RTP), real-time transmission control protocol (RTCP)), the video data of the second video corresponds to a video stream containing image data and An audio stream containing audio data.

As such, the buffering of the video data of the second video may include buffering the video stream data, or buffering the video stream data and the audio stream data. The video data may include: image data and audio data; usually, the data amount of the image data of a video frame is much larger than the data amount of the audio data. In step 103, the number of videos buffering the second video includes: buffering at least the image data of the second video. Because the data volume of the audio data is small, when switching to live broadcast of the second video, the terminal can also promptly download from the media server. Request audio data for live broadcast.

In other embodiments, the buffering the video data of the second video in step 103 may include: synchronizing the image data and the audio data of the buffered video data. In this way, when switching to live broadcast of the second video, live broadcast can be performed directly based on the cached image data and audio data.

In step 105, when a switching instruction is detected, the live broadcast of the first video is stopped, and the cached video data is used to broadcast the second video.

Optionally, when the terminal detects the execution of the switching, the terminal stops the live broadcast of the first video; switches to live broadcast the second video; and in the embodiment of the present invention, the live broadcast second video directly utilizes the cached Video data of the second video starts the live broadcast of the second video; there is no need to temporarily obtain the video information of the second video, and start buffering the video data of the second video based on the video information, after the video data of the second video is buffered The live broadcast has only begun, which obviously improves the efficiency of live broadcast switching and reduces the anomalies such as freezes and black screens during live broadcast switching.

Here, it should be noted that the first video and the second video are not only characterized by two videos, but may be characterized by multiple live videos that are constantly changing live videos; when a switching instruction is detected, the Switching a live video to another live video does not only signify the switching between two live videos, but also the switching between multiple live videos that a user may watch during the entire live switching process.

For example, when watching the live video of host A, the next live broadcast of host B is cached. After a period of time, when the user watches the live video of host B, the next live broadcast of host C is cached.

For another example, it may be that the user continuously switches from A-caster-B-caster-C-caster-D-caster-. When the switch instruction is detected, stop the live broadcast of the A host's live video, and use the cached live data of the B host's live video for the live broadcast, and cache the video data of the C host's live video; when the switch instruction is detected, stop The live broadcast of the B host's live video, and the cached live data of the C host's live video is used for the live broadcast, and the D data of the live broadcast of the D host is cached; when the switching execution order is detected, the video of the live broadcast of the D host is stopped Data ... and so on, until the live video of interest is selected for a long live video broadcast.

It should be noted that, during the live broadcast of the video in this embodiment, when the user is looking for a favorite channel or program, the user buffers the video data of the second video when the first video is live, so that when a switch instruction is detected, the switch When the second video is live broadcasted, the cached video data of the second video can be used for live broadcast, thus avoiding the “black screen” state or no program state caused by accessing the live video from a random point in time; and, It can be realized that when the user continuously switches the process of the live video, the user can watch the cut-in live video in a very short time, reducing the waiting time of the first appearance of the live video, and achieving a better effect than the second opening; and During the entire switching process, the video data of the next video will be cached when the previous video is played, which also overcomes the feeling of stutter caused by the continuous switching to the user during the live broadcast.

Example two

Based on the first embodiment, as shown in FIG. 2, the above step 105 further includes:

When the switching instruction is detected, controlling the live video of the first video to slide out of the display area from the first direction;

Controlling the live broadcast picture of the second video to slide into the display area from a second direction of the display area;

The second direction is opposite to or the same as the first direction.

Here, the detecting the switching instruction may be: detecting the generated switching instruction according to a user operation.

Here, it is possible to slide the interactive display screen with a finger or other touch object to control the live broadcast screen of the first video to slide out of the display area from the first direction, and / or to control the live broadcast screen of the second video from The second direction of the display area is drawn into the display area; wherein the first direction and the second direction may be a direction parallel to the horizontal axis of the display area or a direction parallel to the vertical axis of the display area; It can be in any direction, as long as it does not affect the control to slide the live picture of the first video from the display area, and does not affect the control to slide the live picture of the second video from the display area; The first direction and the second direction may be opposite directions or the same.

The horizontal axis direction may be a direction in which a long side of the display screen is located; and the vertical axis direction may be a direction in which a short side of the display screen is located.

Here, when the switching instruction is detected, according to the switching instruction, it may also be executed to exit the homepage of the first video live broadcast to the live broadcast APP, scroll the interactive display screen to switch from the first video to the second video, and touch to enter The second video broadcasts the operation of the second video.

In some embodiments, the switching instruction may be a sliding operation instruction corresponding to a sliding operation, or may be a voice instruction collected through voice, or a control instruction received from another electronic device, for example, received from a mouse or a remote control device. Switch instruction.

Further, the step 105 further includes:

Detect the sliding operation acting on the display interactive screen;

If the sliding operation is detected, generating the switching instruction;

The sliding direction of the sliding operation is the first direction.

Optionally, the terminal detects a sliding operation performed by the user on the display interactive screen, and the direction of the sliding operation may be the first direction or a direction opposite to the first direction; if the sliding operation is detected, then Generate a switch instruction.

If the direction of the sliding operation is the same as the first direction, so that the user's operating inertia is the same, and the user experience can be improved.

Example three

Based on the first embodiment, as shown in FIG. 2, the above step 103 further includes:

When the first video is broadcast live, at least one group of pictures GOP that is live broadcast at the current moment of the second video is buffered.

The current time can be understood as: the current time point. Play the current moment at any one of the first videos.

Here, buffering the video data may include: buffering the data content of the video stream. The video stream includes a collection of video frames. Taking MPEG1, MPEG2, MPEG4, and H.264 as examples, it is a video stream including a group of pictures (GOP) set.

In some embodiments, when the first video is broadcast live, a cache space is allocated for the second video in advance, and the cache space can accommodate at least one GOP of the second video; in some embodiments, the capacity of the cache space can be at least Cache two or more GOPs.

The buffering of at least one GOP of the second video live at the current moment may write the GOP of the second video currently downloaded from the network side into the cache space, and if the cache space is full, directly replace the farther from the current moment Cached GOP for historical moments. For example, a cache queue is established in the cache space, and the cache queue may be a first-in-first-out (FIFO) queue. In this way, if a GOP is written to the end of the queue, a first is popped up at the head of the FIFO. GOP. In this way, the second video is cached, on the one hand, it does not occupy a large amount of cache space, which saves the cache capacity of the playback terminal; on the other hand, it can timely discard the cached GOP at the historical moment, reducing switching to live broadcast due to switching errors In the second video, the GOP selected for entering the live broadcast is incorrect (for example, the GOP at the historical moment is selected for live broadcast at the current moment), and the live broadcast skip caused by the GOP from the historical moment to the GOP at the next moment is reduced. The continuous phenomenon, so the special setting of the cache space also improves the live broadcast effect of the second video.

Please refer to FIG. 1 again. When the user opens the video content of the anchor A for viewing, the user may pre-cache a GOP or a set of more than one GOP of the next adjacent live video B anchor and store it in the terminal's local cache. . If the user switches the video content at this time, the terminal APP can directly read the GOP or GOP set in the cache for playback, and continue to download the rest of the video frames of B anchor. At the same time, pre-cache and download the live video C anchor one or more GOPs stored in In the local cache, waiting for the user to switch.

Here, the GOP includes: an I frame, a P frame, and a B frame;

I frame is a key frame, which is usually the first frame of each GOP. It can retain a complete picture. When decoding, only the data of this frame can be used to complete the decoding.

The P frame is a forward prediction frame. The P frame can retain the difference between this frame and the previous frame. Therefore, when decoding, the P frame depends on the previous P frame / I frame;

The B frame is a bidirectional prediction frame. The B frame can retain the difference between this frame and the previous and subsequent frames. Therefore, when decoding, the B frame depends on the previous P frame / I frame and the next P frame; the B frame is not a reference frame and will not Causes the proliferation of decoding errors.

In some embodiments, for video on demand, the video files all start from 0 seconds, and the first frame from 0 seconds is the key frame I frame, so when the user clicks into the on-demand video, it does not exist. The "black screen" caused by entering P-frames or B-frames is seen as video content with pictures. For live video, it is received at a random point in time to play the video stream, and the frame at this point in time may be an I frame, or a P frame or a B frame. When a P frame or a B frame is connected at this time point, this will cause the display interactive screen to appear in a "black screen" state. Therefore, it is necessary to wait until the next key frame I frame arrives before the video content with pictures can start to appear.

It should be noted that in this embodiment, when the first video is broadcast live, at least one frame group GOP of the second video being broadcasted at the current moment is cached. When the live broadcast of the second video is switched, P frames can be avoided directly from the time point. Or the possibility that the B frame enters the live video; when the second video of the live broadcast is entered, the pre-cached GOP can be played, so that the live broadcast can be accessed from the time of the I frame, so that the display interactive screen does not appear " "Blank screen" status or no program status, thereby avoiding the "black screen" or stutter problems during the switching process.

In this way, users can avoid the problem that the time required for the first time to play the picture appears for the first time when the live video is continuously switched; and, if the total interval time of the buffered GOP exceeds the time period between the key frames before and after the key frame, it can be achieved Fully seamless playback of live video switching process.

Embodiment 4

Based on the foregoing third embodiment, as shown in FIG. 2, the step 103 further includes: buffering at least one first-type GOP of the second video at the current moment when the first video is broadcasted live, wherein the first One type of GOP includes: I-frame, B-frame, and P-frame.

Here, when the network to which the terminal is connected is WIFI or a wired network, or when the user is configured to cache the first type of GOP set, or in other cases where there is no restriction on the network traffic, the terminal caches the live broadcast of the second video at the current moment. At least one first-class GOP.

In this way, in this embodiment, a clear picture can be viewed when the sense of stutter caused by the user's continuous switching is reduced.

Example 5

Based on the foregoing third embodiment, as shown in FIG. 2, the step 103 further includes: buffering at least one second-type GOP or at least one third-type GOP when the first video is broadcast live;

The second type of GOP lacks B frames compared to the first type of GOPs; the third type of GOP lacks B frames and P frames compared to the first type of GOPs.

Here, when the buffer drops B frames, or G frames of P frames and B frames, when the terminal requests the GOP of the cached second video, it can carry an indication that the buffered video stream type is an active frame loss mode. Among them, optional drop Frame types include: types of dropping B frames, or dropping P and B frames.

In some embodiments, in a video coding standard based on the GOP structure, each GOP must start with an I frame, followed by a series of P frames and B frames. Because the I frame is decoded independently within the frame, the entire picture can be decoded without reference to other frames when decoding; while the P frame is forward predictive coding, it needs to refer to the I frame or P frame before it; The B frame is bidirectional predictive decoding. When decoding, it needs to refer to the I frame or P frame located on the front and back sides of the frame. When a frame is decided to be dropped, all other frames in the GOP that depend directly or indirectly on the frame must be discarded. Otherwise, it will cause decoder error or failure.

According to the above frame dropping principles and inter-frame dependencies, each B frame can be dropped randomly; when a P frame is dropped, all other P frames and B frames in the current GOP that are located after the P frame in decoding order should be dropped; When an I frame is dropped, all frames in the current GOP should also be dropped.

Therefore, if B frames are dropped and only I and P frames are retained, the sharpness of the picture is affected to some extent, but the effect on the senses is not significant; if P frames are dropped, B frames cannot be decoded, so the P frames are dropped. At the same time, B frames will also be dropped. At this time, a GOP has only I frames. If a GOP interval is 2S, you can see real-time dynamic pictures every 2S.

In this way, if the B frame is dropped, when the switching to the live broadcast second video, the picture clarity at the start of playback will be affected to some extent, but the integrity of the picture is not affected; at the same time, the traffic can be partially resolved. problem. If the P and B frames are discarded, in this case, although the sharpness of the picture is also affected, you can still watch a real-time dynamic picture with a single GOP time interval. If the time of a single GOP is relatively small, Less than the reflection time of the human eye, you can still see continuous video playback.

It should be noted that, when the first video is live broadcasted, if the video data of the cached second video is an incomplete GOP, for example, the GOP of B frame or P frame and B frame is discarded, and the second video is switched to live broadcast , It does not affect its rebuffering of other GOPs. Therefore, when the second video is broadcast live, even if the incomplete GOP video stream buffered in the above step 103 does not affect the subsequent cache of the complete GOP video stream of the second video, the second video is broadcast live. The video content of the video. In addition, since the complete GOP set can be re-buffered in a relatively short time after switching to the second video, in terms of user experience, even if B frames or P frames and B frames are dropped for a short period of time, GOP video content does not affect the intuitive feeling of the entire video viewed by the user. In this way, traffic can be greatly saved, and for some electronic device users with limited traffic, the user's experience of watching live video can be greatly improved.

Example Six

Based on the third embodiment, as shown in FIG. 3, before step 105, the method further includes step 104: detecting whether the duration of the live broadcast of the first video exceeds a set threshold;

If the duration of the live broadcast of the first video exceeds the threshold, the buffering of video data of the second video is stopped.

Optionally, to detect whether the duration of the live broadcast of the first video exceeds a set threshold, a timer may be set to start at the start time of the live broadcast of the first video to record the duration of the live broadcast of the first video; When the duration of the video exceeds a set threshold time, the terminal stops buffering the video data of the second video.

Here, the set threshold may be set according to the history of the user ’s previous browsing of the live video and staying on the live video; for example, if the user stays on A's live broadcast for more than 30s, the user can be regarded as the user ’s live video on A ’s live broadcast. If you are interested, you will stay on the page of A's live video for a long time. In this way, the threshold that can be set can be 30s; different users can set the threshold time differently; the same user corresponds to different types of live video, The set threshold time can also be different.

Here, when switching from one live video to another live video, the threshold time of the timer needs to be reset. The set threshold time may be the same as or different from the previous threshold. For example, for the live video of the A host, the threshold time of the timer is set to 30s; for the live video of the B host, the threshold time of the timer can be set to 15s. When the terminal APP switches from the live video of the anchor A to the live video of the anchor B, the timing from the start time of the live broadcast of the live broadcast of the B anchor is counted from 0, and the set threshold time is 15s.

It should be noted that, in this embodiment, it is detected whether the duration of the live broadcast of the first video exceeds a set threshold to infer whether the user is interested in the content of the first video, so as to determine whether it will stay in the place for a long time. The first video is described, and the video content of the first video is viewed. If it is determined that the dwell time exceeds the set threshold time, it is determined that the user will stay on the first video for a long time, so that it will not switch to the second video in a short time, and by stopping the video data of the second video The cache can save the cache space; and because it does not need to perform synchronous buffering of the video data of the second video, it can also reduce the power consumption of the terminal device, thereby achieving the purpose of saving power.

Example Seven

Based on the first embodiment, as shown in FIG. 4, before step 103, step 102 is further included to determine whether a cache condition is satisfied;

Specifically, the terminal determines whether the cache condition is satisfied.

The step 103 includes: if the buffer condition is satisfied, buffering video data of the second video when the first video is live broadcasted.

Further, determining whether the cache condition is satisfied in step 102 includes at least one of the following:

Scenario 1: if it is detected that the current bandwidth of the live broadcast device is greater than the bandwidth required to receive video data of the first video, it is determined that the cache condition is satisfied;

Scenario 2: if it is detected that the current bandwidth of the live broadcast device is not less than the sum of the bandwidth required to receive video data of the first video and the second video, it is determined that the cache condition is satisfied;

Scenario 3: if it is detected that the network currently connected to the live broadcast device is a predetermined type of network, it is determined that the cache condition is satisfied;

Scenario 4. If the configuration data of the live broadcast device indicates that the second video is cached, it is determined that the cache condition is satisfied;

Scenario 5. If the configuration data of the live broadcast device indicates that the second video is cached and it is detected that the current bandwidth of the live broadcast device is greater than the bandwidth required to receive the video data of the first video, it is determined that the cache condition is satisfied;

Scenario 6. If the configuration data of the live broadcast device indicates that the second video is cached and it is detected that the network currently connected to the live broadcast device is a predetermined type of network, it is determined that the cache condition is satisfied.

Here, the live broadcast device is a terminal, which may be a desktop computer, a smart phone, a tablet computer, or other electronic equipment; the live broadcast device is an electronic device that performs video live broadcast.

It should be noted that, for scenario 1, if it is detected that the current bandwidth of the live broadcast device is greater than the bandwidth required to receive the video data of the first video, it may be determined that the bandwidth of the live broadcast device can cache the video data of the first video, There is also at least a part of the excess bandwidth for buffering the video data of the second video.

For scenario two, if it is detected that the current bandwidth of the live broadcast device is not less than the sum of the bandwidth required to receive video data of the first video and the second video, it may be determined that the live broadcast device has sufficient bandwidth for the first time. Cache of video data for one video and second video.

For scenario three, if it is detected that the network currently connected to the live broadcast device is a predetermined type of network, it is determined that the live broadcast device has sufficient bandwidth to cache the video data of the first video and the second video.

For scenario 4, if the configuration data of the live broadcast device indicates that the second video is cached, it is determined that the bandwidth of the live broadcast device can cache the video data of the first video, and at least the video data of the second video may be cached. .

For scenario 5, if the configuration data of the live broadcast device executes buffering the second video and it is detected that the current bandwidth of the live broadcast device is greater than the bandwidth required to receive the video data of the first video, it is determined that the bandwidth of the live broadcast device may be On the premise of buffering the video data of the first video, there is still at least a part of the excess bandwidth for buffering the video data of the second video.

For scenario 6, if the configuration data of the live broadcast device indicates that the second video is cached and it is detected that the network currently connected to the live broadcast device is a predetermined type of network, it is determined that the bandwidth of the live broadcast device can cache the first video. On the premise of video data, video data of at least the second video may be cached.

It should be noted that, in this embodiment, whether to buffer the video data of the next live video in advance may be implemented according to whether the bandwidth of the live broadcast device meets the conditions.

Example eight

Based on the first embodiment, as shown in FIG. 5, before step 103, step 106 is further included to determine the second video according to the association relationship between the videos.

Further, the step 106 further includes:

According to the display position relationship of the live link on the live video selection page, a video corresponding to a second live link adjacent to the first live link of the first video is selected as the second video.

It should be noted that, in another embodiment, the determining the second video according to the association relationship between the videos may further be: selecting the first video according to the display position relationship of the homepage of the live video on the interactive display screen. The live video corresponding to the homepage of a video adjacent to or adjacent to the homepage of the live video is the second video.

In another embodiment, the determining the second video according to the association relationship between the videos may further be: selecting a first connection with the first video according to a display position relationship of the live link on the live video selection page. The video corresponding to the third live link of one live link separated by one or more live links is the second video.

Example Nine

In order to further explain, the present invention also proposes a live video processing method. The method is mainly directed to a scenario where a terminal receives a first type of GOP; the first type of GOP is a complete GOP, and the first type of GOP includes : I frame, P frame, and B frame; as shown in FIG. 6, the method includes the following steps.

Step S001: Select live video A; and set timer T1;

Optionally, start the terminal device; click to enter the terminal APP page; click to select a certain live video A in the live video category in the terminal APP; set a timer in the terminal APP, and the timer is set to start from the live broadcast A of the terminal APP The timing starts at the moment, and the set threshold time is T1; wherein the terminal APP is an application program for live video broadcasting, for example, it can be Yingke live software, pepper pepper live software, Huya live software, Douyu live software, etc.

Here, by setting the threshold time of the timer, it is possible to determine whether the user may broadcast video A for a long time according to the duration of the terminal APP's subsequent live broadcast on video A.

Step S002: Send a request to pull A media stream;

Optionally, the terminal APP sends a request for pulling the A media stream to the media server.

Step S003: Push A media stream;

Optionally, the media server pushes A media stream to the terminal APP; the media stream may be understood as the video data in the first embodiment, and the media stream includes a video stream and an audio stream.

Step S004: Live A media stream;

Optionally, after the terminal APP receives the A media stream sent by the media server, the terminal APP decodes the A media stream.

Step S005: Send a request to pull a neighboring B media stream;

Optionally, while the terminal APP normally plays the A stream, the terminal APP sends a request to the media server to pull the media stream of the video B corresponding to the second live connection adjacent to the live link of the video A; the terminal APP detects that When the currently accessed network is WIFI or a wired network, or when the user is configured to pre-cache the first type of GOP, a request to pull a media stream including the first type of GOP to the media server is sent.

Here, the first type of GOP includes: I frame, B frame, and P frame.

Step S006: Push the B media stream;

Optionally, after the media server receives the request sent by the terminal APP, the media server pushes the B media stream to the terminal APP; the B media stream includes: a B video stream and a B audio stream.

Here, the GOP in the pushed media stream is the first type of GOP.

Step S007: Save 1 or N GOPs of the B media stream;

Optionally, one or N first-type GOPs in the B media stream are buffered in a local cache of the terminal; where N is a natural number greater than 1.

Step S008: receiving a switching instruction to control the live B media stream; and resetting the T1 timer;

Optionally, the terminal detects the duration of the live A media stream; if the terminal receives a switching instruction before the duration of the live A media stream is less than T1, the terminal APP controls the live B media stream according to the switching instruction; and the terminal resets the timing The timer is set to start counting from the start time of the live B media stream, and the threshold time is T1.

Here, according to the switching instruction to control the live B media stream, it may be performed by performing a sliding operation in the live broadcast display area of the terminal APP to switch to video B to live the B media stream; or it may be performed other operations to switch to video B Live B media stream.

Here, the time for resetting the timer may be different from T1.

Step S009: playing one or N GOPs of the buffered B media stream;

Optionally, the terminal determines whether a B media stream exists in the local cache space; if so, the terminal APP plays the B media stream cached in the local cache space; specifically, plays a first-type GOP or N of the cached B media stream GOP of the first kind.

Step S010: Send a request to continue pulling the B media stream;

Optionally, the terminal APP sends a request to the media server to continue to pull the B media stream; wherein, it may be a request to send the first type of GOP of the unbuffered B media stream; or the first request to send the unbuffered B media stream GOP-like and GOP of the first type that sends a B media stream that has been buffered in the local cache space but has not started to play.

Step S011: continue to push the B media stream;

Optionally, the media server continues to push the B media stream to the terminal APP; after the terminal APP receives the B media stream, it decodes the B media stream; the decoded B is normally displayed by the media stream for the normal live broadcast of the video B; said B The media stream includes: a B video stream and a B audio stream, and the B media stream includes a first type GOP set.

Step S012: Send a request to pull a neighboring C media stream;

Optionally, while the B media stream is normally played, the terminal APP sends a request to the media server to pull the media stream of the video C corresponding to the third live connection adjacent to the live link of the video B; the terminal APP detects the current connection The incoming network is WIFI or a wired network, or when the user is configured to pre-cache the first type of GOP, a request to pull the first type of GOP is sent to the media server.

Here, the first type of GOP includes: an I frame, a B frame, and a P frame.

Step S013: Push the C media stream;

Optionally, after the media server receives the request sent by the terminal APP, the media server pushes a C media stream to the terminal APP; the C media stream includes a C video stream and a C audio stream, and the C video stream includes one or N A first type of GOP video stream.

Step S014: save 1 or N GOPs of the C media stream;

Optionally, one first-type GOP or N first-type GOP sets of the C video stream is cached in a local cache; where N is a natural number greater than 1.

Step S015: no longer change the video;

Optionally, the terminal APP continuously broadcasts the B media stream.

Here, the terminal APP continuously broadcasts the B media stream, indicating that the end user is interested in video B.

Step S016: T1 timeout is detected;

Optionally, the terminal detects that the duration of the terminal APP's continuous live broadcast of the B media stream exceeds the threshold time T1 of the timer.

Step S017: Send a request to stop pushing the media stream of C, and disconnect the connection;

Optionally, when the duration of the live broadcast of the B media stream of the terminal APP exceeds the time T1, the terminal APP sends a request to the media service to stop pushing the C media stream; and stops receiving the C media by disconnecting the transmission protocol between the terminal APP and the media server. flow.

Step S018: Clear the cache of the media stream of C.

Optionally, the terminal clears the C media stream in the buffer space.

It should be noted that, in this embodiment, during the live broadcast of the video, the user can continuously switch the live video by sliding when searching for a favorite channel or program; by pre-buffering the media stream of the B video during the playback of the A video One GOP or N GOP set. By playing a GOP or N GOP set of the C video media stream in advance when playing the B video media stream, the "black screen" state or no program state caused by switching can be avoided, which can be achieved. In addition to the first live video A, the waiting time for the first appearance of other live videos is short, which is shorter than the second open time.

In this way, this embodiment greatly reduces the stall rate, so that the entire live broadcast process can present a picture state, which greatly improves user satisfaction.

It should be noted that, in this embodiment, when a live video is played, the first type of GOP is cached when the next live video is cached. Since the first type of GOP is a complete frame set, including I frames, B frames, and P-frame, so when switching live video, users can watch the video content at the full frame rate, so they can watch very clear pictures and increase user satisfaction.

Example 10

In order to further explain, the present invention also proposes a live video processing method. The method is mainly for a scenario in which a terminal receives a second type of GOP / a third type of GOP; the second type of GOP is discarded compared to the first type of GOP. B frame, the second type of GOP discards B frame and P frame compared to the first type of GOP; as shown in FIG. 7, the method includes the following steps.

Step S201: Select live video A; and set timer T1;

Optionally, start the terminal device; click to enter the terminal APP page; click to select a certain live video A in the live video category in the terminal APP; set a timer in the terminal APP, and the timer is set to start from the live broadcast A of the terminal APP The timing starts at the moment, and the set threshold time is T1. Among them, the terminal APP is an application program for performing live video streaming, such as Momo Live Streaming Software, Zanthoxy Live Streaming Software, Huya Live Streaming Software, Douyu Live Streaming Software, and Live Bar Software. and many more

Step S202: Send a request to pull A media stream;

Step S203: Push A media stream;

Optionally, the media server pushes A media stream to the terminal APP; the A media stream includes: A video stream and A audio stream.

Step S204: Live A media stream;

Step S205: sending a request for pulling the neighboring B media stream; the request carries an indication of frame loss;

Optionally, while the terminal APP normally plays the A stream, the terminal APP sends a request to the media server to pull the media stream of the video B corresponding to the second live connection adjacent to the live link of the video A; and The request carries an indication of dropped frames, and the indication of dropped frames is: the indication of dropped B frames, or the indication of dropped B and P frames.

Here, it should be noted that the request carries the indication identifier of the dropped frame. In fact, the request is to pull an incomplete GOP. For example, in one embodiment, the request carries the indication identifier of the dropped B frame. In order to pull the second type of GOP, in another embodiment, the request carrying the indication identifiers of the dropped B and P frames is to pull the third type of GOP; wherein the second type of GOP includes: P frame and I frame; the third type of GOP includes: I frame.

In another embodiment, the request may carry an indication identifier for dropping a B frame and an indication identifier for dropping a P frame and a B frame. For example, the request to pull adjacent B media streams carries the indication that the most recent GOP at the current moment is the discarded B frame, and the carrying the most recent 2 to 5 GOPs at the current moment is the discarded B frame And the indication identifier of the P frame.

In another embodiment, the request for pulling the adjacent B media stream may also carry an indication identifier that the most recent first to third GOPs at the current moment are the dropped B frame and P frame, and carry the current The fourth GOP with the most recent moment is the indication that the B frame is dropped, and the indication that the fifth GOP with the most recent moment is the complete GOP.

Step S206: Push the B media stream;

Optionally, after the media server receives the request sent by the terminal APP, the media server pushes the B media stream to the terminal APP; the B media stream includes: a B video stream and a B audio stream; and the B video stream includes a second Class / Third GOP or N Second / Third GOP Set Video Streams.

Here, it should be noted that although the push B video stream is an incomplete GOP, such as a second type GOP or a third type GOP; however, the audio stream corresponding to the B video stream does not drop frames and is pushed to the terminal APP The audio stream is unchanged.

Here, it needs to be explained that the push B video stream can be controlled to be a set of the second type of GOP and the third type of GOP; correspondingly, the request may carry an instruction for dropping B frames and an instruction for dropping P frames and B frames.

Step S207: Save one or N GOPs of the B media stream;

Optionally, one or N second-type / third-type GOPs of the B media stream are buffered in a local cache of the terminal; where N is a natural number greater than 1.

Step S208: receiving a switching instruction, controlling the live B media stream; and resetting the T1 timer;

Here, the time for resetting the timer may be different from T1.

Step S209: play one or N GOPs of the buffered B media stream;

Optionally, the terminal determines whether a B media stream exists in the local cache space; if so, the terminal APP plays the B media stream cached in the local cache space; specifically, plays one or N GOPs of the cached B media stream; The GOP type for playing one or N GOPs of the buffered B media stream is described as the second type / third type GOP.

Step S210: Send a request to continue to pull the B media stream;

Optionally, the terminal APP sends a request to the media server to continue to pull the B media stream; wherein, it may be a request to send the first type of GOP of the unbuffered B media stream; or the first request to send the unbuffered B media stream GOP-like and the first GOP that sends a B media stream that has been buffered in the local cache space but has not started playing.

It should be noted that, in step S210, since the B video stream has already been broadcast live at this time, the first type GOP or N GOP set of the B media stream can be pulled, and the B media stream can be played normally, so that the video The picture is clearer; moreover, it is also possible to clear the second type / third type GOP that was previously cached but not played, and pull the first type GOP to be cached.

Step S211: Continue to push the B media stream;

Optionally, the media server continues to push the B media stream to the terminal APP; after the terminal APP receives the B media stream, the B media stream is decoded; the decoded B is normally displayed by the media stream for the normal live broadcast of the video B; said B The media stream includes a B video stream and a B audio stream. The B video stream is a video stream including a first type of GOP set.

Step S212: Send a request to pull the adjacent C media stream; the request carries an indication of frame loss;

Optionally, while the B media stream is normally played, the terminal APP sends a request to the media server to pull the media stream of the video C corresponding to the third live link adjacent to the live link of the video B; and in the request, It carries an indication identifier of dropped frames, where the indication identifier of dropped frames is: the indication identifier of dropped B frames, or the indication identifier of dropped B frames and P frames.

Here, it should be noted that the request in the request carries an indication identifier of a dropped frame. In fact, the request is to pull an incomplete GOP; for example, in one embodiment, the indication identifier of a dropped B frame is carried. Request for pulling the second type of GOP; in another embodiment, the request carrying the indication identifiers of discarded B and P frames is pulling the third type of GOP; wherein the second type of GOP includes : P frame and I frame; the third type of GOP includes: I frame.

Step S213: Push the C media stream;

Optionally, after the media server receives the request sent by the terminal APP, the media server pushes the C media stream to the terminal APP; the C media stream includes a C video stream and a C audio stream, and the C video stream includes a second Class / Third GOP or N Second / Third GOP Set Video Streams.

Here, it should be noted that the C audio stream in the C media stream is not dropped when the terminal APP is pushed.

Step S214: Save 1 or N GOPs of the C media stream;

Optionally, a second type / third type GOP or N second type / third type GOP set of the C media stream is cached in a local cache; wherein, N is a natural number greater than 1.

Step S215: no longer change the video;

Optionally, the terminal APP continuously broadcasts the B media stream.

Step S216: T1 timeout is detected;

Step S217: Send a request to stop pushing the media stream of C, and disconnect the connection;

Step S218: Clear the buffer of C's media stream.

Optionally, the terminal clears the C media stream in the buffer space.

It should be noted that, in this embodiment, during the live broadcast of the video, the user can continuously switch the live video by sliding when searching for a favorite channel or program; by pre-buffering the media stream of the B video during the playback of the A video One or N GOPs. By playing one or N GOPs of the C video media stream before playing the B video media stream, the "black screen" state or no program state caused by switching can be avoided. Except for the live video A, the waiting time for the first appearance of other live videos is short, and the time to achieve the opening is shorter than the second opening time. In this way, this embodiment greatly reduces the stall rate, so that the entire live broadcast process can present a picture state, which greatly improves user satisfaction.

It should be noted that in this embodiment, the second / third type of GOP linking adjacent video streams is pre-cached by audio and video to achieve fast playback of the switching process; when the user switches to the next live broadcast linking adjacent During video, users can watch low frame rate video content according to different network conditions, making it possible to sacrifice the sharpness of the screen in exchange for saving traffic; after playing for a period of time connected to the next live video, it can be played again. Watch the full frame rate of video content and the picture clarity is restored. Thus, in this embodiment, according to the traffic package of the terminal device, a unique scenario for pre-caching the media stream of the next live video can be set, and B frames or P and B frames can be dropped to achieve fast video playback during video switching. .

Example 11

In order to further explain, the present invention also proposes a live video processing method. The method is mainly directed to a scenario in which pre-cache is not performed when the bandwidth of the live broadcast device does not meet the pre-cache conditions. As shown in FIG. 8, the method includes the following steps.

Step S301: selecting a live video A;

Optionally, start a terminal device; click to enter the terminal APP page; click to select a live video A in the live video category of the terminal APP; wherein the terminal APP is an application program for performing live video, such as Panda Live, CC Live, Tentacle, Dragon Ball Live, etc.

Step S302: determine that the bandwidth is insufficient, and do not pre-cache the media stream of the next video;

Optionally, it is detected that the current bandwidth of the live broadcast device is less than the bandwidth required to receive the media stream of the A video and the media stream of the next video B, or the terminal detects that the configuration data of the live broadcast device indicates that the next video is not pre-cached When a media stream is generated, the terminal does not perform an operation of pre-caching the media stream of the next video.

Here, the next video B is a video that the first live broadcast link of video A is adjacent to the second live broadcast bet; or, the next video B is a display interactive screen that is adjacent to or adjacent to the homepage of video A. Video.

Step S303: Send a request to pull A media stream;

Here, the media stream includes a series of GOPs; the GOP is a first type of GOP.

Step S304: Push A media stream;

Step S305: Live A media stream;

Optionally, after the terminal APP receives the A media stream sent by the media server, the terminal APP decodes the A media stream; the terminal APP broadcasts the A media stream live.

It should be noted that in this embodiment, it is also possible to determine whether to perform the operation of pre-caching the media stream of the next video according to the bandwidth situation of the live broadcast device. In this way, this embodiment can prevent the The action of pre-caching the media stream of the next video.

It should be noted here that the description of the following live video processing device items is similar to the description of the live video processing method described above, and the beneficial effects of the same method are described without further description. For technical details not disclosed in the embodiment of the live video processing apparatus of the present invention, please refer to the description of the embodiment of the live video control method of the present invention.

An embodiment of the present invention also provides a video live broadcast device. Referring to FIG. 9, the device includes: a video live broadcast module 21 and a cache module 22;

The video live broadcast module 21 is configured to live broadcast the first video; and is also used to stop the live broadcast of the first video when a switching instruction is detected, and use the cached video data to live broadcast the second video;

The buffering module 22 is configured to buffer video data of the second video when the first video is broadcast live.

Optionally, the video live broadcast module 21 further includes: a first switching sub-module 211 and a second switching sub-module 212;

The first switching sub-module 211 is configured to control the live video of the first video to slide out of the display area from the first direction when the switching instruction is detected;

The second switching submodule 212 is configured to control a live broadcast picture of the second video to slide into the display area from a second direction of the display area;

The second direction is opposite to or the same as the first direction.

Optionally, the video live broadcast module 21 further includes: a first detection sub-module 213 and a generation sub-module 214;

The first detection sub-module 213 is configured to detect a sliding operation acting on a display interactive screen;

The generating sub-module 214 is configured to generate the switching instruction if the sliding operation is detected;

The sliding direction of the sliding operation is the first direction.

Optionally, the buffering module 22 is further configured to buffer, when the first video is broadcast live, at least one group of pictures GOP at the current moment of the second video live broadcast.

Optionally, the cache module 22 is further configured to cache at least one first-type GOP of the second video at the current moment when the first video is broadcasted live, where the first-type GOP includes: I Frames, B frames, and P frames.

Optionally, the cache module 22 is further configured to cache at least one second-type GOP or at least one third-type GOP when the first video is broadcast live;

Optionally, the apparatus further includes: a duration detection module 23;

The duration detection module 23 is configured to detect whether the duration of the live broadcast of the first video exceeds a set threshold;

Optionally, the apparatus further includes: a first determining module 24;

The first determining module 24 is configured to determine whether a cache condition is satisfied;

The buffering module is further configured to buffer the video data of the second video when the first video is broadcast live if the buffering conditions are met.

Optionally, the determining whether the cache condition is satisfied includes:

If it is detected that the current bandwidth of the live broadcast device is greater than the bandwidth required to receive video data of the first video, determining that the buffer condition is satisfied;

If it is detected that the current bandwidth of the live broadcast device is not less than the sum of the bandwidth required for receiving the video data of the first video and the second video, determining that the cache condition is satisfied;

If it is detected that the network currently connected to the live broadcast device is a predetermined type of network, determine that the cache condition is satisfied;

If the configuration data of the live broadcast device indicates that the second video is cached, determining that the cache condition is satisfied;

If the configuration data of the live broadcast device indicates that the second video is cached and it is detected that the current bandwidth of the live broadcast device is greater than the bandwidth required to receive video data of the first video, determining that the cache condition is satisfied;

If the configuration data of the live broadcast device indicates that the second video is cached and it is detected that the network currently connected to the live broadcast device is a predetermined type of network, it is determined that the cache condition is satisfied.

Optionally, the apparatus further includes: a second determining module 25;

The second determining module 25 is configured to determine the second video according to an association relationship between the videos.

Optionally, the second determining module 25 is further configured to select a video corresponding to a second live link adjacent to the first live link of the first video according to a display position relationship of the live link on the live video selection page. Is the second video.

An embodiment of the present invention also discloses a terminal. As shown in FIG. 10, the terminal includes a processor 31 and a memory 32 for storing a computer program capable of running on the processor; wherein the processor is used for running The computer program implements the live video processing method provided by any embodiment of the present invention.

In some embodiments, the memory 32 in the embodiment of the present invention may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), and an electronic memory. Erase programmable read-only memory (EPROM, EEPROM) or flash memory. The volatile memory may be Random Access Memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (Synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDRSDRAM), enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (Synchlink DRAM, SLDRAM) And direct memory bus random access memory (Direct RAMbus RAM, DRRAM). The memory 32 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

The processor 31 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method may be completed by an integrated logic circuit of hardware in the processor 31 or an instruction in the form of software. The above-mentioned processor 31 may be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a ready-made programmable gate array (Field Programmable Gate Array, FPGA), or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. Various methods, steps, and logical block diagrams disclosed in the embodiments of the present invention may be implemented or executed. A general-purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in combination with the embodiments of the present invention can be directly embodied as being executed by a hardware decoding processor, or completed by using a combination of hardware and software modules in the decoding processor. The software module may be located in a mature storage medium such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, and the like. The storage medium is located in the memory 32, and the processor 31 reads information in the memory 32 and completes the steps of the foregoing method in combination with its hardware.

In some embodiments, the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSP), digital signal processing devices (DSPD), programmable Logic device (Programmable Logic Device, PLD), Field Programmable Gate Array (FPGA), general purpose processor, controller, microcontroller, microprocessor, other for performing the functions described in this application Electronic unit or combination thereof.

For software implementation, the techniques described herein can be implemented through modules (e.g., procedures, functions, etc.) that perform the functions described herein. Software codes may be stored in a memory and executed by a processor. The memory may be implemented in the processor or external to the processor.

An embodiment of the present invention further provides a live video processing system. As shown in FIG. 11, the system includes a terminal 41 and a media server 42. The terminal 41 is configured to implement the provided by any embodiment of the present invention. Video live processing method; the media server 42 is configured to send video data of a first video and / or video data of a second video to the terminal 41.

Another embodiment of the present invention further provides a computer storage medium. The computer-readable storage medium stores an executable program. When the executable program is executed by the processor 31, the following steps of the picture processing and distribution method can be implemented:

Broadcast the first video;

Optionally, when the executable program is executed by the processor 31, it is further configured to implement the following steps:

The second direction is opposite to or the same as the first direction.

Detect the sliding operation acting on the display interactive screen;

If the sliding operation is detected, generating the switching instruction;

The sliding direction of the sliding operation is the first direction.

When the first video is broadcast live, at least one first-type GOP of the second video being broadcast at the current moment is cached, where the first-type GOP includes: I-frame, B-frame, and P-frame. Optionally, when the executable program is executed by the processor 31, it is further configured to implement the following steps:

When the first video is broadcast live, buffer at least one second type GOP or at least one third type GOP;

Detecting whether the duration of the live broadcast of the first video exceeds a set threshold;

Determine whether the cache conditions are met;

The buffering the video data of the second video when the first video is broadcast live includes:

If the cache condition is satisfied, the video data of the second video is cached when the first video is broadcast live.

Optionally, when the executable program is executed by the processor 31, it is further configured to implement at least one of the following steps:

Determining the second video according to the association relationship between the videos.

In some embodiments, the computer storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM, Read Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk, or an optical disk. A medium on which program code can be stored.

The above are only specific embodiments of the present invention, but the scope of protection of the present invention is not limited to this. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed by the present invention. It should be covered by the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

A method for processing live video, wherein the method includes:

Broadcast the first video;

Buffering video data of the second video when the first video is live broadcasted;

When a switching instruction is detected, the live broadcast of the first video is stopped, and the second video is broadcast live using the cached video data.
The method according to claim 1, wherein when the switching instruction is detected, stopping the live broadcast of the first video and using the cached video data to live broadcast the second video comprises:

When the switching instruction is detected, controlling the live video of the first video to slide out of the display area from the first direction;

Controlling the live broadcast picture of the second video to slide into the display area from a second direction of the display area;

The second direction is opposite to or the same as the first direction.
The method according to claim 2, wherein the method further comprises:

Detect the sliding operation acting on the display interactive screen;

If the sliding operation is detected, generating the switching instruction;

The sliding direction of the sliding operation is the first direction.
The method according to claim 1, wherein, when the first video is broadcast live, buffering video data of a second video comprises:

When the first video is broadcast live, at least one group of pictures GOP that is live broadcast at the current moment of the second video is buffered.
The method according to claim 4, wherein, when the first video is broadcast live, buffering at least one group of pictures GOP at the current moment of the second video comprises:

When the first video is broadcast live, at least one first-type GOP of the second video being broadcast at the current moment is cached, where the first-type GOP includes: I-frame, B-frame, and P-frame.
The method according to claim 4, wherein, when the first video is live broadcasted, buffering at least one group of pictures GOP of the second video live broadcast at the current moment, further comprising:

When the first video is broadcast live, buffer at least one second type GOP or at least one third type GOP;

The second type of GOP lacks B frames compared to the first type of GOPs; the third type of GOP lacks B frames and P frames compared to the first type of GOPs.
The method according to claim 1, wherein before the switching instruction is detected, further comprising:

Detecting whether the duration of the live broadcast of the first video exceeds a set threshold;

If the duration of the live broadcast of the first video exceeds the threshold, the buffering of video data of the second video is stopped.
The method according to claim 1, further comprising:

Determine whether the cache conditions are met;

The buffering the video data of the second video when the first video is broadcast live includes:

If the cache condition is satisfied, the video data of the second video is cached when the first video is broadcast live.
The method according to claim 8, wherein the determining whether the cache condition is satisfied comprises at least one of the following:

If it is detected that the current bandwidth of the live broadcast device is greater than the bandwidth required to receive video data of the first video, determining that the buffer condition is satisfied;

If it is detected that the current bandwidth of the live broadcast device is not less than the sum of the bandwidth required for receiving the video data of the first video and the second video, determining that the cache condition is satisfied;

If it is detected that the network currently connected to the live broadcast device is a predetermined type of network, determine that the cache condition is satisfied;

If the configuration data of the live broadcast device indicates that the second video is cached, determining that the cache condition is satisfied;

If the configuration data of the live broadcast device indicates that the second video is cached and it is detected that the current bandwidth of the live broadcast device is greater than the bandwidth required to receive video data of the first video, determining that the cache condition is satisfied;

If the configuration data of the live broadcast device indicates that the second video is cached and it is detected that the network currently connected to the live broadcast device is a predetermined type of network, it is determined that the cache condition is satisfied.
The method according to claim 1, wherein before the buffering the video data of the second video, further comprising:

Determining the second video according to the association relationship between the videos.
The method according to claim 10, wherein determining the second video according to an association relationship between videos comprises:

According to the display position relationship of the live link on the live video selection page, a video corresponding to a second live link adjacent to the first live link of the first video is selected as the second video.
A video live broadcast processing device, wherein the device includes:

A video live broadcast module for live broadcast of the first video; and also for stopping the live broadcast of the first video when a switching instruction is detected, and live broadcast of the second video by using the cached video data;

The buffering module is configured to buffer video data of the second video when the first video is broadcast live.
A terminal, wherein the terminal includes a processor and a memory for storing a computer program capable of running on the processor; wherein when the processor is used to run a computer program, the device according to any one of claims 1-11 is implemented The video live broadcast processing method is described.