CN114025184A

CN114025184A - Video live broadcast method and electronic equipment

Info

Publication number: CN114025184A
Application number: CN202111258740.1A
Authority: CN
Inventors: 金逸添; 潘智轩; 杨冬阳; 宁桥
Original assignee: Shenzhen Futu Network Technology Co Ltd
Current assignee: Shenzhen Futu Network Technology Co Ltd
Priority date: 2021-10-27
Filing date: 2021-10-27
Publication date: 2022-02-08

Abstract

The application provides a video live broadcast method and electronic equipment, relates to the technical field of computers, and can enable a user to continue live broadcast in the same live broadcast room after live broadcast interruption, so that the use experience of a live broadcast initiating user and a live broadcast watching user is improved. The method comprises the following steps: the server acquires a live broadcast request sent by a first terminal by using a first account; the server determines that target live broadcast in a continuous broadcast state exists under the first account; and the server sends continuous playing information of the target live broadcast to the first terminal, so that the first terminal continues playing the target live broadcast according to the continuous playing information.

Description

Video live broadcast method and electronic equipment

Technical Field

The application relates to the technical field of computers, in particular to a video live broadcast method and electronic equipment.

Background

With the development of internet technology, users can transmit the video data recorded by themselves to the internet in real time in a live network mode, so that viewers can watch the video data on the internet in real time. For example, the user a may install an Application (APP) with a live function on an electronic device such as a mobile phone. Furthermore, after the user a opens the live function in the application, the electronic device may start to record video data (i.e., live content) in real time by using components such as a camera and a microphone, and send the live content to the server in real time. In this way, the server can distribute the live content uploaded by the user A through the electronic equipment on the Internet. At this time, other users (for example, user B, user C, etc.) can enter the live room of user a through their own electronic devices, and obtain the live content of user a from the server for real-time viewing.

In some live network scenarios, the live broadcast may be abnormally interrupted. For example, when the electronic device initiating the live broadcast is disconnected or the application initiating the live broadcast is unexpectedly closed, the live broadcast is abnormally interrupted, and a user watching the live broadcast cannot continue to watch the live broadcast. At this time, if the user initiating the live broadcast needs to continue the live broadcast, the electronic device and the application need to be operated again to create a new live broadcast room to initiate a new live broadcast again, and the operation is cumbersome and the user experience is not high. In addition, the user who watches the live broadcast before can continuously watch the live broadcast content after the live broadcast is interrupted only by replacing the live broadcast room, so that the use experience of the user who watches the live broadcast is poor.

Disclosure of Invention

The embodiment of the application provides a video live broadcast method and electronic equipment, which can facilitate a user to continue live broadcast in the same live broadcast room after live broadcast interruption, and improve the use experience of a live broadcast initiating user and a live broadcast watching user.

In a first aspect, a video live broadcast method is provided, including:

the server acquires a live broadcast request sent by a first terminal by using a first account; further, the server can determine whether a target live broadcast in a continuous broadcast state exists under the first account; if the target live broadcast in the continuous broadcast state exists, the server can send continuous broadcast information of the target live broadcast to the first terminal, so that the first terminal can continue the target live broadcast according to the continuous broadcast information, and the function of breakpoint continuous broadcast during live broadcast is realized. Therefore, the user initiating the live broadcast can continue to complete the abnormally interrupted live broadcast in the original live broadcast room, and the user watching the live broadcast can also continue to watch the continuous live broadcast in the original live broadcast room, so that the use experience of the user initiating the live broadcast and the user watching the live broadcast is improved.

In one possible implementation manner, the server determining that a target live broadcast in a continuous broadcast state exists in a first account includes: when the server does not receive the heartbeat data packet corresponding to the target live broadcast within the preset time, the server can determine that the target live broadcast is in a continuous broadcast state. At this point, the server may mark the target live-air ID as playable.

In a possible implementation manner, after the server determines that there is a target live broadcast in a continuous broadcast state under the first account, the method further includes: and the server indicates the first terminal to display a continuous playing prompt which is used for prompting whether the anchor broadcast continues the target live broadcast or not. The anchor may manually select whether to resume the broadcast on the terminal.

In a possible implementation manner, the sending, by the server, resume information of the target live broadcast to the first terminal includes: and after receiving the continuous playing request sent by the first terminal, the server sends continuous playing information of the target live broadcast to the first terminal.

In a possible implementation manner, the resume information may include one or more of a live room ID, a start time, a live time, a client type, and a live mode of the target live broadcast.

In a second aspect, a video live broadcasting method is provided, including:

the server acquires a live broadcast request sent by a first terminal by using a first account; when the live broadcast in the continuous broadcast state does not exist under the first account, the fact that the live broadcast is a new live broadcast initiated by the main broadcast is indicated, the server can allocate a corresponding live broadcast room ID for the live broadcast, the allocated live broadcast room ID is sent to the first terminal, and the first terminal completes the live broadcast by using the live broadcast room ID.

In a possible implementation manner, after the server allocates a corresponding live broadcast room ID for the live broadcast, the method further includes: the server binds the ID of the live broadcast room with the corresponding live broadcast forecast; and then the server can send live broadcast push messages to the live broadcast users who reserve the live broadcast previews, so that the live broadcast users who reserve the live broadcast previews can timely know the messages of the start of live broadcast.

In a third aspect, a video live broadcast method is provided, including:

the server receives a forecast request sent by a second terminal, wherein the forecast request comprises forecast content of a first direct broadcast forecast, and the second terminal can be the same as or different from the first terminal (namely, a terminal for issuing the direct broadcast forecast can be the same as or different from a terminal for actual direct broadcast); the server issues the forecast content of the first live forecast to the social platform, so that the popularization capability of related live broadcasts in the live forecast is improved.

In a possible implementation manner, after the server receives the announcement request sent by the second terminal, the method further includes: the server receives a forecast modification request of a first direct broadcast forecast sent by a second terminal; in response to the forecast modification request, the server may send forecast content of the first direct broadcast forecast to the second terminal, the second terminal presents the forecast content and receives a modification of the anchor; and when the server receives the modified first direct broadcast preview sent by the second terminal, the preview content of the first direct broadcast preview can be updated.

In a possible implementation manner, after the server receives the announcement request sent by the second terminal, the method further includes: the server receives a deletion request of the first direct broadcast preview sent by the second terminal; in response to the deletion request, the server may delete the preview content of the first direct broadcast preview.

That is, after the anchor issues the live preview, the anchor may perform management operations such as modification and deletion on the issued live preview on the second terminal.

In a fourth aspect, a video live broadcasting method is provided, including:

when the first terminal receives the operation of initiating the live broadcast by the anchor input, the first terminal can send a live broadcast request to the server; when the live broadcast is in a continuous broadcast state, the first terminal can receive continuous broadcast information of the target live broadcast sent by the server; and then, the first terminal can continue to play the target live broadcast according to the continuous playing information, and the breakpoint continuous playing function is realized.

In a possible implementation manner, the resume information may include one or more of a live room ID, a start time, a time that has been live, a client type, and a live mode of the target live broadcast.

In a possible implementation manner, the resuming, by the first terminal, the target live broadcast according to the resume information includes: when the client type in the continuous playing information is a mobile terminal and the client type of the first terminal is also the mobile terminal, the first terminal continues playing the target live broadcast according to a live broadcast mode set in the continuous playing information; when the client type in the continuous playing information is a non-mobile terminal and the client type of the first terminal is a mobile terminal, the first terminal can continuously play the target live broadcast according to a horizontal screen mode; when the client type in the continuous playing information is the mobile terminal and the client type of the first terminal is the non-mobile terminal, the first terminal can prompt the anchor to select the live mode and continue playing the target live broadcast according to the live mode selected by the anchor.

Therefore, even if the type of the client which continues to broadcast is different from the type of the client which abnormally exits from the last live broadcast, the client which continues to broadcast can continue to broadcast according to the continuous broadcast information without replacing a live broadcast room, and the use experience of the main broadcast during live broadcast is improved. Meanwhile, a live broadcast user watching the live broadcast can also continue to watch the continuous live broadcast in the original live broadcast room, so that the use experience of the live broadcast user is improved.

In a possible implementation manner, before the first terminal receives the resume information of the target live broadcast sent by the server, the method further includes: and the first terminal displays a continuous playing prompt which is used for prompting the user whether to continue playing the live broadcast which is abnormally quitted last time.

In a fifth aspect, a video live broadcasting method is provided, including:

the first terminal displays a first setting interface of the first direct broadcast forecast; furthermore, the first terminal can receive forecast content input by the main broadcast in the first setting interface, wherein the forecast content can comprise one or more items of a live broadcast title, live broadcast time, a front cover and a live broadcast introduction; subsequently, the first terminal can carry the forecast content input by the main broadcast in the forecast request and send the forecast request to the server, and the server is requested to issue the live forecast.

In a possible implementation manner, after the first terminal sends the forecast content to the server while carrying the forecast content in the forecast request, the method further includes: the first terminal jumps to a management page of the live preview, the management page including a management list of the released one or more live previews. Thus, after the anchor releases the live preview, the anchor can perform management operations such as modification, deletion and the like on the released live preview on the management page.

In a possible implementation manner, after the first terminal jumps to a management page of the live preview, the method further includes: when receiving the modification operation of the main broadcast on the management page to the input of the first direct broadcast preview, the first terminal displays a second setting interface of the first direct broadcast preview, wherein the second setting interface comprises the written preview content of the first direct broadcast preview; when receiving the modification input by the anchor on the second setting interface, the first terminal may send a modification request to the server, where the modification request includes the modified first on-air preview.

In a possible implementation manner, after the first terminal jumps to a management page of the live preview, the method further includes: when receiving a deletion operation input by a host to the first live announcement on the management page, the first terminal transmits a deletion request to the server.

In a possible implementation manner, when the first terminal receives an operation of initiating a live broadcast by a host input, the sending, by the first terminal, a live broadcast request to the server includes: when receiving a live broadcast initiating operation input by a main broadcast on the management page to the first live broadcast preview, the first terminal sends a live broadcast request to the server, namely, the live broadcast is initiated from an entrance of the live broadcast preview.

In a sixth aspect, a server is provided, comprising: a processor and a memory for storing a computer program, the processor being adapted to invoke and execute the computer program stored in the memory to perform the method according to one of the first to third aspects as described above.

In a seventh aspect, a terminal is provided, including: a processor and a memory for storing a computer program, the processor being adapted to invoke and execute the computer program stored in the memory to perform the method according to one of the fourth to fifth aspects.

In an eighth aspect, there is provided a computer readable storage medium for storing a computer program for causing a computer to perform the method of any one of the above aspects or implementations thereof.

In a ninth aspect, there is provided a computer program product comprising computer program instructions to cause a computer to perform the method of any of the above aspects or implementations thereof.

A tenth aspect provides a computer program for causing a computer to perform the method of any one of the above aspects or implementations thereof.

It is understood that the server, the terminal, the computer-readable storage medium and the computer program product provided in the foregoing aspects are all configured to execute the corresponding methods provided above, and therefore, the beneficial effects achieved by the server, the terminal, the computer-readable storage medium and the computer program product may refer to the beneficial effects in the corresponding methods provided above, and are not described herein again.

Drawings

Fig. 1 is a schematic architecture diagram of a live broadcast system according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a video live broadcasting method according to an embodiment of the present application;

fig. 3 is a schematic flowchart of another video live broadcasting method according to an embodiment of the present application;

fig. 4 is a schematic view of an application scenario of a video live broadcast method according to an embodiment of the present application;

fig. 5 is a schematic view of an application scenario of another video live broadcasting method according to an embodiment of the present application;

fig. 6 is a schematic view of an application scenario of another video live broadcasting method according to an embodiment of the present application;

fig. 7 is a schematic flowchart of another video live broadcasting method according to an embodiment of the present application;

fig. 8 is a schematic application scenario diagram of another video live broadcasting method according to an embodiment of the present application;

fig. 9 is a schematic flowchart of another video live broadcasting method according to an embodiment of the present application;

fig. 10 is a schematic application scenario diagram of another video live broadcasting method according to an embodiment of the present application;

fig. 11 is a schematic flowchart of another video live broadcasting method according to an embodiment of the present application;

fig. 12 is a schematic application scenario diagram of another video live broadcasting method according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a terminal according to an embodiment of the present application;

fig. 14 is a schematic structural diagram of a server according to an embodiment of the present application;

fig. 15 is a schematic structural diagram of another terminal according to an embodiment of the present application;

fig. 16 is a schematic structural diagram of another server according to an embodiment of the present application.

Detailed Description

Technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments obtained by a person of ordinary skill in the art without making any creative effort with respect to the embodiments in the present application belong to the protection scope of the present application.

The embodiment of the application provides a video live broadcast method which can be applied to the live broadcast system 100 shown in fig. 1. The live system 100 may include an electronic device 101 and a server 102, among other things. The electronic device 101 and the server 102 may communicate over a network.

The electronic device 101 may be any terminal device. For example, but not limited to, a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc.

The server 102 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud computing services.

The electronic device 101 and the server 102 may be directly or indirectly connected through wired or wireless communication. The server 102 may receive an operation of a user and generate an instruction through the connected electronic device 101, and then the server 102 performs data processing according to the instruction of the electronic device 101, which is not limited herein.

Generally, in a live network scenario, as shown in fig. 2, after the electronic device 101 detects that a user input initiates a live broadcast operation, the electronic device 101 may send a live broadcast request to the server 102. The server 102 may allocate a live broadcast room ID of the live broadcast to the electronic device 101 in response to the live broadcast request, and then the electronic device 101 may start recording the live broadcast content, that is, the video data acquired by the electronic device 101, using the live broadcast room ID allocated by the server 102. Subsequently, the electronic device 101 may send the recorded live content to the server 102 in the form of a video stream in real time. In this way, the server 102 may publish the received live content on the internet using the live room ID as an index, and at this time, other users may use their own electronic devices to enter the corresponding live rooms to view the live content published in real time.

In the live broadcast process, as also shown in fig. 2, a communication method using a heartbeat mechanism may be used between the electronic device 101 and the server 102 to ensure the effectiveness of communication. For example, after acquiring the live broadcast ID assigned by the server 102, the electronic device 101 may periodically (e.g., 1 time every 5 seconds) send heartbeat packets to the server 102. After receiving the heartbeat data packet sent by the electronic device 101 each time, the server 102 may send a heartbeat response packet to the electronic device 101, so that the electronic device 101 knows that effective communication with the server 102 is currently possible.

When the user finishes the live broadcast or an abnormality (such as a network disconnection) occurs during the live broadcast, the electronic device 101 does not send the heartbeat data packet to the server 102 any more. When the server 102 does not receive the heartbeat data packet sent by the electronic device 101 within a preset time (for example, 30 seconds), the server 102 may release the live broadcast room ID to end the live broadcast.

However, the user usually has a demand for continuing the live broadcast after the interruption due to the abnormality in the live broadcast process, but at this time, the server 102 has released the live broadcast room ID of the live broadcast and ended the live broadcast. Then, the user needs to repeat the above procedure again to initiate a new live broadcast by using the electronic device 101 to continue the last interrupted live broadcast, and the user watching the live broadcast also needs to enter the new live broadcast room again to continue watching, which results in poor user experience during live broadcast.

In the embodiment of the present application, the server 102 may identify whether the electronic device 101 has an abnormal interruption during the live broadcast process. If an abnormal interruption occurs, the server 102 may mark the current live broadcast as a playable state. Subsequently, if the server 102 receives a user continuous broadcast instruction sent by the electronic device 101, the server 102 may query that the corresponding live broadcast is in a continuous broadcast state, and then continue to use the original live broadcast room ID to interact with the electronic device 101, thereby completing the breakpoint continuous broadcast function. Therefore, the user initiating the live broadcast can continue to complete the abnormally interrupted live broadcast in the original live broadcast room, and the user watching the live broadcast can also continue to watch the continuous live broadcast in the original live broadcast room, so that the use experience of the user initiating the live broadcast and the user watching the live broadcast is improved.

Optionally, in this embodiment of the application, when abnormal interruption occurs and the server 102 marks the live broadcast as a continuous broadcast state, the server 102 performs the following operation to create a memory area in advance, which is used as a cache area for storing the cached video, and in the process of playing the live broadcast, obtains video data that is not checked by the user due to the abnormal interruption and stores the video data in the cache area; after receiving a user live broadcast resuming instruction sent by the electronic device 101, the server 102 pushes the instruction to the user to select to preferentially view the cached video in the cache area or to continue to use the original live broadcast room ID to interact with the electronic device 101, thereby completing the breakpoint resuming function.

Specifically, in order to improve the data processing efficiency and avoid the waste of the cache space, a temporary storage area is partitioned in the cache area and is used for temporarily storing the cache data. And preferentially storing the cache data into the temporary storage area, and continuously storing the cache data in the temporary storage area.

Specifically, all the cache data in the temporary storage area are compressed and then stored into the cache area as a whole, the cache data in the temporary storage area can be emptied, and then new cache data continues to be received.

Specifically, let X be the size of the video data packet to be cached; by inverse X of packet size^-1To measure the space occupied by the data packet and the consumption used in data replication. Time _ f is the Time of the last access to the data; time _ n is the current Time, and the number of accesses in the unit Time of future is predicted by the reciprocal of the difference between the two, namely: (Time _ f-Time _ n)^-1；

Time _ c is the creation Time of the data packet; calculating the data creation time as follows: time _ c-Time _ n;

time _ m is the latest data update Time, and Time _ c ≠ Time _ a;

the total number of times of storage is:

if the Time of the Time _ m is the same as the Time of the Time _ f, not caching;

in summary, the class coefficient of the target packet is calculated by the following formula:

a level threshold Q1 is preset, the obtained value is compared with a threshold, and if: q1< Q, buffering data in the temporary storage area; q1 ≧ Q buffers the data in the buffer.

For convenience of description, the user who initiates the live broadcast may be called a main broadcast, and the user who watches the live broadcast may be called a live broadcast user (or fan, etc.).

In some embodiments, an application with a live function may be installed in an electronic device such as a mobile phone, and may be subsequently referred to as a live APP. Before initiating the live broadcast, the anchor can use the live broadcast APP to publish a live broadcast preview so as to attract more live broadcast users to pay attention to or reserve the live broadcast to be initiated subsequently.

Illustratively, for example, a live broadcast APP on a mobile phone is used by a anchor to publish a live broadcast preview, as shown in fig. 3, an embodiment of the present application provides a method for publishing a live broadcast preview, where the method includes:

s301, the mobile phone displays a first setting interface for releasing the live preview.

Illustratively, an entry for publishing live preview can be set in the live APP. For example, when the mobile phone runs a live APP, a preview release button can be displayed in a display interface of the live APP. If the anchor clicks the preview issue button, the mobile phone may display a first setup interface 401 for issuing the live preview, as shown in fig. 4.

In some embodiments, as also shown in fig. 4, one or more input options may be included in the first settings interface 401, including a live title 401a, a live time 401b, a cover page 401c, and a live profile 401 d. The input options can include necessary input options and optional input options, and the anchor can manually input the input options to complete the input of the forecast content.

S302, the mobile phone receives the forecast content input by the anchor in the first setting interface.

Still taking the example of the first setting interface 401, after the mobile phone displays the first setting interface 401 for publishing the live preview, the anchor may input one or more input options such as a live title 401a, a live time 401b, a front cover 401c, and a live summary 401d in the first setting interface 401. The mobile phone may use the specific content of each input option input in the first setting interface 401 by the anchor as the preview content of the live broadcast.

For example, when the mobile phone detects that the anchor inputs any one of the input options in the first setting interface 401, it may detect whether all the input options to be filled are filled in real time. If all necessary input options are filled in completely, the mobile phone can set a release button 404 of the live announcement in the first setting interface 401 to be in an interactive state; otherwise, the mobile phone may set the publish button 404 of the live preview in the first setting interface 401 to a non-interactive state.

For example, if it is detected that the anchor has not yet filled out the content in cover 401c, the cell phone may display post button 404 in gray, at which point the cell phone will not respond to the clicking action of the anchor if the anchor clicks on post button 404. If it is detected that the anchor completes all the live broadcast title 401a, the live broadcast time 401b, and the cover page 401c, the mobile phone may display the release button 404 in red, and at this time, if the anchor clicks the release button 404, the mobile phone may continue to execute the following step S303 to release the live broadcast preview of the live broadcast.

In addition, when the mobile phone detects that the anchor inputs the live broadcast time 401b in the first setting interface 401, it can also detect whether the live broadcast time input by the anchor is legal. For example, the current system time is: 2021/10/12, 16:10, if the live time 401b input by the anchor is 2021/10/12, 10:10, the mobile phone can prompt that the live time currently input by the anchor is illegal, i.e. when the live time input by the anchor is earlier than the system time, the mobile phone can prompt that the live time currently input by the anchor is illegal.

And S303, the mobile phone sends the forecast content to a server.

Still taking the example of the first setting interface 401 as described above, after the anchor completes the input of the preview content in the first setting interface 401, the posting button 404 in the first setting interface 401 may be clicked. Furthermore, the mobile phone can respond to the operation of clicking the release button 404 by the anchor, and send the preview content input by the anchor to the server by carrying the preview content in a preview request, where the preview request is used to request the server to release the preview content.

S304, the server publishes the forecast content to a social platform.

After receiving the forecast request sent by the mobile phone, the server can store the forecast content carried in the forecast request in a preset database for maintenance. And the server can publish the forecast content to a social platform of the live APP. For example, the server may publish the preview content 501 input by the anchor in the form of feed stream in "cattle pen" of the live APP. Thus, as shown in fig. 5, other users can see the preview content 501 when browsing "cattle pen", thereby improving the popularization capability of live broadcasting.

In some embodiments, as also shown in fig. 5, after the server publishes the preview content 501 in "cowboy" of the live APP, the corresponding electronic device may also be instructed to display a reservation button 502 when the other users browse "cowboy". If the live user wants to watch the live of the preview in the preview content 501, the reservation button 502 can be clicked. For example, after detecting that the live user a clicks the reservation button 502, the electronic device may send a subscription request to the server, and trigger the server to establish a binding relationship between the live user a and the preview content 501. Subsequently, when the live broadcast of the preview in the preview content 501 starts, the server may remind the live broadcast user a to watch the live broadcast according to the established binding relationship.

S305, the server sends a response message of successful release of the live preview to the mobile phone.

After the server successfully releases the preview content to the social platform, the server can send a response message that the live preview is successfully released to the mobile phone of the anchor, so that the mobile phone can know that the live preview is successfully released. Illustratively, the response message sent by the server may include a trailer ID corresponding to the live trailer.

In some embodiments, as shown in fig. 6, after receiving a response message that a live preview is successfully published, the mobile phone may jump to a management page 601 of the live preview, and display a prompt message 602 that the live preview is successfully published on the management page 601, so that the anchor knows that the live preview is successfully published.

In some embodiments, as also shown in fig. 6, a management page 601 of the live trailer may also include a management list 603 of published live trailers. The anchor can perform management operations such as modification, deletion and the like on the published live preview in the management list 603.

Illustratively, a live broadcast APP on a mobile phone is still used by a host to publish a live broadcast preview example, as shown in fig. 7, an embodiment of the present application provides a management method for a live broadcast preview, where the method includes:

s701, displaying a management page of the live broadcast preview by the mobile phone.

As shown in fig. 6, after a live preview is successfully published, the handset can automatically jump to the management page 601 of the live preview. The management page 601 includes a management list 603 of one or more live previews that have been published. The anchor can perform management operations such as deletion, modification and the like on the published live preview in the management list 603. Of course, the anchor may enter the management page of the live preview through other entries, which is not limited in this embodiment of the application.

S702, responding to the modification operation of the main broadcast to the first direct broadcast advance notice input in the management page, the mobile phone obtains advance notice content of the first direct broadcast advance notice from the server.

As also shown in fig. 6, the first live preview 604 that has been published may be included in the administrative list 603 of live previews. When the anchor needs to modify the trailer content of the first follow-up trailer 604, a modify button 605 associated with the first follow-up trailer 604 in the management page 601 may be clicked.

If it is detected that the anchor clicks the modify button 605, which indicates that the anchor inputs a modification operation to the first on-air preview 604, the handset may request to obtain preview content corresponding to the first on-air preview 604 from the server. For example, the mobile phone may carry the trailer ID of the first direct-broadcast trailer 604 in the modification request and send the modification request to the server, and the server may search the corresponding trailer content, that is, the trailer content (e.g., a live title, a cover page, etc.) of the first direct-broadcast trailer 604 in a preset database according to the trailer ID of the first direct-broadcast trailer 604. In turn, the server can send the preview content of the first direct preview 604 to the handset.

In some embodiments, after acquiring the modification request sent by the mobile phone, the server may further determine whether the first on-air preview 604 allows modification. For example, the server may determine whether modification of the first direct broadcast trailer 604 is allowed based on the current system time and the live time set in the first direct broadcast trailer 604. If the current system time is earlier than the live time set in the first live preview 604, the server may determine that the first live preview 604 is allowed to be modified, and then carry an identification of the allowed modification in a preset field (e.g., an announce _ modifying _ status field). Accordingly, if the current system time is later than the live time set in the first live preview 604, the server may determine that the first live preview 604 is not allowed to be modified, and then carry an identification of not allowing modification in a preset field (e.g., an announce _ modifiable _ status field).

In this way, after obtaining the preview content of the first direct-view preview 604 from the server, the mobile phone can determine whether to currently allow the first direct-view preview 604 to be modified according to the identifier carried in the announce _ modifying _ status field.

If the handset determines that the modification of the first on-air preview is not currently allowed 604, the handset may display a prompt message to the anchor indicating that the modification failed. Or, the handset may further set the modification button 605 of the first live announcement 604 to be in an non-interactive state or hide the modification button 605, which is not limited in this embodiment of the present application.

Accordingly, if the handset determines that the modification of the first on-air preview 604 is currently allowed, the following step S703 may be continuously performed.

And S703, the mobile phone displays and modifies a second setting interface of the first direct broadcast preview according to the preview content of the first direct broadcast preview.

Still taking the example of modifying the first direct broadcast announcement 604, after the mobile phone acquires the announcement content of the first direct broadcast announcement 604 from the server, the second setting interface 801 for modifying the first direct broadcast announcement 604 may be displayed according to the announcement content of the first direct broadcast announcement 604. As shown in fig. 8, the second setting interface 801 is similar to the first setting interface for publishing the first live preview 604, and the second setting interface 801 may also include one or more input options such as a live title 801a, a live time 801b, a front cover 801c, and a live summary 801 d. In contrast, the user can re-edit the input options already filled in the second setting interface 801 according to the preview contents of the first follow-up preview 604.

S704, the mobile phone receives the modification operation of the anchor on the forecast content in the second setting interface, and the modified first direct-broadcast forecast is obtained.

Similarly to step S302, in step S704, the handset may receive a modification operation of the preview content of the first on-air preview 604 by the anchor in the second setting interface 801. For example, the anchor may re-edit the trailer content, such as the live title, live time, cover page, or live profile, of the first live trailer 604. The handset can take the preview content entered by the anchor in the second setup interface 801 as the modified first on-air preview 604.

S705, the mobile phone sends the modified first direct broadcast preview to a server.

As also shown in fig. 8, a posting button 802 may also be provided in the second setting interface 801. After the anchor modifies the trailer content of the first follow-up trailer 604 in the second setup interface 801, the post button 802 may be clicked. At this time, the mobile phone may respond to the operation of clicking the release button 802 by the anchor, and send the announcement content of the modified first on-air announcement 604 in the second setting interface 801 to the server. Further, the server may update the preview content of the first live preview 604 in a predetermined database, thereby completing the modification process of the live preview.

Optionally, after the server finishes updating the preview content of the first live preview 604, a response message of successful modification may be sent to the mobile phone, so that the mobile phone knows that the modification of the live preview is successful. At this time, the mobile phone may further display a prompt message that the first live announcement 604 is successfully modified, so that the anchor knows that the live announcement is successfully modified.

In other embodiments, after the mobile phone displays a management page of the live preview (e.g., the management page 601), in addition to modifying the published live preview, the anchor may delete the published live preview from the management list 603 of the management page 601. The method of deleting the published live preview can be seen in steps S706-S707 described below.

S706, in response to the deleting operation input by the anchor to the first direct broadcast preview in the management page, the mobile phone sends a deleting request of the first direct broadcast preview to the server.

Still taking the example of the first follow-up 604 within the management list 603 in fig. 6, when the anchor wishes to delete the first follow-up 604 that has been posted, a delete button 606 associated with the first follow-up 604 in the management page 601 may be clicked.

If it is detected that the anchor clicks the delete button 606, indicating that the anchor inputs a delete operation to the first on-air preview 604, the handset may send a delete request for the first on-air preview 604 to the server. For example, the handset may send the trailer ID of the first direct broadcast trailer 604 to the server with the delete request.

And S707, responding to the deletion request, and deleting the first direct broadcast preview by the server.

After receiving the deletion request of the first live announcement 604 sent by the mobile phone, the server may delete the announcement content of the corresponding first live announcement 604 in the preset database according to the announcement ID in the deletion request, thereby completing the deletion process of the live announcement.

Optionally, after deleting the preview content of the first live preview 604, the server may also send a response message indicating that the deletion is successful to the mobile phone, so that the mobile phone knows that the deletion of the live preview is successful. At this time, the mobile phone may further display a prompt message that the deletion of the first live announcement 604 is successful, so that the anchor knows that the deletion of the live announcement is successful.

Since the server deletes the first live announcement 604 in the preset database, the subsequent anchor does not acquire the related content of the first live announcement 604 any more when logging in the live APP on the mobile phone and other devices.

In some embodiments, a live broadcast (which may also be referred to as a video live broadcast) may be initiated using a live broadcast function of a live broadcast APP, regardless of whether the anchor publishes a live broadcast preview on the live broadcast APP. Illustratively, a live APP on a mobile phone is used by a anchor to initiate a live broadcast, as shown in fig. 9, an embodiment of the present application provides a video live broadcast method, where the method includes:

and S901, displaying a third setting interface for initiating live broadcast by the mobile phone.

Illustratively, the anchor may initiate a live broadcast from a published live feed (e.g., the administrative list 603 described above). For example, a live launch button 607 of the first live preview 604 is provided in the management list 603 in fig. 6. When the anchor wants to initiate a live broadcast corresponding to the first live preview 604, the live broadcast initiation button 607 can be clicked. That is, the anchor may start live with a live preview as the portal that initiated the live. Alternatively, the anchor may initiate the live broadcast through another portal (for example, a live broadcast button in the homepage, etc.), and this is not limited in this embodiment of the application.

For example, when the anchor clicks the live broadcast initiation button 607 of the first live broadcast announcement 604, the mobile phone may obtain announcement content (e.g., a live broadcast title, a cover page, etc.) of the first live broadcast announcement 604 from the server after detecting that the anchor clicks the live broadcast initiation button 607. Further, as shown in fig. 10, the mobile phone may display a third setting interface 1001 for initiating a live broadcast according to the preview content of the first live broadcast preview 604. The third setting interface 1001 may include the same options as the preview content, such as a live title, a cover page, and the like. The handset may automatically populate these options in accordance with the third setup interface 1001. The anchor may also modify these options manually in the third setting interface 1001, which is not limited in any way by the embodiment of the present application.

As shown in fig. 10, the third setting interface 1001 for initiating live broadcast may further set a parameter related to the live broadcast, for example, the live broadcast mode is a horizontal screen mode or a vertical screen mode.

It should be noted that after the mobile phone obtains the advance notice content of the first live broadcast advance notice 604, it can also determine whether to allow the current live broadcast to be initiated according to the current system time. For example, if the current system time is earlier than the live broadcast time in the preview content, the handset may determine that the present live broadcast is allowed to be initiated, and proceed to step S902 described below. If the current system time is later than the live broadcast time in the forecast content, the mobile phone can determine that the live broadcast is not allowed to be initiated, and further displays a prompt message that the live broadcast is failed to be initiated.

And S902, the mobile phone sends the live broadcast information of the live broadcast to the server according to the setting of the anchor broadcast in the third setting interface.

Still taking the example of the third setting interface 1001 for initiating live broadcasting, after the anchor has set the relevant parameters of the live broadcasting in the third setting interface 1001, the anchor can click the live broadcasting button 1002 to start live broadcasting. Then, after detecting that the anchor clicks the live button 1002, the mobile phone can carry live information of the live broadcast in a live broadcast request and send the live broadcast request to the server. The live broadcast information may include a live broadcast title, a cover page, a live broadcast mode, and the like set in the third setting interface 1001 by the anchor broadcast, and may further include a type (for example, a mobile phone), a model, a time when the live broadcast starts (for example, a time when the live broadcast button 1002 is clicked), a live broadcast stream address, and the like of the client.

And S903, the mobile phone acquires the live broadcast room ID corresponding to the live broadcast from the server.

After the server acquires the live broadcast request carrying live broadcast information, the server can distribute a corresponding live broadcast room ID for the live broadcast, so that the corresponding relation between the live broadcast room ID and the live broadcast information is established. The subsequent server can use the live broadcast room ID to maintain the live broadcast information of the live broadcast for the index. And the server can send the live broadcast room ID allocated for the live broadcast to the client (namely the mobile phone) so that the mobile phone can acquire the live broadcast room ID corresponding to the live broadcast.

And S904, the mobile phone starts live broadcast by using the live broadcast room ID.

After the mobile phone acquires the live broadcasting room ID of the live broadcasting, the live broadcasting can be started by using the live broadcasting room ID. At the moment, the mobile phone can jump to a live interface to display the currently recorded live content in real time. For example, a mobile phone may send video data recorded in real time (i.e., live content) to a server, and the server distributes the live content in real time on a network platform provided by a live APP.

S905, the server binds the live broadcast room ID with the corresponding live broadcast preview.

In the embodiment of the application, after the server allocates the corresponding live broadcast room ID for the live broadcast, the live broadcast and the corresponding live broadcast preview can be bound by using the live broadcast room ID. For example, the server may establish a correspondence between a live room ID and a corresponding trailer ID.

S906, the server sends live broadcast push information to the live broadcast user reserving the live broadcast preview.

Since one or more live users may have subscribed to the live broadcast when the live broadcast preview (e.g., the first live broadcast preview 604) is published, after the live broadcast is bound to the corresponding live broadcast preview, the server may send a live broadcast push message indicating that the live broadcast subscribed by the relevant live broadcast user has started to the live broadcast user who has subscribed to the live broadcast preview.

In some embodiments, after the server allocates the corresponding live broadcast room ID for the live broadcast, the server may further instruct the mobile phone to delete the corresponding live broadcast preview, thereby ensuring the real-time performance of the live broadcast preview in the live broadcast preview list.

In other embodiments, the handset may adopt a communication method of a heartbeat mechanism to ensure the effectiveness of communication in the process of live broadcasting by using the live broadcasting room ID allocated by the server. As shown in fig. 11, after the mobile phone starts live broadcasting, heartbeat data packets may be periodically sent to the server. The server can reply the corresponding heartbeat response after receiving the heartbeat data packet sent by the mobile phone.

When abnormity occurs in the live broadcast process (such as network disconnection, abnormal exit of live broadcast APP and the like), the mobile phone exits from the live broadcast, and the mobile phone cannot send a heartbeat data packet to the server. Then, if the server does not receive the heartbeat data packet sent by the mobile phone within the first preset time (for example, 15s), the server may determine that the live broadcast is abnormal. At this time, the server can mark the ID of the live broadcast room of the current live broadcast as a continuous broadcast state so as to continuously broadcast the live broadcast. Correspondingly, if the server does not receive the heartbeat data packet sent by the mobile phone within a longer time, for example, within a second preset time (for example, 600s), the server may determine that the live broadcast does not need to be maintained, and at this time, the mobile phone may end the live broadcast. For example, the mobile phone may release the live broadcast room ID of the current live broadcast, so that the live broadcast room ID may be allocated to the live broadcast initiated by other users.

In the embodiment of the present application, as shown in fig. 11, when the live broadcast is abnormally interrupted, the live broadcast can be resumed according to the following live broadcast method, so as to implement the function of breakpoint continuous broadcast.

S1101, the mobile phone (or other client) sends a live broadcast request to the server.

When the mobile phone quits live broadcasting due to abnormality in the live broadcasting process, the anchor can continue to use the mobile phone or other clients (such as a tablet computer, a PC and the like) to log in the live broadcasting APP again. And the anchor logs in the live APP example by using the mobile phone again, and after the anchor enters the live APP, if the anchor input is detected to initiate the live operation, the mobile phone can send a live request to the server. For example, the live broadcast request may include information such as an account or a user name that the anchor logs in the live broadcast APP this time.

And S1102, the server judges whether the live broadcast is in a continuous broadcast state or not according to the live broadcast request.

After receiving a live broadcast request sent by a mobile phone (or other client), the server can inquire whether live broadcast in a continuous broadcast state exists under the account number.

For example, if the server does not receive a heartbeat packet corresponding to a certain live broadcast time ID within a certain time period, the server may mark the live broadcast time ID under the corresponding account as a continuous broadcast state, that is, the live broadcast corresponding to the live broadcast time ID is in the continuous broadcast state. At this time, the server may continue to perform step S1103 described below.

Correspondingly, if the server inquires that live broadcast in a continuous broadcast state does not exist under the account sending the live broadcast request, the server can instruct the mobile phone to start new live broadcast according to the flow of initiating new live broadcast.

And S1103, if the live broadcast is in a continuous broadcast state, the server indicates the mobile phone (or other client) to display a continuous broadcast prompt.

If the server inquires that the account number of the anchor log-in exists the live broadcast which can be continuously played, the server can send the live broadcast room ID marked as the continuous broadcast state to the mobile phone, at this time, as shown in fig. 12, the mobile phone can display a dialog box 1201, and a user is prompted in the dialog box 1201 that the user can continuously play the live broadcast which is abnormally quitted last time. The content in the dialog 1201 may be referred to as a resume prompt. Of course, the mobile phone may also display the continuous playing prompt in a voice mode, an animation mode, and the like, which is not limited in this embodiment of the present application.

And S1104, if the anchor selects to resume the last abnormal quit live broadcast, the mobile phone (or other client) acquires resume information of the last live broadcast from the server.

Illustratively, the dialog 1201 described above may include a button 1202 to continue the live broadcast and a button 1203 to initiate a new live broadcast. If it is detected that the anchor clicks the button 1202 for continuing the live broadcast, which indicates that the anchor selects to resume the live broadcast which is abnormally exited last time, the mobile phone can send a resume request to the server, wherein the resume request includes the live broadcast room ID of the live broadcast which is abnormally exited last time, so as to request the server to resume the live broadcast.

Furthermore, after receiving the resume request, the server can send resume information corresponding to the live broadcast room ID in the resume request to the mobile phone. The resume information may include one or more of a start time of the live broadcast of the last abnormal exit, a time of the live broadcast, a client type, and a live broadcast mode (e.g., a landscape mode or a portrait mode).

For example, since resume information of a certain live broadcast is generally a subset of live broadcast information of the certain live broadcast, the server may send the live broadcast information corresponding to the live broadcast room ID to a client (e.g., a mobile phone) currently logging in the live broadcast APP, and then the mobile phone obtains resume information required for the resume from the live broadcast information. Or, the server may also directly screen resume information required by the resume from the live broadcast information, and then send the resume information to the mobile phone, which is not limited in this embodiment of the application.

And S1105, the mobile phone (or other client) continues live broadcast by using the live broadcast room ID according to the continuous broadcast information.

After the client side of the continuous playing obtains the continuous playing information of the live broadcast which is abnormally quitted last time, the client side can continue to use the ID of the live broadcast room before the abnormal quitting to carry out the live broadcast according to the continuous playing information, and the continuous playing function is realized.

Specifically, the resume information records the type of the client when the last live broadcast exits abnormally. If the type of the client in the resume information is a mobile terminal (e.g., a mobile phone) and the type of the client in the resume information is still the mobile terminal (e.g., the mobile phone), the mobile phone can continue to use parameters such as a live mode (e.g., a horizontal screen mode or a vertical screen mode) in the resume information for resuming.

Or, if the type of the client in the resume information is a non-mobile terminal such as a PC, and the type of the client in the resume is a mobile terminal (for example, a mobile phone), the mobile phone may default to resume in the live mode of the landscape mode.

Or, if the type of the client in the resume information is a mobile terminal (e.g., a mobile phone) and the type of the client in the resume is a non-mobile terminal (e.g., a PC), the PC may prompt the anchor to select a horizontal screen or vertical screen live mode again, and then resume the play according to the live mode selected by the anchor.

Therefore, even if the type of the client which resumes the live broadcasting is different from the type of the client which abnormally exits from the last live broadcasting, the client which resumes the live broadcasting can continue the live broadcasting by using the original live broadcasting room ID according to the resuming information without replacing the live broadcasting room, and the use experience of the main broadcast during the live broadcasting is improved. Meanwhile, a live broadcast user watching the live broadcast can also continue to watch the continuous live broadcast in the original live broadcast room, so that the use experience of the live broadcast user is improved.

While method embodiments of the present application are described in detail above in conjunction with fig. 1-12, device embodiments of the present application will be described in detail below with the understanding that device embodiments correspond to method embodiments, and similar descriptions may be had by reference to method embodiments.

Fig. 13 shows a schematic block diagram of a terminal provided in an embodiment of the present application. As shown in fig. 13, the terminal may include:

a sending unit 1301, configured to send a live broadcast request to a server when receiving an operation of initiating a live broadcast by a host input; an obtaining unit 1302, configured to receive continuous playing information of a target live broadcast sent by the server; and a live broadcasting unit 1303 configured to continue broadcasting the target live broadcast according to the resume information.

In some embodiments, the live broadcast unit 1303 is specifically configured to: when the client type in the continuous playing information is a mobile terminal and the client type of the first terminal is also the mobile terminal, continuing playing the target live broadcast according to a live broadcast mode set in the continuous playing information; when the client type in the continuous playing information is a non-mobile terminal and the client type of the first terminal is a mobile terminal, continuously playing the target live broadcast according to a horizontal screen mode; and when the client type in the continuous playing information is a mobile terminal and the client type of the first terminal is a non-mobile terminal, prompting the anchor to select a live mode, and continuing playing the target live broadcast according to the live mode selected by the anchor.

In some embodiments, the terminal further includes a display unit 1304, configured to display a resume prompt, where the resume prompt is used to prompt a user whether to resume the live broadcast that was last abnormally exited.

In some embodiments, the display unit 1304 is further for: displaying a first setting interface of a first live announcement; the obtaining unit 1302 is further configured to: receiving forecast content input by a main broadcast in the first setting interface, wherein the forecast content comprises one or more items of a live broadcast title, live broadcast time, a front cover and a live broadcast brief introduction; the sending unit 1301 is further configured to: and carrying the forecast content in a forecast request and sending the forecast content to the server.

In some embodiments, the display unit 1304 is further for: and jumping to a management page of the live preview, wherein the management page comprises a management list of the released one or more live previews.

In some embodiments, the display unit 1304 is further for: when receiving the modification operation of a main broadcast on the management page to the input of a first direct broadcast preview, displaying a second setting interface of the first direct broadcast preview, wherein the second setting interface comprises the preview content of the filled first direct broadcast preview; the sending unit 1301 is further configured to: and after receiving the modification input by the anchor on the second setting interface, sending a modification request to the server, wherein the modification request comprises a modified first direct broadcast forecast.

In some embodiments, the sending unit 1301 is further configured to: and when receiving a deletion operation input by a main broadcasting on the management page to the first live announcement, sending a deletion request to the server.

In some embodiments, the sending unit 1301 is further configured to: and when receiving a live broadcast initiating operation input by a main broadcast on the management page to the first live broadcast preview, sending a live broadcast request to a server.

Fig. 14 shows a schematic block diagram of a server provided in an embodiment of the present application. As shown in fig. 14, the server includes:

an acquisition unit 1401 configured to: acquiring a live broadcast request sent by a first terminal by using a first account; a processing unit 1402 configured to: determining that target live broadcast with a continuous broadcast state exists under the first account; a sending unit 1403, configured to: and sending continuous playing information of the target live broadcast to the first terminal, so that the first terminal continues playing the target live broadcast according to the continuous playing information.

In some embodiments, the processing unit 1402 is specifically configured to: and when the server does not receive the heartbeat data packet corresponding to the target live broadcast within the preset time, determining that the target live broadcast is in a continuous broadcast state.

In some embodiments, the processing unit 1402 is further configured to: and indicating the first terminal to display a continuous playing prompt which is used for prompting whether the anchor broadcast continues the target live broadcast or not.

In some embodiments, the processing unit 1402 is further configured to: and when the live broadcast in the continuous broadcast state does not exist under the first account, distributing a corresponding live broadcast room ID for the live broadcast, and sending the live broadcast room ID to the first terminal.

In some embodiments, the processing unit 1402 is further configured to: binding the live broadcast room ID with a corresponding live broadcast forecast; and sending live broadcast push messages to live broadcast users who reserve the live broadcast preview.

In some embodiments, the obtaining unit 1401 is further configured to: receiving a forecast request sent by a second terminal, wherein the forecast request comprises forecast content of a first direct-broadcast forecast, and the second terminal is the same as or different from the first terminal; the processing unit 1402 is further configured to: and publishing the forecast content of the first direct broadcast forecast to the social platform.

In some embodiments, the obtaining unit 1401 is further configured to: receiving a forecast modification request of the first direct broadcast forecast sent by the second terminal; the transmission unit 1401 is also configured to: responding to the forecast modification request, and sending forecast content of the first direct-broadcast forecast to the second terminal; the processing unit 1402 is further configured to: and after receiving the modified first direct broadcast preview sent by the second terminal, updating preview content of the first direct broadcast preview.

In some embodiments, the obtaining unit 1401 is further configured to: receiving a deletion request of the first direct broadcast preview sent by the second terminal; the processing unit 1402 is further configured to: and deleting the forecast content of the first direct broadcast forecast in response to the deletion request.

The terminal and the server provided in the above embodiments may execute the technical solutions of the above method embodiments, and the implementation principles and technical effects are similar, which are not described herein again.

Fig. 15 is a schematic structural diagram of a terminal according to an embodiment of the present application. The terminal device shown in fig. 15 includes a processor 1510, and the processor 1510 can call and run a computer program from a memory to implement the method in the embodiment of the present application.

Optionally, as shown in fig. 15, the terminal device may further include a memory 1520. From the memory 1520, the processor 1510 can call and execute a computer program to implement the method in the embodiment of the present application.

The memory 1520 may be a separate device from the processor 1510 or may be integrated into the processor 1510.

Optionally, as shown in fig. 15, the terminal device may further include a transceiver 1530, and the processor 1510 may control the transceiver 1530 to communicate with other devices, and specifically, may transmit information or data to other devices or receive information or data transmitted by other devices.

The transceiver 1530 may include a transmitter and a receiver, among others. The transceiver 1530 may further include one or more antennas.

Optionally, as shown in fig. 15, the terminal device may further include a display 1540, and the display 1540 may be used to output text, pictures, videos, and the like to the user.

Fig. 16 is a schematic structural diagram of a server according to an embodiment of the present application. The server shown in fig. 16 includes a processor 1610, and the processor 1610 can call and execute a computer program from a memory to implement the method in the embodiment of the present application.

Optionally, as shown in fig. 16, the server may further include a memory 1620. From the memory 1620, the processor 1610 can call and run a computer program to implement the method in the embodiment of the present application.

The memory 1620 may be a separate device from the processor 1610, or may be integrated into the processor 1610.

Optionally, as shown in fig. 16, the server may further include a transceiver 1630, and the processor 1610 may control the transceiver 1630 to communicate with other devices, and specifically, may transmit information or data to other devices or receive information or data transmitted by other devices.

The transceiver 1630 may include a transmitter and a receiver, among others. The transceiver 1630 may further include an antenna, which may be one or more in number.

The terminal device and the server provided in the above embodiments may execute the technical solutions of the above method embodiments, and the implementation principles and technical effects are similar, which are not described herein again.

It should be understood that the processor of the embodiments of the present application may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method embodiments may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software.

It will be appreciated that the memory in the embodiments of the subject application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The embodiment of the application also provides a computer readable storage medium for storing the computer program.

Optionally, the computer-readable storage medium may be applied to a terminal device or a server in the embodiment of the present application, and the computer program enables a computer to execute corresponding processes in each method in the embodiment of the present application, which is not described herein again for brevity.

Embodiments of the present application also provide a computer program product comprising computer program instructions.

Optionally, the computer program product may be applied to a terminal device or a server in the embodiment of the present application, and the computer program instructions enable a computer to execute corresponding processes in each method in the embodiment of the present application, which is not described herein again for brevity.

The embodiment of the application also provides a computer program.

Optionally, the computer program may be applied to the terminal device or the server in the embodiment of the present application, and when the computer program runs on a computer, the computer is enabled to execute corresponding processes in each method in the embodiment of the present application, and for brevity, details are not described here again.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for live video, comprising:

the server acquires a live broadcast request sent by a first terminal by using a first account;

the server determines that target live broadcast with a continuous broadcast state exists under the first account;

and the server sends the continuous playing information of the target live broadcast to the first terminal, so that the first terminal continues playing the target live broadcast according to the continuous playing information.

2. The method of claim 1, wherein the server determines that a target live broadcast with a continuous broadcast status exists in the first account, and comprises:

and when the server does not receive the heartbeat data packet corresponding to the target live broadcast within the preset time, the server determines that the target live broadcast is in a continuous broadcast state.

3. The method of claim 1, wherein after the server determines that there is a target live broadcast in a playable state under the first account, the method further comprises:

and the server indicates the first terminal to display a continuous playing prompt which is used for prompting whether the anchor broadcast continues the target live broadcast or not.

4. The method of claim 3, wherein the server sends the resume information of the target live broadcast to the first terminal, and wherein the sending comprises:

and after the server receives a continuous playing request sent by the first terminal, the server sends continuous playing information of the target live broadcast to the first terminal.

5. The method according to any one of claims 1 to 4, wherein after the server obtains the live broadcast request sent by the first terminal using the first account, the method further comprises:

and when the live broadcast in the continuous broadcast state does not exist under the first account, the server allocates a corresponding live broadcast room ID for the live broadcast, and sends the live broadcast room ID to the first terminal.

6. The method according to any one of claims 1-5, further comprising:

the server receives a forecast request sent by a second terminal, wherein the forecast request comprises forecast content of a first direct-broadcast forecast, and the second terminal is the same as or different from the first terminal;

and the server publishes the forecast content of the first direct broadcast forecast to a social platform.

7. The method according to claim 6, wherein after the server receives the announcement request sent by the second terminal, the method further comprises:

the server receives a forecast modification request of the first direct broadcast forecast sent by the second terminal;

responding to the forecast modification request, and sending forecast content of the first direct-broadcast forecast to the second terminal by the server;

and after receiving the modified first direct broadcast preview sent by the second terminal, the server updates preview content of the first direct broadcast preview.

8. A method for live video, comprising:

when a first terminal receives an operation of initiating live broadcast by a main broadcast input, the first terminal sends a live broadcast request to a server;

the first terminal receives continuous broadcasting information of target live broadcasting sent by the server;

and the first terminal resumes the target live broadcast according to the resuming information.

9. The method of claim 8, wherein the resuming the target live broadcast by the first terminal according to the resume information comprises:

when the client type in the continuous playing information is a mobile terminal and the client type of the first terminal is also the mobile terminal, the first terminal continues playing the target live broadcast according to a live broadcast mode set in the continuous playing information;

when the client type in the continuous playing information is a non-mobile terminal and the client type of the first terminal is a mobile terminal, the first terminal continuously plays the target live broadcast according to a horizontal screen mode;

and when the client type in the continuous playing information is a mobile terminal and the client type of the first terminal is a non-mobile terminal, the first terminal prompts the anchor to select a live mode and continues playing the target live broadcast according to the live mode selected by the anchor.

10. The method of claim 8, wherein before the first terminal sends the live request to the server, the method further comprises:

the first terminal displays a first setting interface of a first direct-broadcast preview;

the first terminal receives forecast content input by a main broadcast in the first setting interface, wherein the forecast content comprises one or more of a live broadcast title, live broadcast time, a cover page and a live broadcast introduction;

and the first terminal carries the forecast content in a forecast request and sends the forecast request to the server.

11. The method according to claim 10, wherein after the first terminal sends the forecast content to the server in a forecast request, the method further comprises:

and the first terminal jumps to a management page of the live preview, wherein the management page comprises a management list of one or more released live previews.

12. A server, comprising: a processor and a memory for storing a computer program, the processor for invoking and executing the computer program stored in the memory to cause the server to perform the method of any one of claims 1-7.

13. A terminal, comprising: a processor and a memory for storing a computer program, the processor being configured to invoke and execute the computer program stored in the memory to cause the terminal to perform the method according to any of claims 8-11.

14. A computer-readable storage medium for storing a computer program which causes a computer to perform the method of any one of claims 1-7 or 8-11.