Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The invention is applied to the self-contained media player in the open operating system, and when a user installs an open operating system on the electronic equipment, such as an android system, the self-contained media player in the android system is also installed on the electronic equipment for the user to play media files such as audio and video.
The media player may be located in a separate media playing device based on an open operating system, or may be located in any electronic device with a media playing function based on an open operating system, including but not limited to a desktop computer, a smart phone, a palm computer, a tablet computer, a smart phone, and the like.
Fig. 1 is a flowchart illustrating a method for controlling a media player of an open os according to an embodiment of the present invention. Referring to fig. 1, the method includes:
step 101, when a media player is ready to play a media file, a user interface event processing thread and a user interface event queue are created, and the user interface event processing thread is started.
In an operating system, a Thread (Thread) refers to a single sequential control flow in a program, and multiple threads can be run simultaneously in a single program to perform different tasks in parallel, which is called multithreading. Multiple threads share data space, each thread has its own set of CPU registers and stacks, and the execution of a thread requires the use of the memory resources and CPU of the computer.
In this embodiment, a user interface event processing thread is created specifically for the media player to process user interface events. For example, in the android system, a new Thread is created by creating an instance of the Thread class. At the same time, a user interface event queue is created for the user interface event processing thread accordingly. The user interface event queue is a data structure for storing user interface events, and can store the user interface events according to the principle of first-in first-out, and the storage mode can be that the user interface events are connected in series in a linked list mode.
Step 102, when a user interface operation is received, writing a user interface event corresponding to the user interface operation into a user interface event queue, wherein the user interface event processing thread reads the user interface event from the user interface event queue in sequence and executes an operation corresponding to the user interface event.
The user interface events corresponding to the user interface operations include: the playback device may further include any one or any combination of start playback, pause playback, stop playback (i.e., end playback), forward playback, reverse playback, fast forward playback, and fast reverse playback. And writing the user interface events into a user interface event queue, and informing a user interface event processing thread to process. Then, the user interface event processing thread reads the foremost user interface event from the user interface event queue in sequence and executes the operation corresponding to the user interface event.
In an embodiment, the user interface operation includes various input operations performed by a user on an operation interface of the media player, and may also include user interface operations other than user operations, such as automatically stopping playing after the playing of the media file is finished. Fig. 2 is a schematic diagram of a user operation interface 200 according to an embodiment of the invention. A user may perform various operations on a media file on the user interface 200 while using the media player. As shown in fig. 2, a picture of a played media file is displayed in box 210, a duration "00: 45" and a total duration "05: 13" of the currently played media file are displayed in box 220, a progress of the playing is displayed in box 230, a button 240 is provided for a user to slide to position the played file to other positions, various operation buttons are provided in box 250, such as play, pause, fast forward, fast backward, and when the media file is completely played, the playing is stopped. Alternatively, the user operation interface 200 may not display various operation buttons in the box 250, and may receive a user operation according to a gesture operation of the user.
In this embodiment, when the media player is ready to play a media file, a user interface event processing thread and a user interface event queue are created, and the user interface event processing thread is started, and when a user interface operation is received, a user interface event corresponding to the user interface operation is written into the user interface event queue, wherein the user interface event processing thread reads the user interface event from the user interface event queue in sequence and executes the operation corresponding to the user interface event, which can avoid directly calling a player kernel to execute the user interface event in the prior art, but allocates the user interface event to a special user interface event processing thread for processing, can improve the CPU utilization, effectively reduce the occurrence of errors such as play failure, errors, no response, and the like, and simplify the programming model, and improve the development efficiency of software developers, the development cost is reduced.
Fig. 3 is a flowchart illustrating a method for controlling a media player of an open os according to another embodiment of the present invention. Referring to fig. 3, the method includes:
step 301, when the media player is ready to play a media file, a user interface event processing thread and a user interface event queue are created, and the user interface event processing thread is started.
Step 301 is the same as step 101, and will not be described herein again.
Step 302, when the media player is ready to play a media file, a play position management thread is created and started, wherein the play position management thread reads the current play position of the media file and stores the read play position in the memory.
When a media player is ready to play a media file, after the data of audio, video, characters and the like related to the media file is ready, a play position management thread is created, and the play position management thread is started at the same time.
In an embodiment, the playing position management thread reads the current playing position of the media file every predetermined time, and updates the playing position stored in the memory to the currently read playing position. For example, the predetermined time may be 200 milliseconds, so that the play position management thread reads the current play position of the media file every 200 milliseconds and updates the play position stored in the memory. In specific application, the value of the preset time can be set according to the requirement. The information of the playing position may refer to a current playing time of the media file.
As shown in the interface of fig. 2, the play position management thread reads the current play position of the media file, and when the media file is being played, the play position management thread may read the time length of playing the media file, for example, the position indicated by the button 240, every 200ms, and then store the time length in the memory. When the next playing position is read, the last playing position stored in the memory is updated to the currently read playing position. If the media file is paused or stopped playing, the playing position management thread reads the playing position of the media file every 200ms to be the same value.
Step 303, the media player accesses the memory, obtains the playing position, and outputs the playing position through the user interface.
After the play position management thread finishes reading and storing the play position in step 302, the media player may directly obtain the play position from the system memory and then display the play position on the user interface. For example, the acquired current play position, i.e., "00: 45", is displayed in a time-length manner in block 220 shown in fig. 2.
Step 304, when a user interface operation is received, writing a user interface event corresponding to the user interface operation into a user interface event queue, and setting a corresponding predetermined waiting time for each user interface event, wherein the user interface event processing thread reads the user interface events from the user interface event queue in sequence and executes the operation corresponding to the user interface event.
In one embodiment, after setting the corresponding predetermined waiting time for each user interface event, the user interface event processing thread may perform the corresponding operation by calling the function corresponding to the user interface event and then returning the function within the predetermined waiting time corresponding to the user interface event. If the user interface event processing thread finishes the operation corresponding to the user interface event within the preset waiting time, immediately returning to the called function; if the user interface event processing thread still executes the operation corresponding to the user interface event when the preset waiting time is over, the called function is returned.
For example, in the android system, the maximum waiting time of the system is 5 seconds, and the predetermined waiting time may be set to 2 seconds. If the user interface event is a stop (stop) play, the user interface event processing thread calls the stop function to stop playing the media file and temporarily release the resources. If the stop function completes the operation within 2 seconds, returning immediately; if the execution time reaches 2 seconds, the stop function is still executed, and the function is returned.
In step 305, the user interface event processing thread and the play position management thread are deleted when the media player is detected to be in a stopped state, an error state, or turned off.
The media player may periodically detect the state in which it is in. The state of the media player includes a ready state, a play state, a pause state, a stop state, a locate state (the player locates to a certain play position), a release state (the resource occupied by the player is released), an error state, a recovery state (the player recovers from the error state), and the like. And if the media player is detected to be in a stop state or an error state, or the user is detected to close the media player, deleting the user interface event processing thread and the playing position management thread. Then, when the media file is played next time, a user interface event processing thread and a playing position management thread are created again.
In this embodiment, when a media player prepares to play a media file, a play position management thread is created and started, where the play position management thread reads a current play position of the media file and stores the read play position in a memory, and the media player accesses the memory to obtain the play position. Compared with the prior art, the scheme provided by the embodiment of the invention can quickly acquire the playing position by directly accessing the memory without calling the kernel of the player, thereby reducing the error state of no response of the program and reducing the playing error rate. In addition, the corresponding preset waiting time is set for each user interface event, the user interface event processing thread executes the operation corresponding to the user interface event and returns within the preset waiting time corresponding to the user interface event, the execution time of the user interface event processing thread on each user interface event can be effectively controlled, the time delay of the media player executing the user operation is further effectively controlled, and the accuracy and the success rate of executing the subsequent user operation are improved. For example, when the user interface event is a stop event, the release of the media player resource can be ensured as much as possible, and the problem that the last played resource is not released completely in the current playing is reduced.
Fig. 4 is a schematic structural diagram of a media player 400 according to an embodiment of the invention. The media player 400 includes:
a creating module 410, configured to create a user interface event processing thread and a user interface event queue when the media player is ready to play a media file;
a starting module 420, configured to start a user interface event processing thread;
a receiving module 430, configured to receive a user interface operation, and trigger a user interface event corresponding to the user interface operation to the writing module 440 whenever a user interface operation is received; and
a writing module 440 for writing a user interface event into the user interface event queue whenever the user interface event is received from the receiving module 430; the user interface event processing thread reads the user interface events from the user interface event queue in sequence and executes the operation corresponding to the user interface events.
Fig. 5 is a schematic structural diagram of a media player 500 according to another embodiment of the invention. Wherein,
the creating module 410 is further configured to create a play position management thread when the media player is ready to play a media file;
a starting module 420, further configured to start a play position management thread; the playing position management thread reads the current playing position of the media file and stores the read playing position in the memory.
In an embodiment, the playing position management thread reads the current playing position of the media file every predetermined time, and updates the playing position stored in the memory to the currently read playing position.
Accordingly, the media player 500 is based on the media player 400 shown in fig. 4, and further includes:
the access module 450 is configured to access a memory and obtain a playing position;
and an output module 460, configured to output the playing position obtained by the access module 450 through a user interface.
In one embodiment, the media player 500 further comprises:
a setting module 470 for setting a corresponding predetermined waiting time for each user interface event; the execution of the operation corresponding to the user interface event by the user interface event processing thread comprises the following steps: the user interface event processing thread calls a function corresponding to the user interface event; the function is returned within a predetermined wait time corresponding to the user interface event.
In one embodiment, the media player 500 further comprises:
a detection module 480, configured to detect a state of the media player;
a deleting module 490, configured to delete the user interface event processing thread and the playing position management thread when the detecting module 480 detects that the media player is in a stopped state, an error state, or is turned off.
Fig. 6 is a schematic structural diagram of a media player 600 according to another embodiment of the invention. The media player 600 includes: a processor 610, a memory 620, a port 630, and a bus 640. The processor 610 and the memory 620 are interconnected by a bus 640. The processor 610 may receive and transmit data through the port 630. Wherein,
the processor 610 is configured to execute modules of machine-readable instructions stored by the memory 620.
Memory 620 stores modules of machine-readable instructions executable by processor 610. The processor 610 may execute modules of instructions including: a creation module 621, an activation module 622, a reception module 623, and a writing module 624. Wherein,
the creation module 621, when executed by the processor 610, may be to: when a media player is ready to play a media file, a user interface event processing thread and a user interface event queue are created;
the initiating module 622, when executed by the processor 610, may be: starting a user interface event processing thread;
the receiving module 623, when executed by the processor 610, may be: receiving a user interface operation, and triggering a user interface event corresponding to the user interface operation to the writing module 440 whenever a user interface operation is received;
the write module 624 when executed by the processor 610 may be: writing a user interface event into the user interface event queue whenever the user interface event is received from the receiving module 430; the user interface event processing thread reads the user interface events from the user interface event queue in sequence and executes the operation corresponding to the user interface events.
In an embodiment, the creating module 621, when executed by the processor 610, may further be: when a media player prepares to play a media file, a play position management thread is established;
the initiating module 622, when executed by the processor 610, may further be: starting a play position management thread; the playing position management thread reads the current playing position of the media file and stores the read playing position in the memory.
Accordingly, the memory 620 stores instruction modules executable by the processor 610 that further include:
an access module 625, configured to access the memory and obtain a playing position;
an output module 626, configured to output the playing position obtained by the accessing module 625 through the user interface.
In one embodiment, the memory 620 stores instruction modules executable by the processor 610, further comprising:
a setting module 627 for setting a corresponding predetermined wait time for each user interface event; the execution of the operation corresponding to the user interface event by the user interface event processing thread comprises the following steps: the user interface event processing thread calls a function corresponding to the user interface event; the function is returned within a predetermined wait time corresponding to the user interface event.
In one embodiment, the memory 620 stores instruction modules executable by the processor 610, further comprising:
a detection module 628, configured to detect a state of the media player;
a deleting module 629 for deleting the user interface event processing thread and the play position management thread when the detecting module 628 detects that the media player is in a stop state, an error state, or is turned off.
It can be seen that the various functions of the creation module 621, the activation module 622, the reception module 623, the writing module 624, the accessing module 625, the output module 626, the setting module 627, the detecting module 628 and the deleting module 629 of the various embodiments described above can be implemented when the modules of instructions stored in the memory 620 are executed by the processor 610.
In the above device embodiment, the specific method for each module and unit to implement its own function is described in the method embodiment, and is not described herein again.
In addition, functional modules in the embodiments of the present invention may be integrated into one processing unit, or each module may exist alone physically, or two or more modules are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
In addition, each of the embodiments of the present invention can be realized by a data processing program executed by a data processing apparatus such as a computer. It is clear that the data processing program constitutes the invention. Further, the data processing program, which is generally stored in one storage medium, is executed by directly reading the program out of the storage medium or by installing or copying the program into a storage device (such as a hard disk and/or a memory) of the data processing device. Such a storage medium therefore also constitutes the present invention. The storage medium may use any type of recording means, such as a paper storage medium (e.g., paper tape, etc.), a magnetic storage medium (e.g., a flexible disk, a hard disk, a flash memory, etc.), an optical storage medium (e.g., a CD-ROM, etc.), a magneto-optical storage medium (e.g., an MO, etc.), and the like.
The invention therefore also discloses a storage medium in which a data processing program is stored which is designed to carry out any one of the embodiments of the method according to the invention described above.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.