Player multiplexing method, device, electronic device and storage medium

Abstract

The embodiments of the present disclosure provide a player reuse method, device, electronic device and storage medium. The method includes: when the stream pulling player meets the pool entry conditions, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread; if the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool; when a call instruction to call the player is received, the stream pulling player is called from the player reuse pool to play the audio and video stream based on the called stream pulling player. The technical solution provided by the embodiments of the present disclosure achieves the effect of global reuse of subsequent players by keeping the core resources of the stream pulling player from being released, thereby improving the program execution efficiency and stream pulling efficiency.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of multimedia technology, and in particular to a player multiplexing method, device, electronic device, and storage medium. Background Art

[0002] With the continuous development of the Internet, audio and video playback applications are covering more and more business scenarios. For example, different services such as video playback, audio playback, live broadcasting, and search are all located in different business scenario pages, which can meet the multimedia playback needs of different business scenarios within the same application.

[0003] In related technologies, to meet multimedia playback requirements in different business scenarios, a new player is usually generated directly when a multimedia playback requirement is detected, and the corresponding audio and video streams are played based on the newly generated player. In addition, when the player is no longer used, the player's core resources are directly released.

[0004] However, when processing multimedia playback requirements in different business scenarios based on the above method, since the core resources of the player are released, there will be a time-consuming problem of calling the player in other business scenarios, or when switching the playback content in the player, the core resources of the player need to be rebuilt, resulting in reduced program response efficiency, and then reduced program execution efficiency, affecting the user experience. Summary of the Invention

[0005] The present disclosure provides a player multiplexing method, device, electronic device and storage medium, so as to achieve the effect of global multiplexing of subsequent players by keeping the core resources of the stream pulling player from being released, thereby improving program execution efficiency and stream pulling efficiency.

[0006] In a first aspect, an embodiment of the present disclosure provides a player multiplexing method, the method comprising:

[0007] When the stream pulling player meets the pool entry condition, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread;

[0008] If the current state is inconsistent with the preset state, adjusting the current state of the stream pull player to the preset state, and placing the stream pull player into a player reuse pool;

[0009] When a call instruction for calling a player is received, a stream pulling player is called from the player multiplexing pool to play the audio and video stream based on the called stream pulling player.

[0010] In a second aspect, an embodiment of the present disclosure further provides a player multiplexing device, the device comprising:

[0011] A player status verification module is used to keep the thread resources of the stream pulling player from being released and verify the current status of the stream pulling player based on an asynchronous verification thread when the stream pulling player meets the pool entry conditions;

[0012] A player state adjustment module is configured to adjust the current state of the stream pull player to the preset state if the current state is inconsistent with the preset state, and place the stream pull player into a player reuse pool;

[0013] The player calling module is used to call the stream pulling player from the player multiplexing pool when receiving a calling instruction to call the player, so as to play the audio and video stream based on the called stream pulling player.

[0014] In a third aspect, an embodiment of the present disclosure further provides an electronic device, the electronic device comprising:

[0015] one or more processors;

[0016] a storage device for storing one or more programs,

[0017] When the one or more programs are executed by the one or more processors, the one or more processors implement the player multiplexing method as described in any of the embodiments of the present disclosure.

[0018] In a fourth aspect, an embodiment of the present disclosure further provides a storage medium comprising computer-executable instructions, which, when executed by a computer processor, are used to execute the player multiplexing method as described in any one of the embodiments of the present disclosure.

[0019] The technical solution of the embodiment of the present disclosure keeps the thread resources of the stream pulling player from being released and verifies the current state of the stream pulling player based on the asynchronous verification thread when the stream pulling player meets the pool entry conditions. Furthermore, if the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool. Finally, when a call instruction to call the player is received, the stream pulling player is called from the player reuse pool to play the audio and video stream based on the called stream pulling player. This solves the problem in the related art that when switching the playback content in the player or calling the player in other application scenarios, the core resources of the player need to be rebuilt, which takes a long time, resulting in reduced program response efficiency and affecting program execution efficiency. This achieves the effect of global reuse of subsequent players by keeping the core resources of the stream pulling player from being released, thereby improving program execution efficiency and stream pulling efficiency, and enhancing user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The above and other features, advantages, and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that the originals and elements are not necessarily drawn to scale.

[0021] Figure 1 This is a flowchart of a player multiplexing method provided by an embodiment of the present disclosure;

[0022] Figure 2 This is a flowchart of a player multiplexing method provided by an embodiment of the present disclosure;

[0023] Figure 3 This is a flowchart of a player multiplexing method provided by an embodiment of the present disclosure;

[0024] Figure 4 This is a flowchart of a player multiplexing method provided by an embodiment of the present disclosure;

[0025] Figure 5 This is a flowchart of a player multiplexing method provided by an embodiment of the present disclosure;

[0026] Figure 6 This is a structural diagram of a player multiplexing device provided by an embodiment of the present disclosure;

[0027] Figure 7 It is a structural diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0028] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0029] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0030] As used herein, the term "including" and its variations are open-ended, i.e., "including but not limited to." The term "based on" means "based, at least in part, on." The term "one embodiment" means "at least one embodiment," the term "another embodiment" means "at least one additional embodiment," and the term "some embodiments" means "at least some embodiments." Other terms are defined in the following description.

[0031] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0032] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, they should be understood as "one or more".

[0033] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0034] It is understandable that before using the technical solutions disclosed in the various embodiments of this disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved in this disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0035] For example, in response to a user's active request, a prompt message is sent to the user to clearly inform the user that the operation requested will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the electronic device, application, server, storage medium, or other software or hardware that performs the operations of the disclosed technical solution based on the prompt message.

[0036] As an optional but non-limiting implementation, in response to receiving a user's active request, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. Furthermore, the pop-up window may also contain a selection control for the user to select "agree" or "disagree" to provide personal information to the electronic device.

[0037] It is understandable that the above notification and user authorization process are merely illustrative and do not limit the implementation of the present disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0038] It is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) must comply with the requirements of relevant laws, regulations and relevant provisions.

[0039] Before introducing the present technical solution, an example of the application scenario can be first explained. The technical solution of the embodiment of the present disclosure can be applied to the scenario of player reuse in the same application. For example, for any application that includes audio and video playback functions, such as a live broadcast player application, it can include two layers, namely a middle-end player and a stream-pulling player. When the application instruction of the application player is detected, a new player can be directly generated to play the corresponding audio and video stream based on the newly generated player. When the playback is no longer needed, the core resources of the player are released to destroy the player; or, for a list-based live broadcast scenario, at least two player application scenarios can be included: the first, there will be "shallow reuse" for the player, for example, the middle-end player is retained when the list is scrolled, but the attribute values ​​inside the middle-end player will be cleared. At the same time, the stream-pulling player will call the destruction operation to deconstruct the core resources of the player during the clearing process to ensure that the stream-pulling rendering process of the player will not affect each other during "shallow reuse"; the second, when leaving the list-based live broadcast page, the entire player resources will be destroyed and cannot be used in other scenarios. Therefore, when applying the player based on the above method, there may be a situation where the player does not have global reuse capability, that is, it is not possible to retain an idle player in the same application and supply it to another new scene for use; and, due to the lack of reuse capability, the kernel resources of the stream player will be rebuilt during the stream pulling process, resulting in a long stream pulling process. At this time, based on the technical solution of the embodiment of the present disclosure, when receiving the stream pulling player and determining that the stream pulling player meets the pool entry conditions, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread. Then, if the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool. Then, when a call instruction to call the player is received, the stream pulling player is retrieved from the player reuse pool to play the audio and video stream based on the retrieved stream pulling player. Thus, the kernel resources of the stream pulling player are kept from being released to achieve the effect of global reuse of subsequent players, thereby improving the program execution efficiency and stream pulling efficiency, and enhancing the user experience.

[0040] Figure 1This is a flow chart of a player multiplexing method provided by an embodiment of the present disclosure. The embodiment of the present disclosure is applicable to any application program where, when the playback source is switched and the player needs to be called, the existing player can be directly called. The method can be executed by a player multiplexing device, which can be implemented in the form of software and / or hardware. Optionally, it can be implemented by an electronic device, which can be a mobile terminal, PC or server, etc.

[0041] like Figure 1 As shown, the method includes:

[0042] S110: When the stream pulling player meets the pool entry condition, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread.

[0043] A stream pull player can be understood as a player capable of implementing the stream pulling process and the playback and rendering process. A stream pull player can be the underlying core player within an application. For example, in a live broadcast scenario, when the live video stream corresponding to the current host is played on the display interface, a player can be invoked within the application to play the live video stream corresponding to the current host. In this case, the player playing the live video stream can be considered the stream pull player. Those skilled in the art will understand that for an application that includes audio and video playback functionality, the player within the application can generally consist of three layers: a service player, a middleware player, and a stream pull player. A service player can be the player corresponding to each service layer within the application. For example, service players can include a live broadcast service player, a search service player, and other service players. The middleware player can encapsulate the basic operations of the stream pull player, consolidate common middleware capabilities across the service layers, simplify service call costs, and be used to directly connect to various service scenarios. The stream pull player can encapsulate the core stream pulling process and playback and rendering capabilities, and can be used to build underlying capabilities. Within an application, the relationship between these three player layers can be that the service player contains the middleware player, and the middleware player contains the stream pull player.

[0044] Among them, the pool entry condition can be a pre-set condition that limits whether the player can enter the player reuse pool. It should be noted that the pool entry condition can be any condition that can achieve the player reuse effect. Optionally, the pool entry condition can be that the stream player changes from a used state to an unused state, and the existing attributes of the stream player in the player reuse pool do not reach the first preset attribute threshold. The used state can be understood as the state corresponding to when the player is currently playing the audio and video stream, that is, the "play" state. The unused state can be understood as the state corresponding to when the player is not currently playing the audio and video stream, that is, the "stopped" state. The player reuse pool can be understood as a pre-built buffer for temporarily storing players. It should be noted that one or more stream players can be stored in the player reuse pool, and the stream players stored in the player reuse pool are all available players, that is, when a player call instruction for any scenario in the application is detected, the stream player can be called in the player reuse pool to play the audio and video stream to be played based on the stream player. The existing attributes can be understood as the attributes of the stored stream players in the player reuse pool. The existing attribute may be any attribute associated with a stored stream-pulling player. Optionally, the existing attribute may be the number of stream-pulling players stored in the player reuse pool. The first preset attribute threshold may be a pre-set existing attribute threshold. It should be noted that the first preset attribute threshold may be associated with the existing attribute, that is, different existing attributes may correspond to different first preset attribute thresholds, and the embodiments of the present disclosure do not limit this. Optionally, in the case where the existing attribute is the number of stream-pulling players stored in the player reuse pool, the first preset attribute threshold may be a threshold value for the number of stream-pulling players stored in the player reuse pool. In this case, the first preset attribute threshold may be any value, and optionally, may be three.

[0045] The thread resources of a stream player can be understood as the actual operational resources required when the stream player is in use, that is, the resources that ensure the normal playback of audio and video streams by the stream player. Thread resources can include multiple modules, including input / output modules (IO modules), hardware decoding modules, rendering modules, and post-processing modules.

[0046] In practical applications, after obtaining a stream player to be placed in a player reuse pool, it is possible to first determine whether the stream player meets the pool entry conditions. Furthermore, if it is determined that the stream player meets the pool entry conditions, that is, the stream player has changed from a used state to an unused state, and the existing attributes of the stream players in the player reuse pool have not reached a first preset threshold, the thread resources of the stream player can be maintained to preserve the existing thread resources of the stream player. Furthermore, the current state of the stream player can be verified based on an asynchronous verification thread.

[0047] The asynchronous verification thread can be understood as a thread distinct from the current main thread. In this embodiment, the current main thread is the pooling thread for the stream player. The asynchronous verification thread can execute corresponding thread tasks in parallel with the current main thread, allowing different thread tasks to execute simultaneously. The current state of the stream player can be an indicator of the current usage of the stream player.

[0048] In actual applications, in order not to block the execution of the current main thread, the current state of the stream player can be checked based on an asynchronous check thread. It should be noted that the use of an asynchronous check thread to check the state of the stream player in the embodiment of the present disclosure is different from the use of the current main thread to check the state of the stream player in the related art. In the related art, after obtaining the stream player to be pooled, the current state of the stream player is directly checked based on the pool entry main thread, so that after the check passes, the player pool entry operation is continued. However, in general, the operation of checking the current state of the stream player and processing the stream player based on the check result takes a long time, which may block the execution of the pool entry main thread and reduce the execution efficiency of the program. In order to solve the problems existing in the related art, the embodiment of the present disclosure adopts a method of checking the current state of the stream player based on an asynchronous check thread, and then, while the asynchronous check thread is checking the current state of the stream player, the pool entry main thread can perform the task of storing the stream player that has passed the check into the player reuse pool. The advantage of this setting is that it improves the execution efficiency of the program and improves the concurrent processing capability and response speed of the program.

[0049] In actual applications, when verifying the current state of the stream-pulling player based on the asynchronous verification thread, the current state of the stream-pulling player can be first obtained in the asynchronous verification thread, and then the obtained current state can be verified.

[0050] Optionally, verifying the current state of the stream-pulling player based on the asynchronous verification thread includes: obtaining the current state of the stream-pulling player based on the player state machine in the asynchronous verification thread.

[0051] The player state machine can be understood as an execution program in the asynchronous verification thread, which can be used to obtain the current state of the player placed in the asynchronous verification thread. In this embodiment, obtaining the current state of the stream-pulling player can be understood as obtaining an identifier representing the player's current usage status from the attribute information corresponding to the stream-pulling player.

[0052] In practical applications, after determining that a stream-pulling player meets the pool entry criteria, the player can be placed in an asynchronous verification thread. Furthermore, the asynchronous verification thread retrieves the current state of the stream-pulling player based on the player state machine. The obtained current state can then be verified in the asynchronous verification thread. Consequently, processing of the stream-pulling player can continue based on the state verification results.

[0053] S120: If the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in a player reuse pool.

[0054] The preset state may be any predetermined player state. Alternatively, the preset state may be an unused state, ie, a "stopped" state.

[0055] In actual applications, when verifying the current state of the stream-pulling player, the current state can be compared with the preset state. If the current state is inconsistent with the preset state, the current state of the stream-pulling player can be adjusted to the preset state. Then, the adjusted stream-pulling player can be placed in the player reuse pool. For example, if the preset state is the "stopped" state, when the current state of the stream-pulling player is the "close" state or the "play" state, the stream-pulling player cannot enter the player reuse pool. The current state of the stream-pulling player can be adjusted from the "close" state or the "play" state to the "stopped" state, and then, the stream-pulling player in the "stopped" state can be placed in the player reuse pool.

[0056] It should be noted that if the current state of the stream pulling player is consistent with the preset state, the stream pulling player can be directly placed in the player reuse pool.

[0057] In actual applications, the current state verification operation of the stream player is executed in the asynchronous verification thread, while the operation of placing the stream player into the player reuse pool is executed in the main thread. Although it has been determined that the existing attributes of the stream player in the player reuse pool have not reached the first preset attribute threshold before the stream player is placed into the asynchronous verification thread, during the process of verifying the current state of the stream player based on the asynchronous verification thread, the main thread may also be executing the operation of placing other stream players that have passed the verification into the player reuse pool. As a result, there may be a situation where the existing attributes of the stream player in the player reuse pool have reached the first preset attribute threshold when the verified stream player is placed into the player reuse pool. Therefore, in order to avoid this situation, before placing the stream player into the player reuse pool, it can be determined again whether the existing attributes of the stream player in the player reuse pool have not reached the first preset attribute threshold, and then the stream player can be processed according to the existing attribute detection results.

[0058] Optionally, placing the stream-pulling player into the player reuse pool includes: obtaining existing attributes of the stream-pulling player in the player reuse pool based on the main thread; when the existing attributes do not reach a first preset attribute threshold, executing the operation of placing the stream-pulling player into the player reuse pool based on the main thread.

[0059] The main thread can be the thread that executes the main method, or it can be understood as the thread that starts running immediately when any application is started. In any application, there can be multiple main threads. In this embodiment, the main thread can be the thread that executes the player pool operation.

[0060] In actual application, when the status check of the stream player passes, the stream player can be placed in the main thread. Afterwards, in the main thread, the existing attributes of the stream player in the player reuse pool are obtained, and it is determined whether the existing attributes obtained have reached the first preset attribute threshold. Further, when it is determined that the existing attributes have not reached the first preset attribute threshold, the stream player in the main thread can be placed in the player reuse pool. Optionally, when the existing attribute is the number of stream players in the player reuse pool, and the first preset attribute threshold is the first preset number threshold of the stream players in the player reuse pool, when it is determined that the number of stream players stored in the player reuse pool has not reached the first preset number threshold, the stream player in the main thread can be placed in the player reuse pool. The advantage of such a setting is that it can avoid the situation where the existing attributes of the stream player in the player reuse pool have reached the first preset attribute threshold when the verified stream player is placed in the player reuse pool, thereby ensuring that the existing attributes of the stream player in the player reuse pool always remain within the first preset attribute threshold, so as to achieve the effect of limiting the number of stream players placed in the player reuse pool.

[0061] It should be noted that before placing the stream player into the player reuse pool, the business attributes corresponding to the role parties involved in the stream player can also be cleared, so that the stream player placed in the player reuse pool does not carry the business attribute identifier corresponding to any role party. Generally speaking, a stream player usually involves three role parties, namely the actual business, the middle platform, and the core stream. In order to achieve a better player reuse effect, before placing the stream player into the player reuse pool, all the business attributes defined by the role parties involved in the stream player can be cleared. In actual applications, a three-layer cleanup mechanism can be deployed in the main thread, and the calling order of the three-layer cleanup mechanism is kernel stream, middle platform, and business. For the stream player to be placed in the player reuse pool, the cleanup mechanism can be called in sequence to clear the corresponding business attributes in the stream player. Among them, a custom entry can be provided for the cleanup of the business, so that the business party can clean up specific resources according to the corresponding business needs.

[0062] It should also be noted that if the existing attributes of the streaming player in the player reuse pool reach the first preset attribute threshold, it may indicate that no other streaming players can be placed in the player reuse pool. At this time, the player in the main thread can be destroyed to ensure the normal execution of the main thread.

[0063] Optionally, based on the above technical solutions, the method further includes: when the existing attribute reaches a first preset attribute threshold, configuring an asynchronous destruction flag for the stream pulling player, so as to asynchronously destroy the stream pulling player based on the asynchronous destruction flag.

[0064] Among them, the asynchronous destruction flag can be understood as a flag that represents the destruction of the player based on the asynchronous destruction thread. It should be noted that for a player, destruction should ensure the complete destruction of kernel resources. The entire destruction process is very time-consuming. If the destruction operation is performed in the main thread, it may seriously affect the normal operation of the main thread; or, for a stream-pulling player, if it is directly destroyed by setting the middle platform player to zero, it will cause the kernel resources of the stream-pulling player to be exposed. Based on this, the technical solution provided by the embodiment of the present disclosure adopts an asynchronous destruction method, that is, first, an asynchronous destruction flag is configured for the stream-pulling player to be destroyed. Furthermore, the corresponding stream-pulling player can be asynchronously destroyed based on the asynchronous destruction flag in the asynchronous destruction thread, so that the stream-pulling player destruction process is almost time-consuming, thereby improving the execution efficiency of the program.

[0065] In actual applications, if the attributes of an existing stream-pulling player in the player reuse pool reach a first preset attribute threshold, it indicates that no more stream-pulling players can be added to the player reuse pool. Furthermore, an asynchronous destruction flag can be configured for the stream-pulling player in the main thread, and the stream-pulling player can be placed in an abnormal destruction process. In this process, the stream-pulling player with the asynchronous destruction flag configured is destroyed, that is, all thread resources of the stream-pulling player are released.

[0066] S130: When a call instruction for calling a player is received, a stream pulling player is called from a player multiplexing pool to play the audio and video stream based on the called stream pulling player.

[0067] Among them, the calling instruction can be understood as a pre-written program code, which can be used to call and apply the player. In this embodiment, when it is detected that the page currently displayed in the application has an audio and video stream playback demand, a calling instruction for calling the player can be generated to call the stream player from the player multiplexing pool based on the calling instruction. In actual applications, detecting that the page currently displayed has an audio and video stream playback demand can be detecting a pre-set playback trigger mechanism; or, it can be that the audio and video stream to be played in the currently displayed page meets the business logic playback conditions; or, it can be jumping from the search result page or the video list page to the currently displayed page, etc. Optionally, the playback trigger mechanism can be a trigger operation acting on the current page, such as the user triggering clicking a play button, single-clicking or double-clicking the current page, etc.

[0068] In actual applications, when the need to play an audio or video stream is detected, a call instruction for calling a player can be generated. Then, when the call instruction is received, the stream player can be called from the player multiplexing pool according to the call instruction, so that the corresponding audio and video stream can be played based on the called stream player. It should be noted that when calling a stream player from the player multiplexing pool, it can be called randomly, or it can be called based on preset calling rules, or it can be other calling methods, and the embodiments of the present disclosure do not make specific restrictions on this. The preset calling rules can be any rules, and optionally, they can be based on the order in which the stream players are placed in the player multiplexing pool.

[0069] The technical solution of the embodiment of the present disclosure keeps the thread resources of the stream pulling player from being released and verifies the current state of the stream pulling player based on the asynchronous verification thread when the stream pulling player meets the pool entry conditions. Furthermore, if the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool. Finally, when a call instruction to call the player is received, the stream pulling player is called from the player reuse pool to play the audio and video stream based on the called stream pulling player. This solves the problem in the related art that when switching the playback content in the player or calling the player in other application scenarios, the core resources of the player need to be rebuilt, which takes a long time, resulting in reduced program response efficiency and affecting program execution efficiency. This achieves the effect of global reuse of subsequent players by keeping the core resources of the stream pulling player from being released, thereby improving program execution efficiency and stream pulling efficiency, and enhancing user experience.

[0070] Figure 2 This is a flowchart of a player reuse method provided by an embodiment of the present disclosure. The technical solution of this embodiment, based on the above embodiment, executes asynchronous destruction logic on the stream-pulling player when the stream-pulling player does not meet the pool entry conditions. For specific implementation methods, please refer to the description of this embodiment. Technical features that are identical or similar to those in the above embodiment are not repeated here.

[0071] like Figure 2 As shown, the method of this embodiment may specifically include:

[0072] S210: When the stream pulling player meets the pool entry condition, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread.

[0073] S220: If the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool.

[0074] S230: When a call instruction for calling a player is received, a stream pulling player is called from the player multiplexing pool to play the audio and video stream based on the called stream pulling player.

[0075] S240: When the stream pulling player changes from a used state to an unused state, and the existing attributes of the stream pulling player in the player reuse pool reach a first preset attribute threshold, an asynchronous destruction flag is marked for the stream pulling player, so as to asynchronously destroy the stream pulling player based on the asynchronous destruction flag.

[0076] In this embodiment, when a stream pulling player is received, if the stream pulling player does not meet the pool entry conditions, the stream pulling player may be asynchronously destroyed.

[0077] In practical applications, after obtaining a stream player to be placed in the player reuse pool, the current state of the stream player and the existing attributes of the stream players in the player reuse pool can be obtained. Furthermore, if it is determined that the current state of the stream player has changed from a used state to an unused state, and the existing attributes have reached a first preset attribute threshold, it indicates that the stream player cannot be placed in the player reuse pool. Furthermore, the stream player can be marked with an asynchronous destruction flag and placed in an abnormal destruction process. In this process, the stream player configured with the asynchronous destruction flag is destroyed, i.e., all thread resources of the stream player are released.

[0078] The technical solution of the embodiment of the present disclosure is as follows: when the stream player meets the pool entry conditions, the thread resources of the stream player are kept from being released and the current state of the stream player is verified based on the asynchronous verification thread. Afterwards, if the current state is inconsistent with the preset state, the current state of the stream player is adjusted to the preset state, and the stream player is placed in the player reuse pool. Furthermore, when a call instruction to call the player is received, the stream player is called from the player reuse pool to play the audio and video stream based on the called stream player. Finally, when the stream player changes from a used state to an unused state and the existing attributes of the stream player in the player reuse pool reach a first preset attribute threshold, an asynchronous destruction flag is marked for the stream player, and the stream player is asynchronously destroyed based on the asynchronous destruction flag, thereby improving the stream pulling efficiency of the application without excessively occupying system resources. In addition, the stream player is asynchronously destroyed, thereby improving the execution efficiency of the program and improving the concurrent processing capability and response speed of the program.

[0079] Figure 3 This is a flowchart of a player reuse method provided by an embodiment of the present disclosure. The technical solution of this embodiment is based on the above embodiment. When the target application is initialized, a stream-pulling player that is consistent with a first preset attribute threshold is placed in the player reuse pool. Thus, the stream-pulling player can be called from the player reuse pool when playing audio and video frames. For specific implementation methods, please refer to the description of this embodiment. Technical features that are the same or similar to those in the above embodiment will not be repeated here.

[0080] like Figure 3 As shown, the method of this embodiment may specifically include:

[0081] S310: When the stream pulling player meets the pool entry condition, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread.

[0082] S320: If the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool.

[0083] S330: When a call instruction for calling a player is received, a stream pulling player is called from the player multiplexing pool to play the audio and video stream based on the called stream pulling player.

[0084] S340: When the target application is initialized, a stream pulling player that is consistent with a first preset attribute threshold is placed in the player multiplexing pool, so that the stream pulling player is retrieved from the player multiplexing pool when playing audio and video frames.

[0085] Among them, the target application can be an application that includes a player, or it can also be understood as an application that has audio and video streaming playback requirements. The target application can be any application, optionally, it can be a live broadcast application, a search application or a multimedia application (such as a video application or an audio application). Application initialization can be understood as eliminating all data generated during the application process and restoring the application to its state before the application. In this embodiment, an initialization control can be set in the target application in advance, and when a trigger operation for the control is detected, the target application can be initialized. Alternatively, when the target application meets the preset initialization logic, an initialization request can be generated, and an initialization inquiry page corresponding to the initialization request can be popped up in the display interface. Then, when a trigger operation for agreeing to the initialization control is detected, the target application can be initialized.

[0086] In actual applications, when initialization of a target application is detected, multiple stream pull players can be pre-built. Furthermore, stream pull players that meet a first preset attribute threshold can be placed in a player multiplexing pool. In this case, the stream pull players placed in the player multiplexing pool can be pre-built stream pull players. Furthermore, when playing audio or video frames, or upon receiving a call instruction to call a player, a stream pull player can be called from the player multiplexing pool to play the audio or video frames based on the called stream pull player.

[0087] The technical solution of the embodiment of the present disclosure is as follows: when the stream player meets the pool entry conditions, the thread resources of the stream player are kept from being released and the current state of the stream player is verified based on the asynchronous verification thread. Afterwards, if the current state is inconsistent with the preset state, the current state of the stream player is adjusted to the preset state, and the stream player is placed in the player reuse pool. Then, when a call instruction to call the player is received, the stream player is called from the player reuse pool to play the audio and video stream based on the called stream player. Finally, when the target application is initialized, a stream player consistent with the first preset attribute threshold is placed in the player reuse pool, so that the stream player is called from the player reuse pool when playing the audio and video frames. This ensures that there is always a stream player with unreleased resources in the application. Furthermore, the process of rebuilding kernel thread resources is omitted when calling the player, thereby improving the stream pulling efficiency.

[0088] Figure 4 This is a flow chart of a player reuse method provided by an embodiment of the present disclosure. The technical solution of this embodiment is based on the above embodiment. After retrieving the stream-pulling player from the player reuse pool, the existing attributes of the player reuse pool are verified, and when the existing attributes are less than a preset multiple of the first preset attribute threshold, a stream-pulling player is added to the player reuse pool to make the existing attributes of the player reuse pool reach the first preset attribute threshold. For the specific implementation method, please refer to the description of this embodiment. Among them, the technical features that are the same or similar to those of the above embodiments are not repeated here.

[0089] like Figure 4 As shown, the method of this embodiment may specifically include:

[0090] S410: When the stream pulling player meets the pool entry condition, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread.

[0091] S420: If the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool.

[0092] S430: When a call instruction for calling a player is received, a stream pulling player is called from the player multiplexing pool to play the audio and video stream based on the called stream pulling player.

[0093] S440: Obtain existing attributes of the player reuse pool.

[0094] The existing attributes of the player multiplexing pool may be the existing attributes of the stream pulling players in the player multiplexing pool, that is, the number of stream pulling players already placed in the player multiplexing pool.

[0095] It should be noted that after a stream-pulling player is retrieved from the player pool, the number of stream-pulling players in the player pool may decrease. If the pool is not replenished in a timely manner, all the stream-pulling players in the pool will be quickly retrieved, thereby degrading the overall system performance of the target application. Therefore, after a stream-pulling player is retrieved from the player pool, the existing properties of the stream-pulling players in the pool can be promptly tested.

[0096] In actual applications, after calling the stream pulling player from the player reuse pool, the existing properties of the stream pulling player in the player reuse pool can be obtained based on the main thread or other child threads, and then the player reuse pool can be processed based on the obtained existing properties.

[0097] S450: If the existing attribute is less than a preset multiple of the first preset attribute threshold, at least one stream pulling player is added to the player multiplexing pool so that the existing attribute of the player multiplexing pool reaches the first preset attribute threshold.

[0098] The preset multiple can be any value, and optionally, can be 0.5 times.

[0099] It should be noted that if the existing attribute is less than a preset multiple of the first preset attribute threshold, the player multiplexing pool can be used to execute the access and supplement logic. In order to reduce the external interface exposure and avoid cumbersome access by the business side, the automatic access and supplement logic can be used.

[0100] In actual applications, if the existing attributes are less than the preset multiples of the first preset attribute threshold, at least one stream pulling player can be constructed, and the at least one constructed stream pulling player can be added to the player multiplexing pool so that the existing attributes of the player multiplexing pool can reach the first preset attribute threshold. For example, assuming that the first preset attribute threshold is 3 and the preset multiple is 0.5, the preset multiple of the first preset attribute threshold is 1.5. If after the stream pulling player is retrieved from the player multiplexing pool, the number of stream pulling players in the player multiplexing pool is 1, that is, the existing attribute is 1, which is less than 1.5, then two stream pulling players can be added to the player multiplexing pool. So that the number of stream pulling players in the player multiplexing pool reaches 3.

[0101] It should be noted that after retrieving the streaming player from the player multiplexing pool, if the existing attributes of the player multiplexing pool are not less than the preset multiples of the first preset attribute, the access and supplement logic may not be executed in the player multiplexing pool, that is, the streaming player will not be added to the player multiplexing pool.

[0102] The technical solution of the embodiment of the present disclosure is as follows: when the stream player meets the pool entry conditions, the thread resources of the stream player are kept from being released and the current state of the stream player is verified based on the asynchronous verification thread. Afterwards, if the current state is inconsistent with the preset state, the current state of the stream player is adjusted to the preset state, and the stream player is placed in the player reuse pool. Then, when a call instruction to call the player is received, the stream player is called from the player reuse pool to play the audio and video stream based on the called stream player. Afterwards, the existing attributes of the player reuse pool are obtained. If the existing attributes are less than a preset multiple of a first preset attribute threshold, at least one stream player is added to the player reuse pool to make the existing attributes of the player reuse pool reach the first preset attribute threshold, thereby achieving the effect of automatically retrieving and replenishing the stream players that have not released resources in the application, thereby improving the execution efficiency of the application and improving the overall system performance of the application.

[0103] Figure 5 This is a flowchart of a player reuse method provided by an embodiment of the present disclosure. This embodiment of the present disclosure is an optional embodiment of the above disclosed embodiments. The player reuse method can be described by taking the existing attribute as the number of stream pulling players in the player reuse pool and the first preset attribute threshold as three as an example. Figure 5 As shown, the method of the embodiment of the present disclosure may include the following steps:

[0104] 1. Receive the stream player and perform the pool operation on the stream player;

[0105] 2. Configure a status lock flag for the streaming player;

[0106] 3. Determine whether the number of players in the player reuse pool is greater than or equal to three. If not, proceed to step 4. If so, proceed to step 8.

[0107] 4. Determine whether the current state of the stream player is a preset state (e.g., unused state). If not, proceed to step 5. If so, proceed to step 6.

[0108] 5. Adjust the current state of the stream player to the preset state;

[0109] 6. Clear the service attribute tags in the streaming player (including: resetting the streaming software development toolkit attributes, clearing the middle platform tags, and clearing the service identifiers);

[0110] 7. Place the stream player into the player reuse pool;

[0111] 8. Configure an asynchronous destruction flag for the stream player so that the stream player can be asynchronously destroyed based on the asynchronous destruction flag.

[0112] 9. End the pool entry operation.

[0113] The technical solution of the embodiment of the present disclosure keeps the thread resources of the stream pulling player from being released and verifies the current state of the stream pulling player based on the asynchronous verification thread when the stream pulling player meets the pool entry conditions. Furthermore, if the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool. Finally, when a call instruction to call the player is received, the stream pulling player is called from the player reuse pool to play the audio and video stream based on the called stream pulling player. This solves the problem in the related art that when switching the playback content in the player or calling the player in other application scenarios, the core resources of the player need to be rebuilt, which takes a long time, resulting in reduced program response efficiency and affecting program execution efficiency. This achieves the effect of global reuse of subsequent players by keeping the core resources of the stream pulling player from being released, thereby improving program execution efficiency and stream pulling efficiency, and enhancing user experience.

[0114] Figure 6 This is a schematic diagram of the structure of a player multiplexing device provided by an embodiment of the present disclosure. Figure 6 As shown, the device includes: a player state checking module 610 , a player state adjusting module 620 and a player calling module 630 .

[0115] Among them, the player status verification module 610 is used to keep the thread resources of the stream pulling player from being released and to verify the current state of the stream pulling player based on the asynchronous verification thread when the stream pulling player meets the pool entry conditions; the player status adjustment module 620 is used to adjust the current state of the stream pulling player to the preset state if the current state is inconsistent with the preset state, and put the stream pulling player into the player reuse pool; the player calling module 630 is used to call the stream pulling player from the player reuse pool when receiving a calling instruction to call the player, so as to play the audio and video stream based on the called stream pulling player.

[0116] Based on the above technical solutions, the pool entry condition is that the stream pulling player changes from a used state to an unused state, and the existing attributes of the stream pulling players in the player reuse pool do not reach a first preset attribute threshold.

[0117] On the basis of the above technical solutions, the player status verification module 610 is specifically configured to execute, in the asynchronous verification thread, obtaining the current status of the stream pulling player based on the player state machine.

[0118] On the basis of the above technical solutions, the player state adjustment module 620 includes: an existing attribute acquisition unit and a player pool entry unit.

[0119] An existing attribute acquisition unit, configured to acquire, based on a main thread, existing attributes of the stream pulling player in the player reuse pool;

[0120] The player pooling unit is used to execute the operation of placing the stream pulling player into the player reuse pool based on the main thread when the existing attribute does not reach the first preset attribute threshold.

[0121] On the basis of the above technical solutions, the device further includes: an asynchronous destruction flag configuration module.

[0122] The asynchronous destruction flag configuration module is used to configure an asynchronous destruction flag for the stream pulling player when the existing attribute reaches the first preset attribute threshold, so as to asynchronously destroy the stream pulling player based on the asynchronous destruction flag.

[0123] On the basis of the above technical solutions, the device further includes: a stream player pool entry module.

[0124] The stream pulling player pool entry module is used to put a stream pulling player consistent with the first preset attribute threshold into the player multiplexing pool when the target application is initialized, so as to call the stream pulling player from the player multiplexing pool when playing audio and video frames.

[0125] On the basis of the above technical solutions, the device further includes: an asynchronous destruction identification marking module.

[0126] An asynchronous destruction identification marking module is used to mark the stream pulling player with an asynchronous destruction identification when the stream pulling player changes from a used state to an unused state and the existing attributes of the stream pulling player in the player reuse pool reach the first preset attribute threshold, so as to asynchronously destroy the stream pulling player based on the asynchronous destruction identification.

[0127] On the basis of the above technical solutions, the device further includes: an existing attribute acquisition module and a stream player adding module.

[0128] An existing attribute acquisition module, configured to acquire existing attributes of the player multiplexing pool after the pull stream player is retrieved from the player multiplexing pool;

[0129] The stream pulling player adding module is used to add at least one stream pulling player to the player multiplexing pool if the existing attribute is less than a preset multiple of the first preset attribute threshold, so that the existing attribute of the player multiplexing pool reaches the first preset attribute threshold.

[0130] The technical solution of the embodiment of the present disclosure keeps the thread resources of the stream pulling player from being released and verifies the current state of the stream pulling player based on the asynchronous verification thread when the stream pulling player meets the pool entry conditions. Furthermore, if the current state is inconsistent with the preset state, the current state of the stream pulling player is adjusted to the preset state, and the stream pulling player is placed in the player reuse pool. Finally, when a call instruction to call the player is received, the stream pulling player is called from the player reuse pool to play the audio and video stream based on the called stream pulling player. This solves the problem in the related art that when switching the playback content in the player or calling the player in other application scenarios, the core resources of the player need to be rebuilt, which takes a long time, resulting in reduced program response efficiency and affecting program execution efficiency. This achieves the effect of global reuse of subsequent players by keeping the core resources of the stream pulling player from being released, thereby improving program execution efficiency and stream pulling efficiency, and enhancing user experience.

[0131] The player multiplexing device provided in the embodiments of the present disclosure can execute the player multiplexing method provided in any embodiment of the present disclosure, and has the corresponding functional modules and beneficial effects of the execution method.

[0132] It is worth noting that the various units and modules included in the above-mentioned device are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the protection scope of the embodiments of the present disclosure.

[0133] Figure 7 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure. Figure 7 , which shows an electronic device (eg Figure 7 The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0134] like Figure 7As shown, the electronic device 500 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. Various programs and data required for the operation of the electronic device 500 are also stored in the RAM 503. The processing device 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An edit / output (I / O) interface 505 is also connected to the bus 504.

[0135] Typically, the following devices may be connected to the I / O interface 505: an input device 506 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 508 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 509. The communication device 509 may allow the electronic device 500 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 7 The electronic device 500 is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead.

[0136] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 509, or installed from the storage device 508, or installed from the ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the method of the embodiment of the present disclosure are performed.

[0137] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0138] The electronic device provided by the embodiment of the present disclosure and the player multiplexing method provided by the above embodiment belong to the same inventive concept. For technical details not fully described in this embodiment, please refer to the above embodiment, and this embodiment has the same beneficial effects as the above embodiment.

[0139] An embodiment of the present disclosure provides a computer storage medium on which a computer program is stored. When the program is executed by a processor, the player multiplexing method provided by the above embodiment is implemented.

[0140] It should be noted that the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or component. In the present disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0141] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0142] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device:

[0143] When the stream pulling player meets the pool entry condition, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread;

[0144] If the current state is inconsistent with the preset state, adjusting the current state of the stream pull player to the preset state, and placing the stream pull player into a player reuse pool;

[0145] When a call instruction for calling a player is received, a stream pulling player is called from the player multiplexing pool to play the audio and video stream based on the called stream pulling player.

[0146] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages, or a combination thereof, including, but not limited to, object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0148] According to one or more embodiments of the present disclosure, [Example 1] provides a player multiplexing method, the method comprising:

[0149] When the stream pulling player meets the pool entry condition, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread;

[0150] If the current state is inconsistent with the preset state, adjusting the current state of the stream pull player to the preset state, and placing the stream pull player into a player reuse pool;

[0151] When a call instruction for calling a player is received, a stream pulling player is called from the player multiplexing pool to play the audio and video stream based on the called stream pulling player.

[0152] According to one or more embodiments of the present disclosure, [Example 2] provides the method of Example 1, further comprising:

[0153] Optionally, the pool entry condition is that the stream pulling player changes from a used state to an unused state, and the existing attributes of the stream pulling players in the player reuse pool do not reach a first preset attribute threshold.

[0154] According to one or more embodiments of the present disclosure, [Example 3] provides the method of Example 1, further comprising:

[0155] Optionally, verifying the current state of the stream pulling player based on the asynchronous verification thread includes:

[0156] Obtaining the current state of the stream pulling player based on the player state machine is executed in the asynchronous verification thread.

[0157] According to one or more embodiments of the present disclosure, [Example 4] provides the method of Example 1, further comprising:

[0158] Optionally, placing the stream pulling player into a player reuse pool includes:

[0159] Obtaining existing properties of the stream pulling player in the player reuse pool based on the main thread;

[0160] When the existing attribute does not reach a first preset attribute threshold, an operation of placing the stream pulling player into the player reuse pool is executed based on the main thread.

[0161] According to one or more embodiments of the present disclosure, [Example 5] provides the method of Example 4, further comprising:

[0162] Optionally, the method further includes: when the existing attribute reaches the first preset attribute threshold, configuring an asynchronous destruction flag for the stream pulling player, so as to asynchronously destroy the stream pulling player based on the asynchronous destruction flag.

[0163] According to one or more embodiments of the present disclosure, [Example 6] provides the method of Example 1, further comprising:

[0164] Optionally, it also includes: when the target application is initialized, placing a stream pulling player consistent with the first preset attribute threshold into the player multiplexing pool, so as to call the stream pulling player from the player multiplexing pool when playing audio and video frames.

[0165] According to one or more embodiments of the present disclosure, [Example 7] provides the method of Example 1, further comprising:

[0166] Optionally, it also includes: when the stream pulling player changes from a used state to an unused state, and the existing attributes of the stream pulling player in the player reuse pool reach a first preset attribute threshold, an asynchronous destruction flag is marked for the stream pulling player, so as to asynchronously destroy the stream pulling player based on the asynchronous destruction flag.

[0167] According to one or more embodiments of the present disclosure, [Example 8] provides the method of Example 1, further comprising:

[0168] Optionally, after the stream pulling player is retrieved from the player multiplexing pool, the method further includes:

[0169] Obtain existing properties of the player reuse pool;

[0170] If the existing attribute is less than a preset multiple of the first preset attribute threshold, at least one stream pulling player is added to the player multiplexing pool so that the existing attribute of the player multiplexing pool reaches the first preset attribute threshold.

[0171] According to one or more embodiments of the present disclosure, [Example 9] provides a player multiplexing device, the device comprising:

[0172] A player status verification module is used to keep the thread resources of the stream pulling player from being released and verify the current status of the stream pulling player based on an asynchronous verification thread when the stream pulling player meets the pool entry conditions;

[0173] A player state adjustment module is configured to adjust the current state of the stream pull player to the preset state if the current state is inconsistent with the preset state, and place the stream pull player into a player reuse pool;

[0174] The player calling module is used to call the stream pulling player from the player multiplexing pool when receiving a calling instruction to call the player, so as to play the audio and video stream based on the called stream pulling player.

[0175] The above description is merely a preferred embodiment of the present disclosure and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also includes other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this disclosure.

[0176] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details have been included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0177] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are merely example forms of implementing the claims.

Claims

1. A player multiplexing method, characterized in that: include: When the stream pulling player meets the pool entry condition, the thread resources of the stream pulling player are kept from being released and the current state of the stream pulling player is verified based on the asynchronous verification thread; If the current state is inconsistent with the preset state, adjusting the current state of the stream pull player to the preset state, and placing the stream pull player into a player reuse pool; When a call instruction for calling a player is received, a stream pulling player is called from the player multiplexing pool to play the audio and video stream based on the called stream pulling player.

2. The method according to claim 1, characterized in that The pool entry condition is that the stream pulling player changes from a used state to an unused state, and the existing attributes of the stream pulling players in the player reuse pool do not reach a first preset attribute threshold.

3. The method according to claim 1, characterized in that Verifying the current state of the stream pulling player based on the asynchronous verification thread includes: Obtaining the current state of the stream pulling player based on the player state machine is executed in the asynchronous verification thread.

4. The method according to claim 1, wherein Placing the stream pulling player into a player reuse pool includes: Obtaining existing properties of the stream pulling player in the player reuse pool based on the main thread; When the existing attribute does not reach a first preset attribute threshold, an operation of placing the stream pulling player into the player reuse pool is executed based on the main thread.

5. The method according to claim 4, characterized in that Also includes: When the existing attribute reaches the first preset attribute threshold, an asynchronous destruction flag is configured for the stream pulling player, so as to asynchronously destroy the stream pulling player based on the asynchronous destruction flag.

6. The method according to claim 1, characterized in that Also includes: When the target application is initialized, a stream pulling player that is consistent with a first preset attribute threshold is placed in the player multiplexing pool, so that the stream pulling player is called from the player multiplexing pool when playing audio and video frames.

7. The method according to claim 1, characterized in that Also includes: When the stream pulling player changes from a used state to an unused state, and the existing attributes of the stream pulling players in the player reuse pool reach a first preset attribute threshold, an asynchronous destruction flag is marked for the stream pulling player, so that the stream pulling player is asynchronously destroyed based on the asynchronous destruction flag.

8. The method according to claim 1, characterized in that After the stream pulling player is retrieved from the player multiplexing pool, the method further includes: Obtain existing properties of the player reuse pool; If the existing attribute is less than a preset multiple of the first preset attribute threshold, at least one stream pulling player is added to the player multiplexing pool so that the existing attribute of the player multiplexing pool reaches the first preset attribute threshold.

9. A player multiplexing device, characterized in that: include: A player status verification module is used to keep the thread resources of the stream pulling player from being released and verify the current status of the stream pulling player based on an asynchronous verification thread when the stream pulling player meets the pool entry conditions; A player state adjustment module is configured to adjust the current state of the stream pull player to the preset state if the current state is inconsistent with the preset state, and place the stream pull player into a player reuse pool; The player calling module is used to call the stream pulling player from the player multiplexing pool when receiving a calling instruction to call the player, so as to play the audio and video stream based on the called stream pulling player.

10. An electronic device, characterized in that: The electronic device comprises: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the player multiplexing method as described in any one of claims 1-8.

11. A storage medium comprising computer executable instructions, wherein the computer executable instructions are used to execute the player multiplexing method as described in any one of claims 1 to 8 when executed by a computer processor.

Images