CN113613057A

CN113613057A - Play window switching method, electronic equipment and storage medium

Info

Publication number: CN113613057A
Application number: CN202110656156.5A
Authority: CN
Inventors: 宓国飞; 江斌; 朱龙
Original assignee: Hangzhou Huacheng Software Technology Co Ltd
Current assignee: Hangzhou Huacheng Software Technology Co Ltd
Priority date: 2021-06-11
Filing date: 2021-06-11
Publication date: 2021-11-05

Abstract

The application discloses a playing window switching method, electronic equipment and a storage medium. The method comprises the following steps: acquiring play data, wherein the memory address of the play data is bound with the first play window; rendering and playing the playing data by utilizing the first playing window; if a request for switching the playing window is received, removing the binding relationship between the memory address of the playing data and the first playing window, wherein the request for switching the playing window points to the second playing window; and binding the memory address of the playing data with the second playing window so as to render and play the playing data by utilizing the second playing window. By the mode, the time for switching the playing window can be reduced, and the phenomenon of black screen/skip playing can be avoided.

Description

Play window switching method, electronic equipment and storage medium

Technical Field

The present application relates to the field of streaming media playing, and in particular, to a method for switching a playing window, an electronic device, and a storage medium.

Background

When a user watches a video (playing data), there is often a need to switch a playing window (for example, there is a need to switch a playing window when a video needs to be recorded, a screen shot, a large screen is watched, and the like), that is, the video needs to be switched from a current playing window to a new playing window for rendering and playing. However, the conventional method for switching the playing window is used to switch the video from the current playing window to the new playing window, which requires a long time, and also causes a black screen/skip play phenomenon, thereby reducing user experience.

Disclosure of Invention

The application provides a play window switching method, electronic equipment and a storage medium, which can solve the problems that the existing play window switching process needs to consume long time and the phenomenon of screen blacking/skip playing can occur.

In order to solve the technical problem, the application adopts a technical scheme that: a method for switching a play window is provided. The method comprises the following steps: acquiring play data, wherein the memory address of the play data is bound with the first play window; rendering and playing the playing data by utilizing the first playing window; if a request for switching the playing window is received, removing the binding relationship between the memory address of the playing data and the first playing window, wherein the request for switching the playing window points to the second playing window; and binding the memory address of the playing data with the second playing window so as to render and play the playing data by utilizing the second playing window.

In order to solve the above technical problem, another technical solution adopted by the present application is: an electronic device is provided, which comprises a processor and a memory connected with the processor, wherein the memory stores program instructions; the processor is configured to execute the program instructions stored by the memory to implement the above-described method.

In order to solve the above technical problem, the present application adopts another technical solution: there is provided a storage medium storing program instructions that when executed enable the above method to be implemented.

Through the mode, when a user needs to switch the playing windows, the user only needs to change the binding relationship between the memory address of the playing data and the playing windows, namely, the playing windows bound with the playing handles are replaced from the original first playing windows to the second playing windows, and then the switching of the playing windows can be achieved. Compared with the existing mode, the play window switching method provided by the application can realize seamless switching of the play window, so that the required time is short, and the phenomenon of screen blacking/skip broadcasting cannot occur.

Drawings

Fig. 1 is a schematic flowchart of a first embodiment of a method for switching a play window according to the present application;

FIG. 2 is a flowchart illustrating a second implementation of the method for switching a playback window of the present application;

fig. 3 is a schematic flowchart of a third embodiment of a playing window switching method according to the present application;

fig. 4 is a schematic flowchart of a fourth embodiment of a method for switching a playing window according to the present application;

FIG. 5 is a schematic diagram of a playback window and a page on which the playback window is located;

FIG. 6 is a schematic structural diagram of an embodiment of an electronic device of the present application;

FIG. 7 is a schematic structural diagram of an embodiment of a storage medium according to the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first", "second" and "third" in this application are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implying any indication of the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of the feature. In the description of the present application, "plurality" means at least two, e.g., two, three, etc., unless explicitly specifically limited otherwise.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those skilled in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments without conflict.

The main working principle of the existing playing window switching method is as follows: acquiring play data; rendering and playing the playing data by utilizing the first playing window; if the need of switching to the second playing window for rendering and playing exists, the playing data which is originally played and rendered in the first playing window needs to be switched to the second playing window for continuing the rendering and playing.

The existing playing window switching method needs to consume long time, and a phenomenon of skip playing/screen blacking can occur, and the reason is as follows: the playing window used for rendering and playing the playing data is bound with the memory address of the playing data. In the conventional method for switching the play window, the binding relationship between the memory address of the acquired play data and the play window is fixed. This means that when a user needs to switch to the second play window, the binding relationship between the memory address of the first play window and the first play window is released, and then a new memory address is created for the play data again, and the new memory address is bound to the second play window, so that the first play window is switched to the second play window. Therefore, there is a long time consumption in the process of switching the playing window, which causes the jumping of the picture content before and after switching and the phenomenon of jumping playing/black screen.

Fig. 1 is a flowchart illustrating a first embodiment of a method for switching a play window according to the present application. It should be noted that, if the result is substantially the same, the flow sequence shown in fig. 1 is not limited in this embodiment.

As shown in fig. 1, the present embodiment may include:

s11: and acquiring the playing data.

The memory address of the playing data is bound with the first playing window.

The execution subject of this embodiment may be a terminal (user side) where the user is located. Application scenarios of the present application include, but are not limited to, entertainment scenarios and surveillance scenarios, and thus the playing data may be, but is not limited to, surveillance videos (e.g., indoor surveillance videos), entertainment videos (e.g., movies, game videos). The playing data may be real-time or non-real-time.

It can be understood that, if the memory address of the play data is bound to the first play window, it means that the play window for rendering and playing the play data is the first play window.

S12: and rendering and playing the playing data by utilizing the first playing window.

S13: and judging whether a request for switching the playing window is received.

Wherein the request for switching the playing window is directed to the second playing window.

The user can select a playing window (a second playing window) on the user-side interface to trigger the user-side to generate a request for switching the windows. The first playing window and the second playing window may be different playing windows on the same page, or may be playing windows on different pages.

If yes, go to S14.

S14: and releasing the binding relationship between the memory address of the playing data and the first playing window.

In addition, in other embodiments, after the binding relationship between the memory address of the play data and the first play window is released, the cache of the first play window may also be deleted, so that the first play window does not need to be cached in the memory all the time, and the possibility of memory overflow is reduced.

S15: and binding the memory address of the playing data with the second playing window so as to render and play the playing data by utilizing the second playing window.

Through the implementation of the embodiment, when a user needs to switch the play window, the user only needs to change the binding relationship between the memory address of the play data and the play window, that is, the play window bound to the play handle is replaced from the original first play window to the second play window, so that the play window can be switched. Compared with the existing mode, the play window switching method provided by the application can realize seamless switching of the play window, so that the required time is short, and the phenomenon of screen blacking/skip broadcasting cannot occur.

Fig. 2 is a schematic flow chart of a second implementation of the method for switching a play window according to the present application. It should be noted that, if the result is substantially the same, the flow sequence shown in fig. 2 is not limited in this embodiment. The present embodiment is a further extension of S11, and as shown in fig. 2, the present embodiment may include:

s111: and sending a pull flow request to the target equipment terminal.

The target device side may be a terminal capable of providing play data. The user can trigger the user side to send a pull stream request to the target equipment side through modes of voice, key pressing, touch and the like when in need. The following is illustrated by way of example:

in an entertainment scene, a user end can run a video playing application, and a target device end can be a terminal in butt joint with the video playing application. The user can select a video to be watched on the video playing application interface, and the video playing application can generate a pull stream request and send the pull stream request to a terminal connected with the video playing application.

The candidate device side list can be obtained in a monitoring scene, namely the candidate device side list can be displayed on a user side interface, and the candidate device side list can comprise camera devices arranged in each monitoring area; and selecting the target equipment terminal from the candidate equipment terminal list. In a specific embodiment, the target device side may be selected from the candidate device side list by the user; in another specific embodiment, the target device side may also be selected from the candidate devices according to a specific algorithm, so as to trigger the user side to generate a pull request and send the pull request to the target device side.

In other embodiments, S111 may further include, before: and determining the memory address of the playing data and the memory address of the code stream. In other words, before sending the pull request to the target device, the storage space may be allocated in advance for the code stream sent by the target device, and the storage space may be allocated in advance for the play data obtained by decoding the code stream.

S112: and receiving a code stream sent by the target equipment end in response to the stream pulling request.

The target device may compress, after receiving the pull request, the play data pointed by the pull request into a code stream and send the code stream to the user side.

S113: and decoding the code stream to obtain the playing data.

The corresponding decoding mode can be selected according to the compression mode, so as to decode the code stream to obtain the playing data.

Fig. 3 is a flowchart illustrating a third embodiment of a method for switching a play window according to the present application. It should be noted that, if the result is substantially the same, the flow sequence shown in fig. 3 is not limited in this embodiment. The present embodiment is a further extension of the first embodiment, and as shown in fig. 3, the present embodiment may include:

s21: and judging whether the memory address of the playing data is valid or not.

It can be understood that the memory address of the playing data is valid, which means that the rendering and playing operation for the playing data is currently performed normally/not stopped. In this case, there is a switching of the play window, and it makes sense to perform S22-S23 to implement the switching of the play window.

The memory address of the play data can be identified by the play handle, so that whether the memory address of the play data is valid can be judged according to the state of the play handle.

If so, executing S22-S23 (corresponding to S14-S15); if not, then S24-S25 are executed.

S22: and releasing the binding relationship between the memory address of the playing data and the first playing window.

S23: and binding the memory address of the playing data with the second playing window so as to render and play the playing data by utilizing the second playing window.

S24: and retrieving the playing data.

And binding the memory address of the newly acquired play data with the second play window.

S25: and rendering and playing the playing data by utilizing the second playing window.

For detailed descriptions of other steps in this embodiment, refer to the previous embodiment, and are not repeated here.

Fig. 4 is a flowchart illustrating a fourth method for switching a playing window according to the present application. It should be noted that, if the result is substantially the same, the flow sequence shown in fig. 4 is not limited in this embodiment. The embodiment is a further extension of the third embodiment, and the playing data is a real-time video. As shown in fig. 4, the present embodiment may include:

s31: and judging whether the memory address of the code stream is effective or not.

It can be understood that, in the case that the playing data is a real-time video, the memory address of the code stream is valid, which means that the stream pulling operation from the target device side by the current user side is not interrupted, and then the rendering playing operation on the playing data may be performed normally or not stopped at present. Therefore, it makes sense to execute S32 if the memory address of the codestream is valid.

The memory address of the code stream can be identified by the stream source handle, so that whether the memory address of the code stream is valid can be judged according to the state of the stream source handle.

If yes, go to S32 (corresponding to 21 above); if not, then S33-S34 (corresponding to S24-S25 above) are performed.

S32: and judging whether the memory address of the playing data is valid or not.

S33: and retrieving the playing data.

S34: and rendering and playing the playing data by utilizing the second playing window.

Different from the third and fourth embodiments, in other embodiments, it may be determined whether the memory address of the playing data and the memory address of the code stream are valid at the same time, and if both are valid, the steps S22-S23/S14-S15 are performed.

The following describes the play window switching method provided in the present application in detail in an example form with reference to fig. 5.

Allocating memory addresses for the code stream and the playing data in advance, and binding the memory addresses of the playing data with the first playing window;

sending a stream pulling request to a target equipment end (camera 1);

receiving a code stream sent by a target equipment terminal, and decoding the code stream to obtain playing data;

rendering and playing the playing data by using the playing window 1, wherein the left side of fig. 5 is a schematic diagram of the playing window 1 and the page 1 where the playing window is located;

receiving a click operation of a user on a playing window 1 of a page 1 to indicate that a user side is switched to a playing window 2;

responding to the click operation of the user, and judging whether the memory address of the playing data is valid or not;

if the current playing window is valid, replacing the first playing window bound with the memory address of the playing data with a second playing window, and rendering and playing the playing data by using the second playing window, wherein the right side of fig. 5 is a schematic diagram of the playing window 2 and the page 2 where the playing window is located;

if the playing data is invalid, the memory address is allocated to the code stream again, the memory address allocated to the playing data again is bound with the second playing window, the stream pulling request is sent to the target equipment end again to acquire the playing data again, and the playing data is rendered and played by using the second playing window.

Fig. 6 is a schematic structural diagram of an embodiment of an electronic device according to the present application. As shown in fig. 6, the electronic device includes a processor 41, and a memory 42 coupled to the processor 41.

Wherein the memory 42 stores program instructions for implementing the method of any of the above embodiments; processor 41 is operative to execute program instructions stored by memory 42 to implement the steps of the above-described method embodiments. The processor 41 may also be referred to as a CPU (Central Processing Unit). The processor 41 may be an integrated circuit chip having signal processing capabilities. The processor 41 may also be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. A general purpose processor may be a microprocessor or the processor 41 may be any conventional processor or the like.

FIG. 7 is a schematic structural diagram of an embodiment of a storage medium according to the present application. As shown in fig. 7, the computer readable storage medium 50 of the embodiment of the present application stores program instructions 51, and the program instructions 51 implement the method provided by the above-mentioned embodiment of the present application when executed. The program instructions 51 may form a program file stored in the computer-readable storage medium 50 in the form of a software product, so as to enable a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to execute all or part of the steps of the methods according to the embodiments of the present application. And the aforementioned computer-readable storage medium 50 includes: various media capable of storing program codes, such as a usb disk, a mobile hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, or terminal devices, such as a computer, a server, a mobile phone, and a tablet.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is merely a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit. The above embodiments are merely examples and are not intended to limit the scope of the present disclosure, and all modifications, equivalents, and flow charts using the contents of the specification and drawings of the present disclosure or those directly or indirectly applied to other related technical fields are intended to be included in the scope of the present disclosure.

Claims

1. A method for switching a play window is characterized by comprising the following steps:

acquiring play data, wherein the memory address of the play data is bound with a first play window;

rendering and playing the playing data by utilizing the first playing window;

if a request for switching the playing window is received, removing the binding relationship between the memory address of the playing data and the first playing window, wherein the request for switching the playing window points to a second playing window;

and binding the memory address of the playing data with the second playing window so as to render and play the playing data by utilizing the second playing window.

2. The method according to claim 1, further comprising, before the releasing the binding relationship between the memory address of the playback data and the first playback window:

judging whether the memory address of the playing data is valid or not;

and if the current playing window is valid, executing the step of removing the binding relationship between the memory address of the playing data and the first playing window.

3. The method according to claim 2, further comprising, after said determining whether the memory address of the playing data is valid, the step of:

if the playing data is invalid, the playing data is obtained again, wherein the memory address of the obtained playing data is bound with the second playing window;

and rendering and playing the playing data by utilizing the second playing window.

4. The method of claim 2, wherein the obtaining the playback data comprises:

sending a pull stream request to a target equipment end;

receiving a code stream sent by the target equipment end in response to the stream pulling request;

and decoding the code stream to obtain the playing data.

5. The method according to claim 4, wherein the playing data is a real-time video, and before the determining whether the memory address of the playing data is valid, the method further comprises:

judging whether the memory address of the code stream is valid;

if yes, executing the step of judging whether the memory address of the playing data is valid.

6. The method according to claim 4, before said sending the pull stream request to the target device, further comprising:

acquiring a candidate device end list;

and selecting the target equipment terminal from the candidate equipment terminal list.

7. The method according to claim 4, before said sending the pull stream request to the target device, further comprising:

and determining the memory address of the playing data and the memory address of the code stream.

8. The method according to claim 1, further comprising, after said unbinding of the play handle from the first play window:

and deleting the cache of the first playing window.

9. An electronic device comprising a processor, a memory coupled to the processor, wherein,

the memory stores program instructions;

the processor is configured to execute the program instructions stored by the memory to implement the method of any of claims 1-8.

10. A storage medium, characterized in that the storage medium stores program instructions that, when executed, implement the method of any one of claims 1-8.