CN113225605B

CN113225605B - Video playing processing method and device, electronic equipment and storage medium

Info

Publication number: CN113225605B
Application number: CN202010080911.5A
Authority: CN
Inventors: 胡玮; 张晓文; 吴桂盛
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-02-05
Filing date: 2020-02-05
Publication date: 2024-03-01
Anticipated expiration: 2040-02-05
Also published as: CN113225605A

Abstract

The invention provides a video playing processing method, a video playing processing device, electronic equipment and a storage medium; the method comprises the following steps: in response to a switching video operation for a player, acquiring a target video of the switching video operation, and determining a target decoder instance adapted to the target video from decoder instances stored in a shared space; invoking the target decoder instance in the shared space to decode media data included in the target video, and outputting a decoding result of the media data for presentation in a display interface of the player. By the method and the device, delay in video switching can be effectively reduced.

Description

Video playing processing method and device, electronic equipment and storage medium

Technical Field

The present invention relates to multimedia technologies, and in particular, to a video playing method, apparatus, electronic device, and storage medium.

Background

Multimedia forms, represented by video (in particular short video), are widely spread by means of the internet, in particular the mobile internet. Because of the characteristics of the massive amount of videos, a very high-frequency use scene is a video which is switched to play in the process of watching the videos, and if delay occurs in the switching process, the user experience is directly affected. The related art lacks a general and efficient solution for reducing the delay of video playback switching.

Disclosure of Invention

The embodiment of the invention provides a video playing processing method, a video playing processing device, electronic equipment and a storage medium, which can effectively reduce delay in video switching.

The technical scheme of the embodiment of the invention is realized as follows:

the embodiment of the invention provides a video playing processing method, which comprises the following steps:

in response to a switching video operation for a player, acquiring a target video of the switching video operation, and determining a target decoder instance adapted to the target video from decoder instances stored in a shared space;

invoking the target decoder instance in the shared space to decode media data included in the target video, and outputting a decoding result of the media data for presentation in a display interface of the player.

The embodiment of the invention provides a video playing processing device, which comprises:

the acquisition module is used for responding to the video switching operation aiming at the player and acquiring a target video of the video switching operation;

a determining module for determining a target decoder instance adapted to the target video from among decoder instances stored in a shared space;

a calling module, configured to call the target decoder instance in the shared space to decode media data included in the target video;

And the output module is used for outputting the decoding result of the media data to be presented in the display interface of the player.

In the above scheme, the device further comprises a storage module,

the storage module is used for responding to the video switching operation of the player and storing decoder instances operated when the historical video is decoded in the shared space;

wherein the history video is a video played before the switching video operation video is received.

In the above scheme, the storage module is further configured to store decoder resources corresponding to decoder instances invoked when decoding the historical video and corresponding display interface output layers into the memory space of the shared space;

the display interface output layer is used for presenting according to the received decoding result of the media data.

In the above scheme, the device further comprises an initialization module,

the initialization module is used for initializing and calling a new decoder instance adapted to the target video when the target decoder instance adapted to the target video is not stored in the shared space, and outputting a decoding result to be presented in a display interface of the player.

In the above arrangement, the device further comprises a release module,

the releasing module is configured to release at least part of decoder instances already stored in the shared space until the memory space occupied by the shared space reaches a memory space threshold

The number of decoder instances in the shared space does not exceed a number threshold, or the memory space occupied by the shared space does not exceed a memory space threshold.

In the above aspect, the release module is further configured to perform at least one of the following release operations:

according to the first-in first-out mode, releasing decoder resources corresponding to decoder examples entering the shared space and corresponding display interface output layers;

and according to the descending order of the frequency of the decoder in the shared space used in the monitoring time, releasing decoder resources corresponding to decoder examples in the shared space and corresponding display interface output layers.

In the above solution, the device further comprises a preloading module,

the preloading module is configured to determine a decoder instance that satisfies a preloading condition when the player is initialized or when the shared space is empty during operation of the player, and

Preloading the decoder instance meeting the preloading condition in the shared space.

In the above solution, the preloading module is further configured to determine a decoder instance that meets at least one of the following preloading conditions:

the first decoder instances in the descending order of usage frequency;

a plurality of decoder instances last invoked before the player was last turned off;

a decoder instance adapted to the preferred video type.

In the above scheme, the preloading module is further configured to obtain a context feature related to the player and a user feature of a player user;

fusing the context features and the user features, and predicting the fused features through a machine learning model combination to obtain preloading probabilities of a plurality of candidate decoder examples;

preloading a plurality of candidate decoder instances in the descending order of preloading probability into the shared memory;

wherein the contextual characteristics include at least one of: information of the video which has been played by the player; video switching frequency;

wherein the information of the video includes at least one of: the type and name of the video; and playing the video, wherein the available memory space of the player is used for playing the video.

In the above scheme, the calling module is further configured to intercept an application program interface of the decoder instance;

the functionality of the intercepted application program interface is proxied through a proxy decoder instance that includes the same application program interface as the intercepted decoder instance.

In the above solution, the determining, from among decoder instances stored in the shared space, a target decoder instance adapted to the target video includes:

acquiring configuration parameters of decoder examples stored in a shared space and video parameters of the target video;

and determining the decoder instance corresponding to the configuration parameter matched with the video parameter as a target decoder instance matched with the target video.

In the above solution, the invoking the target decoder instance in the shared space to decode media data included in the target video includes:

inserting preset type coding information into media data included in the target video to obtain edited media data, wherein the coding information comprises at least one of the following: a sequence parameter set; a picture parameter set;

invoking the target decoder instance in the shared space to decode the edited media data.

An embodiment of the present invention provides a video play processing device, including:

a memory for storing executable instructions;

and the processor is used for realizing the video playing processing method provided by the embodiment of the invention when executing the executable instructions stored in the memory.

The embodiment of the invention provides a computer readable storage medium, which is characterized in that executable instructions are stored for realizing the video playing processing method provided by the embodiment of the invention when being executed by a processor.

The embodiment of the invention has the following beneficial effects:

in the process of switching the player to play the target video, the decoder instance adapting to the target video can be called from the shared space, so that the decoder instance already instantiated by the player can be flexibly multiplexed, a new decoder instance does not need to be always re-created, and the delay in video switching is effectively reduced.

Drawings

FIG. 1 is a schematic diagram of a life cycle of a decoder according to an embodiment of the present invention;

fig. 2 is a schematic flow chart of a short video playing method based on a decoder according to an embodiment of the present invention;

fig. 3 is a schematic flow chart of decoder multiplexing in a player according to an embodiment of the present invention;

Fig. 4 is a schematic view of a video switching definition provided in an embodiment of the present invention;

FIG. 5 is a schematic diagram of an alternative architecture of a video playback processing system according to an embodiment of the present invention;

fig. 6 is a schematic structural diagram of a video playing processing device according to an embodiment of the present invention;

fig. 7A is a schematic flow chart of an alternative video playing processing method according to an embodiment of the present invention;

FIG. 7B is a flowchart illustrating a method for determining a target decoder instance according to an embodiment of the present invention;

FIG. 7C is a flowchart illustrating a method for invoking a target decoder instance according to an embodiment of the present invention;

fig. 8A-8B are schematic interface diagrams of video switching scenes provided in an embodiment of the present invention;

fig. 9 is a schematic flow chart of a cross-player multiplexing decoder according to an embodiment of the present invention;

fig. 10A is a schematic diagram of a decoder multiplexing condition according to an embodiment of the present invention;

fig. 10B is a schematic diagram of multiplexing conditions during adaptive playback according to an embodiment of the present invention;

fig. 10C is a schematic diagram of multiplexing conditions during non-adaptive playing according to an embodiment of the present invention;

FIG. 11 is a schematic diagram of a class design according to an embodiment of the present invention;

fig. 12 is a schematic diagram of an alternative architecture of a video playing system according to an embodiment of the present invention;

Fig. 13 is an operation schematic diagram of a decoder multiplexing front-end according to an embodiment of the present invention;

FIG. 14 is a schematic diagram of a module call relationship according to an embodiment of the present invention;

fig. 15 is a comparative schematic diagram of video time consumption provided by an embodiment of the invention.

Detailed Description

The present invention will be further described in detail with reference to the accompanying drawings, for the purpose of making the objects, technical solutions and advantages of the present invention more apparent, and the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by those skilled in the art without making any inventive effort are within the scope of the present invention.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is to be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with one another without conflict.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.

Before describing embodiments of the present invention in further detail, the terms and terminology involved in the embodiments of the present invention will be described, and the terms and terminology involved in the embodiments of the present invention will be used in the following explanation.

1) Video first frame: and a process of reading the video from the player and rendering the first frame of the video on the display interface for display.

2) A player: a multimedia play frame, such as MediaPlayer, exoPlayer, ijkPlayer, capable of providing play capability.

3) A decoder: i.e. a video decoder, for a decoding link of video data in a player, such as a MediaCodec decoder on an Android platform, a process of creating each class in a static code of the decoder as an object in a memory space, called an instantiation process of the decoder, the instantiated decoder being a decoder in a running state, also called a decoder instance, which occupies a certain memory resource (memory space), and when the decoder instance is released, the object data in the memory space is emptied.

4) Proxy decoder (TMediaCodec): the function of the original decoder (MediaCodec) used by the proxy player can intercept MediaCodec, selectively multiplex, and reduce unnecessary initialization time.

5) Adaptive playback (Adaptive Playback Support) refers to the direct decoding of the next video source content without resetting the decoder after switching video sources (video + audio) under certain conditions.

6) Decoder multiplexing: the impending playing of one video is the multiplexing of the created decoder instance for decoding other videos.

7) The shared space, also called a shared pool, is used to store the memory space of the decoder that has been instantiated.

For example, keep a shared pool (KeepPool), when one video ends playing, the decoder does not destroy the decoder instance directly, but put into the shared pool and keep its state for multiplexing by other player instances (i.e. when the player plays other videos).

The inventor finds that in the process of implementing the video playing processing method provided by the embodiment of the invention, the conventional short video playing method is based on a decoder (MediaCodec), the function of encoding and decoding is realized by accessing the decoder at the bottom layer, the MediaCodec processes data in an asynchronous mode, and a group of input/output buffers (buffers) are used. Referring to fig. 1, fig. 1 is a schematic diagram of a life cycle of a decoder according to an embodiment of the present invention, as shown in fig. 1, in a process of encoding and decoding, the life cycle of MediaCodec includes three states: a Stopped state (Stopped), an Executing state (Executing), a Released state (Released), wherein the Stopped state includes: the method comprises the following three sub-states of an uninitialized state, a configuration state, an error state and the like, and the execution state comprises three sub-states of a refreshing state, an operation state, a stream end and the like.

The rule switching flow of the three sub-states of the stop state is as follows: when a MediaCo dec object is created, which is in an uninitialized state, the MediaCo dec object can be reset in any state to return the MediaCo dec to the uninitialized state, and the configuration of the MediaCo dec is changed to the configuration state. The error state is entered when MediaCodec encounters an error, which may be caused by an error or exception returned upon a queue operation.

The rule switching flow of the three sub-states of the execution state is as follows: the MediaCode c immediately enters a refreshing sub-state after the start function is called, and at the moment, the MediaCode c can have all caches and can return to the refreshing sub-state through refreshing at any time of the execution state; once the first input cache is dequeued, the Me diaCodec transitions to the run sub-state, which occupies most of the MediaCodec lifecycle, transitioning to the uninitialized state by invoking the stop function; when an input with an end of stream tag is buffered in the queue, mediaCodec transitions to the end of stream sub-state.

After using MediaCodec, the release function is called to release its resources, and the final release state is entered. Referring to fig. 2, fig. 2 is a schematic flow chart of a short video playing method based on a decoder according to an embodiment of the present invention, because one player only corresponds to one decoder and can only decode video with a configured encoding format, as shown in fig. 2, in the short video playing method according to an embodiment of the present invention, when one short video is played each time, the player restarts a new decoder, specifically:

1) Creating a decoder:

this procedure corresponds to the uninitialized state shown in fig. 1, and in actual implementation, the creation decoder is implemented by the function mediacodec.createdercoderbypype (), and a decoder instance is created in memory using createDe coderByType () of MediaCodec.

2) The decoder is configured:

this procedure corresponds to the configuration state shown in fig. 1, and in actual implementation, the decoder is configured through mediacodec.config ure (), and video coding parameters such as coding format, video width and height, etc. that need to be played are configured. Typically, a parameter-configured decoder can only decode the corresponding video in the encoding format.

3) Turning on the decoder:

this procedure corresponds to the operating state shown in fig. 1, and in actual implementation, the decoder is started by mediacodec.

Through the mode, the coding and decoding flow based on the MediaCodec is as follows: firstly, requesting an empty input buffer from the MediaCodec, filling the data, and then transmitting the data to the MediaCodec for processing; then MediaCodec finishes processing the data and outputs the processing result to an empty output buffer; finally, obtaining output buffered data from the MediaCodec, consuming the data therein, and releasing the output buffered data back to the decoder after the output buffered data is used; the switching process of video playback based on this is time consuming.

Further, the embodiment of the present invention improves the time consumption of the conventional mode by using ExoPlayer, and provides a scheme for multiplexing the decoder in the player, referring to fig. 3, fig. 3 is a schematic flow chart of multiplexing the decoder in the player provided by the embodiment of the present invention, as shown in fig. 3, in the same player, if the decoder played last time can be multiplexed by the current playing, the initialization flow of the decoder is not needed. Therefore, when a new short video is played each time, judging whether a decoder played last time in the player can be multiplexed or not, and if so, directly using the decoder; if not, the current decoder is released and a new decoder is reinitialized.

However, since ExoPlayer is an intra-player decoder multiplexing scheme that employs decoders that are not destroyed before, and decoders can only be inside the player instance, it can only be determined that the last decoder can not be multiplexed, and cannot be multiplexed across players. In addition, one player hardware only corresponds to one decoder, and can only decode the video with the adaptive coding format and width and height, and can be well reused only when the video source played currently is consistent with the video source played last time; however, in an actual short video scene, the video characteristics such as the coding format are relatively random, and are not fixed, so that the scheme based on Ex oPlayer results in a low multiplexing rate. In addition, due to randomness of the short video source, the scheme based on the multiplexing decoder in the player is more suitable for switching the video to the scenes with different definition as shown in fig. 4, the video can be switched to the scenes with different definition according to the network speed, the lifting effect on the first frame is limited, and the delay of video playing switching cannot be effectively reduced.

In view of this, the embodiments of the present invention provide a video playing processing method, apparatus, electronic device, and storage medium, which can reduce delay in video switching, and hereinafter describe exemplary applications of the video playing processing device provided in the embodiments of the present invention, where the electronic device provided in the embodiments of the present invention may be implemented as various types of user terminals such as a notebook computer, a tablet computer, a desktop computer, a set-top box, a mobile device (e.g., a mobile phone, a portable music player, a personal digital assistant, a dedicated messaging device, and a portable game device). In the following, an exemplary application of the electronic device will be described.

Referring to fig. 5, fig. 5 is a schematic diagram of an alternative architecture of the video playback processing system 100 according to an embodiment of the present invention, in order to support a video playback processing application, a terminal 400 (a terminal 400-1 and a terminal 400-2 are shown in an exemplary manner) are connected to a server 200 through a network 300, where the network 300 may be a wide area network or a local area network, or a combination of both.

In practical applications, the player may be in the form of a dedicated player client (APP, native APP), a Web page player in a browser, or a small program (Web APP), for example, the terminal 400 is provided with a player for displaying, on the graphical interface 410 (the graphical interface 410-1 and the graphical interface 410-2 are exemplarily shown), a short video to be switched acquired from the server 200, and when the target user clicks on the short video to be switched, a codec manager of the player on the terminal 400 acquires a target video of the switching video operation in response to the switching video operation for the player, and determines a target decoder instance adapted to the target video from among decoder instances stored in the shared pool; the target decoder instance in the shared pool is invoked to decode media data included in the target video and output the media data for presentation in a display interface of the player.

Referring to fig. 6, fig. 6 is a schematic structural diagram of a video play processing device 500 according to an embodiment of the present invention, and the video play processing device 500 shown in fig. 6 includes: at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. The various components in the video playback processing device 500 are coupled together by a bus system 540. It is appreciated that the bus system 540 is used to enable connected communications between these components. The bus system 540 includes a power bus, a control bus, and a status signal bus in addition to the data bus. The various buses are labeled as bus system 540 in fig. 6 for clarity of illustration.

The processor 510 may be an integrated circuit chip with signal processing capabilities such as a general purpose processor, such as a microprocessor or any conventional processor, or the like, a digital signal processor (DSP, digital Signal Processor), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or the like.

The user interface 530 includes one or more output devices 531 that enable presentation of media content, including one or more speakers and/or one or more visual displays. The user interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

The memory 550 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard drives, optical drives, and the like. Memory 550 may optionally include one or more storage devices physically located remote from processor 510.

Memory 550 includes volatile memory or nonvolatile memory, and may also include both volatile and nonvolatile memory. The non-volatile memory may be read only memory (ROM, read Only Me mory) and the volatile memory may be random access memory (RAM, random Access Memor y). The memory 550 described in embodiments of the present invention is intended to comprise any suitable type of memory.

In some embodiments, memory 550 is capable of storing data to support various operations, examples of which include programs, modules and data structures, or subsets or supersets thereof, as exemplified below.

An operating system 551 including system programs for handling various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and handling hardware-based tasks;

network communication module 552 is used to reach other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 include: bluetooth, wireless compatibility authentication (WiFi), and universal serial bus (USB, universal Serial Bus), etc.;

A presentation module 553 for enabling presentation of information (e.g., a user interface for operating a peripheral device and displaying content and information) via one or more output devices 531 (e.g., a display screen, speakers, etc.) associated with the user interface 530;

the input processing module 554 is configured to detect one or more user inputs or interactions from one of the one or more input devices 532 and translate the detected inputs or interactions.

In some embodiments, the apparatus provided by the embodiments of the present invention may be implemented in software, and fig. 6 shows an apparatus 555 stored in a memory 550, which may be software in the form of a program, a plug-in, or the like, including the following software modules: the acquisition module 5551, determination module 5552, invocation module 5553 and output module 5554 are logical and thus may be arbitrarily combined or further split depending on the functionality implemented.

The functions of the respective modules will be described hereinafter.

In other embodiments, the video playback processing apparatus provided in the embodiments of the present invention may be implemented in hardware, and by way of example, the video playback processing apparatus provided in the embodiments of the present invention may be a processor in the form of a hardware decoding processor that is programmed to perform the video playback processing method provided in the embodiments of the present invention, for example, the processor in the form of a hardware decoding processor may employ one or more application specific integrated circuits (ASIC, application Specific Integrated Circuit), DSP, programmable logic device (PLD, programmable Logic Device), complex programmable logic device (CPLD, comple x Programmable Logic Device), field programmable gate array (FPGA, field-Programma ble Gate Array), or other electronic components.

The video playing processing method provided by the embodiment of the invention will be described in connection with the exemplary application and implementation of the terminal provided by the embodiment of the invention.

Referring to fig. 7A, fig. 7A is a schematic flowchart of an alternative video playing processing method according to an embodiment of the present invention, and an example of running a player in a terminal is described with reference to the steps shown in fig. 7A.

The form of the player can be a special player APP, a webpage player in a browser or a player in an applet form.

Step 301: the codec manager of the player responds to the video switching operation for the player to acquire a target video of the video switching operation.

For example, a player APP is arranged on the terminal, and when a user clicks a switching key for the player, a corresponding target video is acquired from the terminal or the server.

Step 302: from among decoder instances stored in the shared space, a target decoder instance that is adapted to the target video is determined.

Referring to fig. 7B, fig. 7B is a flowchart illustrating a method for determining an instance of a target decoder according to an embodiment of the present invention, and in some embodiments, step 302 shown in fig. 7A may be implemented by steps 3021 to 3022 shown in fig. 7B:

Step 3021: and acquiring configuration parameters of decoder examples stored in a shared space and video parameters of the target video.

Step 3022: and determining the decoder instance corresponding to the configuration parameter matched with the video parameter as a target decoder instance matched with the target video.

Here, adaptation refers to video size (width and height), encoding format, angle, and buffer size supported by the decoder configuration, and is compatible with the size, encoding format, angle, and buffer size of the target video. In actual implementation, it is determined whether the decoder instance is adapted to the target video by comparing the decoder configuration parameters to the video parameters of the target video. Generally, when the angle of the decoder configuration, the encoding format, and the angle and encoding format of the target video are the same, respectively, the decoder buffer size is greater than or equal to the buffer size of the target video, and the video width and height also satisfy a certain condition, the decoder instance is considered to be adapted to the target video.

For a decoder supporting adaptive playback capability, as long as the maximum video width of the configured decoder is equal to or greater than the video width of the target video and the maximum video height of the configured decoder is equal to or greater than the video height of the target video, the decoder instance is considered to be adapted to the target video. For decoders that do not support adaptive playback capability, the decoder instance is considered to be adaptive to the target video only if the video width and height of the configured decoder are exactly the same as the video width and height of the target video.

In some embodiments, prior to determining a target decoder instance that is adapted to the target video from among the decoder instances stored in the shared pool, the codec manager of the player further stores in the shared pool a decoder instance that is run when decoding the historical video in response to a switch video operation for the player; the historical video is a video played when the switching video operation video is received.

In practical implementation, the processor resources occupied by the decoder instance operated when the historical video is decoded can be kept, the decoder instance operated when the historical video is decoded is migrated from the memory space which is originally occupied to the memory space corresponding to the shared pool, and the memory space which is originally occupied is released, so that the shared pool in the mode does not occupy the special memory space in the RAM; or the decoder operated when the historical video is decoded is mapped from the memory space which is originally occupied to the memory space corresponding to the shared pool without migration, and the shared pool in the mode can occupy a section of continuous memory space in the RAM.

In some embodiments, the player's codec manager may store decoder instances that are run when decoding historical video in the shared pool by:

Storing decoder resources corresponding to decoder examples called during decoding historical video and corresponding display interface output layers into a memory space of a shared pool; and the display interface output layer displays the received media data according to the decoding result.

Here, the decoder resource is generated by instantiation, including an object created correspondingly in memory space for each class in the code of the decoder.

In some embodiments, when the target decoder instance adapted to the target video is not stored in the shared pool, the server also initializes and invokes a new decoder instance adapted to the target video and outputs the decoding result for presentation in the display interface of the player.

Here, the fact that the target decoder instance adapted to the target video is not stored in the shared pool means that the decoder instance is not stored in the shared pool, or that the stored decoder instance configuration parameter and the target video parameter do not satisfy the multiplexing condition.

Step 303: the target decoder instance in the shared pool is invoked to decode media data included in the target video.

Referring to fig. 7C, fig. 7C is a flowchart illustrating a method for invoking a target decoder instance according to an embodiment of the present invention, and in some embodiments, the target decoder instance in the call shared pool in step 303 shown in fig. 7A may be implemented by steps 3031-3032 shown in fig. 7C:

Step 3031: the codec manager of the player intercepts an application program interface of the decoder instance;

step 3032: the function of the intercepted application program interface is proxied through the proxy decoder instance that includes the same application program interface as the intercepted decoder instance.

Here, the proxy decoder instance has an interface that is fully consistent with the intercepted decoder instance, and the proxy decoder instance proxies the functionality of the original intercepted decoder instance.

In some embodiments, a target decoder instance in the shared space may be invoked to decode media data included in the target video by:

inserting preset type coding information into media data included in a target video to obtain edited media data, wherein the coding information comprises at least one of the following steps: a sequence parameter set; a picture parameter set; the target decoder instance in the shared space is invoked to decode the edited media data.

Here, when the decoder does not satisfy the multiplexing condition, processing may be performed as needed so that the decoder instance can understand the content of the new video, for example, before decoding the video, inserting decoding information such as a sequence parameter set (SPS, seque nce Parameter Sets), a picture parameter set (PPS, picture Parameter Set), etc., so that the decoder instance can understand that the video source is switched; or for a decoder supporting adaptive playing capability, if the maximum video width and height of the configured decoder is less than or equal to the video width and height of the video to be decoded, a special construction frame of 32 x 32 is inserted before the video to be decoded is decoded, so that the decoder can understand that the video source is switched; or call the refresh function flush () of the decoder to clear the buffer data of the previously decoded video.

Step 304: and outputting the decoding result of the media data to be presented in a display interface of the player.

In some embodiments, when the memory space occupied by the shared pool reaches the memory space threshold, the codec manager of the player also releases at least some decoder instances already stored in the shared pool until the number of decoder instances in the shared pool does not exceed the number threshold, or the memory space occupied by the shared pool does not exceed the memory space threshold.

Here, the memory space threshold may be a preset value; may be dynamically set according to the actual available memory space of the electronic device running the player, e.g. not exceeding 5% of the available memory space.

In some embodiments, the codec manager of the player may release at least some of the decoder instances already stored in the shared pool by: performing at least one of the following release operations: according to the first-in first-out mode, releasing decoder resources corresponding to decoder examples in the shared pool and corresponding display interface output layers; and according to the descending order of the frequency of the decoder in the shared pool used in the monitoring time, releasing the decoder resources corresponding to the decoder examples in the shared pool and the corresponding display interface output layers.

Here, when the shared pool is operated, its state is determined, and when it exceeds the maximum memory of the shared pool, the decoder therein is eliminated. The elimination policy may be set by itself, such as first in first out (FIFO, first Input First Output), which refers to first in decoder elimination followed by second in decoder elimination. The obsolete decoder is removed from the shared pool, actually freeing up memory occupied by the resources.

In addition, the least recently used (LRU, least Recently Used) algorithm, the least recently used (LFU, least frequently used), and the like may be adopted to eliminate the decoder resources and the corresponding display interface output layer corresponding to the least recently used or least recently used decoder instance in the shared pool for a predetermined period of time.

In some embodiments, when the player is initialized, or when the shared pool is empty during operation of the player, the codec manager of the player determines the decoder instances that satisfy the preload condition and preloads the decoder instances that satisfy the preload condition in the shared pool.

In some embodiments, the codec manager of the player may determine the decoder instance that satisfies the preload condition by: determining a decoder instance that satisfies at least one of the following preload conditions: the first decoder instances in the descending order of usage frequency; a plurality of decoder instances last invoked before the player was last turned off; a decoder instance adapted to the video type preferred by the player user.

Here, in consideration of the similarity of short videos, it is preferable to determine the decoder instance most frequently used in the latest preset time as the decoder instance satisfying the preload condition, or the decoder instance last called before the player was turned off last time as the decoder instance satisfying the preload condition, or the decoder instance of the video type conforming to the user preference of the player as the decoder instance satisfying the preload condition based on the portrait information of the user of the player.

In some embodiments, the codec manager of the player may also determine a decoder instance that satisfies the preload condition by: acquiring context characteristics related to a player and user characteristics of a player user; fusing the context features and the user features, and predicting the obtained fused features through the combination of a machine learning model to obtain preloading probabilities of a plurality of candidate decoder examples; preloading a plurality of candidate decoder instances in the descending order of preloading probability into a shared memory; wherein the contextual characteristics include at least one of: information of the video that the player has played; video switching frequency; wherein the information of the video includes at least one of: the type and name of the video; the available memory space of the player when playing the video.

And predicting the context characteristics such as information of videos played by the player or video switching frequency and the fusion characteristics of user characteristics of a player user by utilizing a machine learning technology to obtain preloading probabilities of a plurality of candidate decoder examples, and selecting candidate decoder examples with preloading probabilities exceeding a probability threshold to preload into the shared memory.

By the method, in the process of switching the player to play the target video, the decoder instance adapting to the target video is called from the shared pool, so that the decoder instance already instantiated by the player can be flexibly multiplexed, a new decoder instance does not need to be always re-created, and delay in video switching is effectively reduced.

In the following, an exemplary application of the embodiment of the present invention in a practical application scenario will be described.

Aiming at the problems that the switching process of video playing is time-consuming, the scheme based on ExoPlayer only can judge that the last decoder can not be multiplexed, and the time consumption of the initialization of the decoder is not required when video playing is switched due to the fact that the last decoder can not be multiplexed across players, and the like, the embodiment of the invention provides a video playing processing method, wherein a coder and decoder manager of a player responds to the switching video operation aiming at the player to acquire a target video of the switching video operation, and determines a target decoder instance matched with the target video from decoder instances stored in a shared pool; the target decoder instance in the shared pool is invoked to decode media data included in the target video and output the media data for presentation in a display interface of the player.

The video playing processing method provided by the embodiment of the invention is based on a cross-player decoder multiplexing scheme, and has a decoder sharing pool, multiplexing is considered from the global perspective, and due to the existence of the decoder sharing pool, a proper decoder can be preloaded in the sharing pool, so that the video playing processing method is more suitable for scenes of short video playing and switching of decoder examples. In selecting the decoder, more choices can be provided and more decisions can be made possible due to the shared pool concept that breaks through the player limitations.

According to the video playing processing method provided by the embodiment of the invention, in a scene of short video playing, as the short video is switched relatively frequently, the decoder self-adaptive playing characteristic is utilized, and when the next player plays, the proper decoder can be directly selected from the shared pool without initializing the decoder every time, so that the flow of the first frame of the video is optimized, the time required by the first frame is greatly reduced, and the video playing experience is finally optimized.

For example, referring to fig. 8A-8B, fig. 8A-8B are schematic interface diagrams of a video switching scenario provided by an embodiment of the present invention, as shown in fig. 8A-8B, when a user views a short video and switches from an a video shown in fig. 8A to a next video B, when stopping playing the a video, a decoder for the a video is not destroyed directly, but is put into a shared pool; when playing the B video, instead of directly reinitializing a new decoder instance, a suitable decoder instance is selected from the shared pool for multiplexing, thereby saving the time required for the first frame of the video. Likewise, when switching from the C video shown in fig. 8B to the next video D, the decoder for the C video is put into the shared pool when stopping playing the C video; when the D video starts to be played, a proper decoder instance is selected from the shared pool to be multiplexed, so that the time required by the first frame of the video is saved.

In practical application, when video switching is performed, the flow of multiplexing the decoder between videos is greatly changed, and then the description is continued with the video switching scenario of switching the a video to the B video shown in fig. 8A, and when the video is switched, the a player is stopped first, and then the B player is started to play, see fig. 9, fig. 9 is a schematic flow diagram of the cross-player multiplexing decoder provided by the embodiment of the present invention, and will be described with reference to fig. 9:

first, when the a player stops, the decoder is "reclaimed," where "reclaimed" refers to no more use of the decoder, and not to the memory space occupied by the freed decoder resources. In contrast, the decoder resources are reserved and the output layer (i.e., surface) of the bearing picture bound to the decoder is reserved, so that the picture of the video is rendered on the Surface. With the above "reclamation", the decoder of the a player is hosted by the global shared pool, and the state of the decoder is maintained.

Next, before the B player starts playing, an appropriate decoder is selected from the shared pool, where whether the decoder selected from the shared pool meets the multiplexing condition is determined to be appropriate, referring to fig. 10A, fig. 10A is a schematic diagram of the multiplexing condition of the decoder according to the embodiment of the present invention, and as shown in fig. 10A, the decoder configuration parameters are compared with the video parameters of the video to be decoded respectively to determine whether the decoder is appropriate for the video to be decoded. In practical implementation, when the angle configured by the decoder, the encoding format, and the angle and encoding format of the video to be decoded are the same, respectively, the buffer size of the decoder is greater than or equal to the buffer size of the video to be decoded, and the video width and height also meet certain conditions, the decoder is considered to be suitable for the video to be decoded.

Next, the parameter of video width and height will be described in two cases, referring to fig. 10B, fig. 10B is a schematic diagram of multiplexing conditions during adaptive playback provided by the embodiment of the present invention, and as shown in fig. 10B, for a decoder supporting adaptive playback capability, as long as the configured decoder has a maximum video width equal to or greater than the video width of the video to be decoded, and the configured decoder has a maximum video height equal to or greater than the video height of the video to be decoded, the decoder is considered to be suitable for the video to be decoded. Referring to fig. 10C, fig. 10C is a schematic diagram of multiplexing conditions during non-adaptive playing according to an embodiment of the present invention, as shown in fig. 10C, for a decoder that does not support adaptive playing capability, only if the video width and height of the configured decoder are identical to those of the video to be decoded, the decoder is considered suitable for the video to be decoded.

By the method, the proper decoder can be selected from the shared pool to decode the video to be decoded, and when the proper decoder cannot be found from the shared pool, a new decoder needs to be built by self.

Next, a description will be given of a shared pool, which is a multiplexing pool of managed decoders, generally, and is established when the APP is played, and is a storage structure similar to an array, and is stored in a memory. When the shared pool is operated, the state of the shared pool is judged, and when the shared pool exceeds the maximum memory of the shared pool, a decoder therein is eliminated. The elimination strategy can be set by itself, such as LRU algorithm, LFU algorithm, FIFO algorithm, etc. The obsolete decoder is removed from the shared pool, actually freeing up memory occupied by the resources.

Here, the maximum memory of the shared pool may be a preset value, for example, the maximum number of decoders, and the maximum value of memory space occupied by the decoders; the method can also be determined by the service logic of the player, for example, the method can be comprehensively determined according to the available memory space and the video switching times/frequency, and the parameters are positively correlated with the value of the memory size of the shared pool (at least one of the parameters can be adopted to establish a linear/nonlinear positive correlation relationship with the memory), so that the smoothness and the operation stability (the memory cannot overflow) during frequent switching are ensured.

When the shared pool is empty, i.e. when the player app is started, and video playing is not performed, in order to solve the time delay of video switching caused by the time spent by the subsequent player to acquire the decoder initialization, a pre-load is performed here, i.e. an instance of the decoder that may be used is created in advance, e.g. statistics of the historical number of times/frequency of use of different decoders, a descending order of the order, a part of the decoder instance that is adapted to the preferred video type is pre-loaded before the arrangement.

In practical applications, as to what type of decoder to preload, machine learning may be employed to predict, in particular, to obtain contextual characteristics associated with the player and user characteristics of the player user; fusing the context features and the user features, and predicting based on the fused features obtained by combining the machine learning model to obtain preloading probabilities of a plurality of candidate decoder examples; preloading a plurality of candidate decoder instances in the descending order of preloading probability into a shared memory; wherein the contextual characteristics include at least one of: information of the video that the player has played; video switching frequency; the information of the video includes at least one of: the type and name of the video; and the available memory space of the player is used for playing the video.

Referring to fig. 11, fig. 11 is a schematic diagram of an architecture of a class design provided by an embodiment of the present invention, as shown in fig. 11, an interception module intercepts an interface of an original decoder (MediaCodec), and a proxy decoder (TMediaC odec) proxies the original decoder (MediaCodec) functions; a proxy decoder management module (TCodecMan manager) globally manages a proxy decoder map (tmedulacodecmap), decoder multiplexing processing logic (ReuseHandler), policy configuration module (Policy), and configuration module (Config); the decoder wrapper module includes a decoder wrapper class (CodecWrapper) and a direct encoder wrapper class (DirectCodecWrappe r), the decoder wrapper class (CodecWrapper) including a video decoder wrapper class (VideoCodecWrap per) and an audio decoder wrapper class (AudioCodecWrapper). The decoder pools include a run pool (runingpool), a shared pool (KeepPool), and a recycle pool (recyleedpool). The function of each class will be described next.

Referring to fig. 12, fig. 12 is a schematic diagram of an alternative architecture of a video playing system according to an embodiment of the present invention, and as shown in fig. 12, the video playing system according to the embodiment of the present invention includes: the system comprises an interception module, a strategy configuration module, a coding and decoding management module, a decoder packaging module and a decoder pool, and is described one by one as follows:

1. Interception module

The interception module is composed of three parts of an agent decoder instance (TMediaCodec), a texture view controller (THookTe xtureView) and a third party interception library, and is mainly used for intercepting the interface of the original decoder instance (MediaCodec) and the function of the agent.

1) Proxy decoder (TMediaCodec): the function of proxy MediaCodec, which has an interface completely identical to the original decoder (MediaCodec), performs decoding.

2) Texture view controller (THookTextureView): the proxy original texture view controller (Textu view) ensures that the state of the output layer is not released when the output layer is unbinding by the player, because after the output layer is released, the state of the MediaCodec is abnormal and cannot be decoded again, namely cannot be reused again, so that the release time of the output layer needs to be controlled, and the normal decoding state of the MediaCodec is ensured.

3) Third party interception library: typically, the function of a proxy class requires that the class be replaced with a proxy class. The interception library can directly proxy the function of the class without code intrusion.

2. Policy configuration module

1) Elimination strategy: the memory size of the shared pool in the decoder pool is 2 by default, and when the decoder is full, the strategy needs to be eliminated, and the shared pool is FIFO by default and can be configured.

2) Decoder configuration strategy: mediaCodec is no longer configured directly from the parameters of the video, but from policies, in the configuration phase, to adapt to more video plays, here by default 2k video H264, H265 coding configurations, one each.

3. Agent decoder management module (tcodecananager)

1) Proxy decoder mapping: the original decoder instance (MediaCodec) and proxy decoder (tmedia codec) mappings are maintained, facilitating lookup.

2) Decoder allocation and reclamation: decoder allocation and reclamation is managed by tcodecananager, which determines to which player instance the decoder instance is allocated, and also when the decoder instance is reclaimed.

3) Decoder multiplexing processing logic: in some cases, due to the problem of model compatibility, processing is required before multiplexing, the specific processing mode can be seen in fig. 13, fig. 13 is a schematic operation diagram of the front multiplexing of the decoder provided in the embodiment of the present invention, as shown in fig. 13, the video and the audio in the target video are separated into the basic code streams, and when the decoder meets the multiplexing condition, the decoder directly multiplexes without special processing; when the decoder does not meet the multiplexing condition, processing can be performed according to the need so that the decoder instance can understand the content of the new video, for example, for a decoder supporting the adaptive playing capability, if the configured maximum video width height of the decoder is smaller than or equal to the video width height of the video to be decoded, by inserting a special structure frame of 32 x 32 before decoding the video to be decoded, the decoder can understand that the video source is switched; or the refresh function flush () of the decoder is called to clear the buffer data of the previously decoded video; alternatively, decoding information such as SPS, PPS, etc. is inserted before decoding the video so that the decoder instance can understand that the video source was switched. Likewise, the audio data is processed accordingly.

4. Monitoring module

The monitoring module is used for decoding failure generally if abnormality occurs in the whole process of the proxy MediaCodec function. The monitoring module records the site and reports the log.

5. Decoder packaging module

For wrapping MediaCodec, different wrapping classes are used in different situations.

1) Decoder wrapper class (CodecWrapper): the wrapper class of the decoder instance refers to the MediaCo dec, rather than the tmedia codec, the base class of all wrapper classes, including the decoder instance.

2) Multiplexing decoder wrapper class (ReuseCodecWrapper): package class of decoder instances with multiplexing capability.

3) Video decoder wrapper class (VideoCodecWrapper): for packaging of video decoders.

4) Audio decoder wrapper class (AudioCodecWrapper): for packaging of audio decoders.

5) Direct encoder wrapper class (DirectCodecWrapper), a wrapper class of decoder instances that are not multiplexed.

6. Decoder pool

1) Run pool (RunningPool): the mapping is stored in memory in the form of a key-value pair Map.

2) Shared pool (KeepPool): the unbundled decoder instance is reserved for multiplexing by other players.

Referring to fig. 14, fig. 14 is a schematic diagram of a module call relationship provided by an embodiment of the present invention, as shown in fig. 14, all places where MediaCodec is used in the embodiment of the present invention are replaced by proxy decoders (tmedico dec), and when in use, a decoder pool in the present scheme is globally managed by a proxy decoder management module (tcodecanager), and the target video processed by the video/audio decoder determines whether the original decoder can be reused or not by using a decoder multiplexing processing logic, and how to process a multiplexed decoder instance. In actual implementation, the proxy decoder management module maps the decoder instance bound with the output layer into the running pool, and when the decoder instance needs to be recycled and released, the decoder instance is not directly recycled but is stored into the shared pool for other players to use. The recovery period of the decoder instance, i.e. whether the decoder instance needs to be recovered, is determined by the shared pool. Typically, when the memory space occupied by the shared pool reaches a memory space threshold, it is necessary to reclaim some decoder instances stored in the shared pool until the number of decoder instances in the shared pool does not exceed a number threshold, or the memory space occupied by the shared pool does not exceed a memory space threshold. When the player App starts or the shared pool is empty in the running process of the player App, some decoder instances meeting the preloading condition can be preloaded into the shared pool, so that the shared pool is ensured to have reusable decoder instances all the time.

Referring to fig. 15, fig. 15 is a schematic diagram showing the video time consumption comparison provided by the embodiment of the invention, as shown in fig. 15, when the original scheme is not multiplexed, 95% of the machine decoder initialization time is within 200ms, and only 25% of the machine decoder initialization time is within 50 ms; and after multiplexing by using the scheme, the time required by 90% of machine decoders is within 22ms, and the time required by 99% of machine decoders is within 50 ms.

By the above manner, the video playing processing method provided by the embodiment of the invention has the following technical effects:

1. the first frame of the scheme has obvious optimizing effect

1) When the scheme is not used, the average initialization of all types of decoders needs 84ms, while the scheme takes only 8ms on average in the multiplexing process, and 76ms is saved.

2) On low-end models, the decoder initialization takes 200ms, whereas the present solution only takes 20ms.

2. The scheme has good portability, and is easy to be suitable for any Android platform and a player based on a MediaCodec decoder.

3. The scheme is decoupled from the players, and the decoder can be shared between the players.

4. The decoder can be selected from the shared pool before playing, more decoders are selected, and the multiplexing rate is improved.

Continuing with the description below of an exemplary architecture of the video playback processing device 555 implemented as a software module provided by an embodiment of the present invention, in some embodiments, as shown in fig. 6, the software modules stored in the video playback processing device 555 of the memory 540 may include: an acquisition module 5551, a determination module 5552, a call module 5553, and an output module 5554.

An acquisition module 5551, configured to respond to a switching video operation for a player, and acquire a target video of the switching video operation;

a determining module 5552 for determining a target decoder instance adapted to the target video from among decoder instances stored in the shared space;

a calling module 5553, configured to call the target decoder instance in the shared space to decode media data included in the target video;

an output module 5554, configured to output a decoding result of the media data for presentation in a display interface of the player.

In some embodiments, the apparatus further comprises a memory module,

Wherein the history video is a video played before the switching video operation is received.

In some embodiments, the storage module is further configured to store decoder resources corresponding to decoder instances invoked when decoding the historical video, and corresponding display interface output layers into a memory space of the shared space;

In some embodiments, the apparatus further comprises an initialization module,

In some embodiments, the device further comprises a release module,

The number of decoder instances in the shared pool does not exceed a number threshold, or the memory space occupied by the shared space does not exceed a memory space threshold.

In some embodiments, the release module is further configured to perform at least one of the following release operations:

In some embodiments, the apparatus further comprises a preloading module,

In some embodiments, the preloading module is further configured to determine a decoder instance that satisfies at least one of the following preloading conditions:

the first decoder instances in the descending order of usage frequency;

A decoder instance adapted to the preferred video type.

In some embodiments, the preloading module is further configured to obtain a context feature associated with the player and a user feature of a player user;

In some embodiments, the calling module is further configured to intercept an application program interface of the decoder instance;

In some embodiments, the determining module is further configured to obtain configuration parameters of the decoder instance stored in the shared space, and video parameters of the target video;

In some embodiments, the calling module is further configured to insert a preset type of encoding information into media data included in the target video, to obtain edited media data, where the encoding information includes at least one of the following: a sequence parameter set; a picture parameter set;

a memory for storing executable instructions;

In some embodiments, the computer includes various computing devices including smart terminals and servers, and the storage medium may be FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; but may be a variety of devices including one or any combination of the above memories.

In some embodiments, the executable instructions may be in the form of programs, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and they may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

As an example, the executable instructions may, but need not, correspond to files in a file system, may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a hypertext markup language (HTML, hyper Text Markup Language) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

As an example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices located at one site or, alternatively, distributed across multiple sites and interconnected by a communication network.

In summary, the video playing processing method provided by the embodiment of the invention has the following beneficial effects:

1. in the process of switching and playing the target video by the player, the decoder instance adapting to the target video is called from the shared pool, so that the instantiated decoder instance of the player can be flexibly multiplexed, a new decoder instance is not required to be always re-created, and the delay in video switching is effectively reduced;

2. the portability is good, and the method is easy to be suitable for a player of any Android platform based on a MediaCodec decoder;

3. the decoder can be shared among the players after being decoupled from the players, and the decoder can be selected in the shared pool before being played, so that more decoders are selectable, and the multiplexing rate is improved.

The foregoing is merely exemplary embodiments of the present invention and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and scope of the present invention are included in the protection scope of the present invention.

Claims

1. A video playback processing method, the method comprising:

when the player is initialized or the shared space is empty in the running process of the player, determining the decoder instance meeting the preloading condition, and

preloading the decoder instance meeting the preloading condition in the shared space;

responding to a video switching operation aiming at the player, and acquiring a target video of the video switching operation;

acquiring configuration parameters of decoder instances stored in the shared space and video parameters of the target video, wherein the shared space also stores decoder instances operated when decoding historical video, and the historical video is video played before receiving the switching video operation;

determining a decoder instance corresponding to the configuration parameter matched with the video parameter as a target decoder instance adapted to the target video;

Invoking the target decoder instance in the shared space to decode the edited media data, and

outputting the decoding result of the media data to be presented in a display interface of the player;

when the memory space occupied by the shared space reaches the memory space threshold, releasing at least part of decoder examples stored in the shared space until

The number of decoder instances in the shared space does not exceed a number threshold, or the memory space occupied by the shared space does not exceed a memory space threshold, where the memory space threshold is a preset value or dynamically set according to the actual available memory space of the electronic device running the player.

2. The method according to claim 1, wherein the method further comprises:

in response to a switch video operation for the player, a decoder instance that is run when decoding historical video is stored in the shared space.

3. The method of claim 2, wherein storing decoder instances that are run when decoding historical video in the shared space comprises:

Storing decoder resources corresponding to decoder examples called during decoding historical video and corresponding display interface output layers into a memory space of the shared space;

4. The method according to claim 1, wherein the method further comprises:

initializing and invoking a new decoder instance adapted to the target video when the target decoder instance adapted to the target video is not stored in the shared space, and

and outputting a decoding result to be presented in a display interface of the player.

5. The method of claim 1, wherein said releasing at least some decoder instances already stored in the shared space comprises:

performing at least one of the following release operations:

6. The method of claim 1, wherein the determining decoder instances that satisfy a preload condition comprises:

determining a decoder instance that satisfies at least one of the following preload conditions:

the first decoder instances in the descending order of usage frequency;

a decoder instance adapted to the preferred video type.

7. The method of claim 1, wherein the determining decoder instances that satisfy a preload condition comprises:

acquiring context characteristics related to the player and user characteristics of a player user;

fusing the context features and the user features, and predicting the obtained fused features through a machine learning model to obtain preloading probabilities of a plurality of candidate decoder examples;

preloading a plurality of candidate decoder instances preceding in a descending order of preloading probabilities into the shared space;

8. The method according to any of claims 1 to 7, wherein said invoking the target decoder instance in the shared space comprises:

an application program interface intercepting the target decoder instance;

the functionality of the intercepted application program interface is proxied through a proxy decoder instance that includes the same application program interface as the intercepted target decoder instance.

9. A video playback processing apparatus, the apparatus comprising:

the initialization module is used for determining decoder instances meeting the preloading conditions when the player is initialized or when a shared space is empty in the running process of the player, and preloading the decoder instances meeting the preloading conditions in the shared space;

the determining module is used for obtaining the configuration parameters of the decoder instances stored in the shared space and the video parameters of the target video, wherein the shared space also stores the decoder instances operated when the historical video is decoded, and the historical video is the video played before the switching video operation is received; determining a decoder instance corresponding to the configuration parameter matched with the video parameter as a target decoder instance adapted to the target video;

The calling module is used for inserting preset type coding information into the media data included in the target video to obtain edited media data, wherein the coding information comprises at least one of the following: a sequence parameter set; a picture parameter set; invoking the target decoder instance in the shared space to decode the edited media data;

the output module is used for outputting the decoding result of the media data to be presented in a display interface of the player;

and the releasing module is used for releasing at least part of decoder examples stored in the shared space when the memory space occupied by the shared space reaches a memory space threshold value until the number of the decoder examples in the shared space does not exceed a number threshold value, or the memory space occupied by the shared space does not exceed a memory space threshold value, wherein the memory space threshold value is a preset value or is dynamically set according to the actual available memory space of the electronic equipment running the player.

10. An electronic device for video playback processing, the device comprising:

a memory for storing executable instructions;

A processor configured to implement the video playback processing method of any one of claims 1 to 8 when executing the executable instructions stored in the memory.

11. A computer readable storage medium storing executable instructions for implementing the video playback processing method of any one of claims 1 to 8 when executed by a processor.