CN108966000B - Playing method and device, medium and terminal thereof - Google Patents

Playing method and device, medium and terminal thereof Download PDF

Info

Publication number
CN108966000B
CN108966000B CN201810784760.4A CN201810784760A CN108966000B CN 108966000 B CN108966000 B CN 108966000B CN 201810784760 A CN201810784760 A CN 201810784760A CN 108966000 B CN108966000 B CN 108966000B
Authority
CN
China
Prior art keywords
data
data packet
played
packet
packets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810784760.4A
Other languages
Chinese (zh)
Other versions
CN108966000A (en
Inventor
方君君
陈飞
杨松帆
黄琰
张邦鑫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Century TAL Education Technology Co Ltd
Original Assignee
Beijing Century TAL Education Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Century TAL Education Technology Co Ltd filed Critical Beijing Century TAL Education Technology Co Ltd
Priority to CN201810784760.4A priority Critical patent/CN108966000B/en
Publication of CN108966000A publication Critical patent/CN108966000A/en
Application granted granted Critical
Publication of CN108966000B publication Critical patent/CN108966000B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H04N21/4398—Processing of audio elementary streams involving reformatting operations of audio signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H04N21/4394—Processing of audio elementary streams involving operations for analysing the audio stream, e.g. detecting features or characteristics in audio streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440218—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

The embodiment of the invention discloses a playing method, a device, a medium and a terminal thereof, wherein the playing method comprises the following steps: inserting null data packets between data packet sets, wherein the coding modes of the data packets in one data packet set are the same; and decoding the data packets in the data packet set by combining the positions of the empty data packets to obtain playing data suitable for playing. The technical scheme in the embodiment of the invention can improve the continuity of the video switching playing and solve the problem of screen blacking during the video switching playing.

Description

Playing method and device, medium and terminal thereof
Technical Field
The present invention relates to the field of internet technologies, and in particular, to a playing method, an apparatus, a medium, and a terminal thereof.
Background
With the development of science and technology and the improvement of the living standard of people, video works become an irreplaceable important mode for work, study, social contact and leisure and entertainment of people, and the requirement of people on video playing is higher and higher.
Currently, when a user needs to continuously play a plurality of videos, the video files to be played need to be added to a play list of a player and played in sequence. When the packaging formats of a plurality of video files are different, the player needs to exchange different decoders according to the video information to decode and play the video. However, in the process of switching decoders, the continuity of the connection of the front and rear videos is poor, and even a short black screen appears, so that the video playing is interrupted, and the user experience is seriously influenced.
The continuity of the switching playing between the existing videos needs to be improved.
Disclosure of Invention
The technical problem solved by the embodiment of the invention is to improve the continuity of video playing.
To solve the foregoing technical problem, an embodiment of the present invention provides a playing method, including: inserting null data packets between data packet sets, wherein the coding modes of the data packets in one data packet set are the same; decoding the data packets in the data packet set in combination with the position of the null data packet to obtain playing data suitable for playing, wherein decoding the data packets in the data packet set in combination with the position of the null data packet includes:
judging whether the data packet is an empty data packet or a non-empty data packet;
when the data packet is a non-empty data packet, decoding the non-empty data packet by using a decoder to obtain the playing data, wherein the decoder corresponds to the file header information of the file to be played;
when the data packet is a null data packet, a decoder required to decode a next data packet is determined.
Optionally, before inserting a null data packet between the data packet sets, the method further includes: and decapsulating the plurality of files to be played to obtain data packets in the files to be played, wherein the data packets in each file to be played are divided into one or more data packet sets.
Optionally, the data packets are divided into an audio data packet set and a video data packet set according to data types.
Optionally, the inserting null packets between the packet sets includes: storing a data packet set obtained by de-encapsulating a plurality of files to be played into one or a plurality of data packet queues; empty packets are inserted between the packet sets of the packet queue.
Optionally, the storing the data packet set obtained by decapsulating the plurality of files to be played into one or more data packet queues includes at least one of the following: storing the audio data packet set obtained by decapsulation into an audio data packet queue; and storing the video data packet set obtained by de-encapsulation into a video data packet queue.
Optionally, storing the data packet set obtained by decapsulating the plurality of files to be played into one or more data packet queues includes: determining that the number of packets stored in the packet queue does not exceed the upper limit of the capacity of the stored packet queue.
Optionally, the decapsulating the plurality of files to be played includes: acquiring the file to be played, wherein the file to be played comprises file header information and original file data; and reading the file header information to determine a corresponding demultiplexer, wherein the demultiplexer is used for de-encapsulating the original file data.
Optionally, the original file data includes at least one of audio data and video data, and the data packet set includes at least one of an audio data packet set and a video data packet set, where the audio data packet set includes data packets of an audio data portion obtained by decapsulating the file to be played, and the video data packet set includes data packets of a video data portion obtained by decapsulating the file to be played.
Optionally, the decapsulating the plurality of files to be played includes: and the decapsulation thread decapsulates the files to be played in sequence according to a preset sequence.
Optionally, the data packet is determined to be an empty data packet or a non-empty data packet by determining whether the position information of the data packet is greater than or equal to zero.
Optionally, after decoding the non-null data packet, the method further includes: and adding the playing data obtained by decoding the non-empty data packets to one or more queues to be played according to a decoding sequence to wait for playing.
Optionally, adding the play data obtained by decoding the non-empty data packet to one or more queues to be played according to a decoding order includes: determining that the amount of the playing data added to the queue to be played does not exceed the upper limit of the capacity of the queue to be played.
Optionally, the data packet includes an audio data packet and a video data packet, the playing data includes audio sampling data and video frame data, and the queue to be played includes an audio sampling data queue and a video frame data queue; the adding the playing data obtained by decoding the non-empty data packets to one or more queues to be played according to a decoding order includes at least one of the following: adding the audio sample data obtained by decoding the audio data packet to the audio sample data queue; and adding the video frame data obtained by decoding the video data packet to the video frame data queue.
Optionally, decoding the audio data packet and decoding the video data packet are performed in parallel by different threads.
Optionally, the playing data includes audio sampling data and video frame data, and after the playing data suitable for playing is obtained, the method further includes: synchronizing the audio sample data and video frame data; and outputting the audio sampling data and the video frame data to run playing.
An embodiment of the present invention further provides a playing device, which is characterized by including: the data packet transmission device comprises an insertion unit, a transmission unit and a decoding unit, wherein the insertion unit is suitable for inserting null data packets among data packet sets, and the data packets in one data packet set are encoded in the same mode; a decoding unit, adapted to decode the data packets in the data packet set in combination with the positions of the null data packets to obtain playing data suitable for playing, the decoding unit includes:
a data packet judging subunit, adapted to judge whether the data packet is an empty data packet or a non-empty data packet;
the decoding subunit is suitable for decoding the non-empty data packet by using a decoder to obtain the playing data when the data packet is the non-empty data packet, wherein the decoder corresponds to the file header information of the file to be played;
and the switching subunit is suitable for determining a decoder required for decoding the next data packet when the data packet is a null data packet.
Optionally, the method further includes: and the decapsulation unit is suitable for decapsulating a plurality of files to be played to obtain data packets in the files to be played before inserting empty data packets between the data packet sets, wherein each data packet in the files to be played is divided into one or more data packet sets.
Optionally, the insertion unit includes: the data packet storage subunit is suitable for storing a data packet set obtained by de-encapsulating a plurality of files to be played into one or a plurality of data packet queues; an inserting subunit, adapted to insert null packets between the sets of packets of the packet queue.
Optionally, the decapsulating unit includes: the data file acquisition subunit is suitable for acquiring the file to be played, and the file to be played comprises file header information and original file data; and the header information reading subunit is suitable for reading the file header information to determine a corresponding demultiplexer, and the demultiplexer is used for decapsulating the original file data.
Optionally, the decoding unit includes: a data packet judging subunit, adapted to judge whether the data packet is an empty data packet or a non-empty data packet; the decoding subunit is suitable for decoding the non-empty data packet by using a decoder to obtain the playing data when the data packet is the non-empty data packet, wherein the decoder corresponds to the file header information of the file to be played; and the switching subunit is suitable for determining a decoder required for decoding the next data packet when the data packet is a null data packet.
Optionally, the method further includes: and the playing data adding unit is suitable for decoding the non-empty data packets, and then adding the playing data obtained by decoding the non-empty data packets to one or more queues to be played according to a decoding sequence to wait for playing.
Optionally, the data packet includes an audio data packet and a video data packet, the playing data includes audio sampling data and video frame data, and the queue to be played includes an audio sampling data queue and a video frame data queue; the playing data adding unit comprises at least one of the following sub-units: an audio data adding subunit, adapted to add the audio sample data obtained by decoding the audio data packet to the audio sample data queue; and the video data adding subunit is suitable for adding the video frame data obtained by decoding the video data packet to the video frame data queue.
Embodiments of the present invention further provide a computer-readable storage medium, on which computer instructions are stored, and when the computer instructions are executed, the steps of the playing method are executed.
The embodiment of the present invention further provides a terminal, which includes a memory and a processor, where the memory stores a computer instruction capable of running on the processor, and the processor executes the step of the playing method when running the computer instruction.
Compared with the prior art, the technical scheme of the embodiment of the invention has the following beneficial effects:
in the embodiment of the invention, the empty data packets are inserted among the data packet sets, and the data files are decoded by combining the positions of the empty data packets to obtain the video data suitable for playing. Therefore, the invention inserts a null data packet between the data packet sets to distinguish the different data packet sets of the front and back data packets of the null data packet. Therefore, in the embodiment of the present invention, in response to reading the null data packet, the decoder corresponding to the next data packet is switched to, that is, in the embodiment of the present invention, the decoder required by the next data packet can be determined in the decoding process. Compared with the method for determining the decoder when the file to be played where the data packet is located is read every time, the method for determining the decoder in the embodiment of the invention has higher efficiency in the process of determining the decoder, thereby ensuring the normal operation of the decoding process and solving the problem of the black screen phenomenon when the video is switched and played.
Furthermore, after decapsulation, the data packets obtained by decapsulation are stored in the data packet queue and sequentially stored according to the decapsulation sequence, so that the decoding threads can decode according to the sequence, the decoding threads can be supported to determine the decoder of the next data packet set when reading empty data packets according to the corresponding sequence, the decoder required by the next decoded data packet set can be obtained in advance, and the playing effect can be improved.
Further, after the data packet set obtained by de-encapsulation is stored in a data packet queue, the number of the data packets stored in the data packet queue is determined not to exceed the upper limit of the capacity of the stored data packet queue, and the situation that the data packets obtained by de-encapsulation are lost due to the fact that the data files continue to be de-encapsulated after the data packets exceed the upper limit of the capacity is avoided, so that the playing effect is influenced.
Furthermore, by decoding the data packet in advance and adding the decoded playing data to the queue to be played, the decoding does not need to be waited during playing, the continuity of video playing is improved, and the user experience is further improved.
Drawings
FIG. 1 is a flow chart of a playing method according to an embodiment of the present invention;
FIG. 2 is a flow chart of an embodiment of the present invention for decapsulating data files;
FIG. 3 is a flow chart of inserting null packets in an embodiment of the present invention;
FIG. 4 is a flow chart of a method for storing data packets into a data packet queue according to an embodiment of the present invention;
FIG. 5 is a flowchart of decoding a file to be played in an embodiment of the present invention;
FIG. 6 is a flow chart of decoding a data packet according to an embodiment of the present invention;
FIG. 7 is a flowchart illustrating storing playback data in a queue to be played according to an embodiment of the present invention;
FIG. 8 is a flow chart of decoding a data packet in accordance with an embodiment of the present invention;
FIG. 9 is a flowchart illustrating playing a file to be played according to an embodiment of the present invention;
fig. 10 is a schematic structural diagram of a playback device according to an embodiment of the present invention;
FIG. 11 is a schematic structural diagram of an insertion unit according to an embodiment of the present invention;
FIG. 12 is a diagram illustrating an embodiment of a structure of a packet storing subunit;
fig. 13 is a schematic structural diagram of a decapsulating unit according to an embodiment of the invention;
FIG. 14 is a block diagram of a decoding unit according to an embodiment of the present invention;
fig. 15 is a schematic structural diagram of a play data adding unit according to an embodiment of the present invention.
Detailed Description
As described in the background art, the continuity of the conventional video switching and playing needs to be improved.
In a video playing process, a de-packer and a decoder which are needed to be used are determined according to file header information of a file to be played, the de-packer de-packs an original data file to obtain data packets, and the data packets form one or more data packet sets. At decoding time, the data packet is decoded using the decoder obtained before the decapsulation. When a plurality of files to be played need to be played continuously, especially when the encoding modes of the plurality of files to be played are different, in order to perform decoding normally, decapsulation and decoding of the next file to be played need to be performed after the data packet obtained by one file to be played is decoded completely. Therefore, during playing, due to the interruption of the decoding process, short playing data are lost at the place where the front and back files to be played are connected, so that the phenomenon of screen blacking occurs, and the user experience is influenced.
In the embodiment of the present invention, empty packets are inserted between the data packet sets, and the data files are decoded according to the positions of the empty packets, so as to obtain video data suitable for playing. Therefore, the invention inserts a null data packet between the data packet sets to distinguish the different data packet sets of the front and back data packets of the null data packet. Compared with the scheme that the decapsulator and the decoder of the next file to be played are determined to perform decoding and decapsulation after the data packet of the previous file to be played is decoded, the invention inserts a null data packet between the data packet sets obtained by decapsulating the previous file to be played and switches to the decoder corresponding to the next data packet in response to reading the null data packet during decoding, that is, in the embodiment of the invention, the decoder required by the next data packet can be determined in the decoding process. Compared with the method for determining the decoder when the file to be played where the data packet is located is read every time, the method for determining the decoder in the embodiment of the invention has higher efficiency in the process of determining the decoder, thereby ensuring the normal operation of the decoding process and solving the problem of the black screen phenomenon when the video is switched and played.
In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in detail below.
Fig. 1 is a flowchart of a playing method in an embodiment of the present invention, which may specifically include the following steps:
step S11, inserting empty data packets among data packet sets, wherein the encoding modes of the data packets in one data packet set are the same;
step S12, decoding the data packets in the data packet set in combination with the positions of the null data packets to obtain the playing data suitable for playing.
The data packet set includes a plurality of data packets, and in a specific implementation, the data packet set may be derived from different files to be played, and the encapsulation formats of the different files to be played may be the same or different. The data packet set may be obtained by de-encapsulating a file to be played. Generally, the encoding formats of the data packets in one of the data packet sets are the same, and the encoding formats of the data packet sets obtained by decapsulating different files to be played may be the same or different. In specific implementation, the decoding is a reverse process of encoding, and the playing data suitable for playing is obtained by decoding the data packet formed after compression encoding.
In some application scenarios, because of the interaction between the teaching video recording and the teaching, a plurality of playing files need to be played continuously. When a plurality of playing files are played continuously, the playing files need to be decoded and unpacked. Since the recording time equipment may be different, the packaging format or the encoding format of the playing file may be different, the common packaging formats include MP4, FLA, AVI, etc., and the common encoding formats include ASCII, ANSI, GBK, GB2312, UTF-8, GB18030, UNICODE, etc. Thus, the encoding of the resulting data packets after decapsulation may be different. Because the decapsulator and the decoder need to be replaced when the playing file is switched, the playing data for playing is lost, and thus a short black screen appears.
In the embodiment of the invention, a plurality of data packet sets are obtained, the empty data packet is inserted between the data packet sets to distinguish different data packet sets of two adjacent data packets before the empty data packet, and the decoder is switched to be the decoder of the next data packet by judging the obtained empty data packet during decoding.
In a specific implementation, the decoder switching to the next packet can be implemented as follows.
The decoders obtained when reading the file to be played may be stored in a memory location or decoder list. When the storage bit or the decoder list only allows to store two decoders, a data packet obtained by decoding a first file to be played is stored according to the first decoder stored in the storage bit or the decoder list, and a decoder corresponding to decoding a second file to be played is stored in the storage bit or the decoder list. And when the second file to be played is read completely and the data packet obtained by the first file to be played is not decoded completely, stopping continuously reading the next file to be played. After the data packet obtained by the first file to be played is read, a decoder corresponding to the second file to be played in the storage location or decoder list is obtained to decode the data packet corresponding to the second file to be played, then the third file to be played is read, and the decoder corresponding to the third file to be played is stored in the storage location or decoder list. Switching from a decoder corresponding to a first file to be played to a decoder corresponding to a second file to be played may be by reading a null data packet inserted between the data packet sets of the two files to be played, i.e., when a null data packet is read, the decoder in the storage bit or decoder list is obtained. When a plurality of decoders can be stored in the storage bit or the decoder list, the storage sequence of the decoders corresponding to different files to be played is the same as the reading sequence of the files to be played, and the reading of the files to be played is not influenced by the speed of the decoding data packet.
With continued reference to fig. 1, before inserting null packets between the packet sets, may further include: step S13, decapsulating the multiple files to be played to obtain the data packets in the files to be played, where the data packets in each file to be played are divided into one or more data packet sets.
In a specific implementation, the file to be played may include video data and audio data, or the file to be played may include only video data or audio data. Therefore, the set of one or more packets formed by the packets obtained by decapsulating the file to be played may be used. Specifically, the packet set may be divided into an audio packet set and a video packet set according to different types of the decapsulated packets. Wherein the audio data packet set comprises one or more audio data packets, and the video data packet set comprises one or more video data packets.
In a specific implementation, the decapsulation of the file to be played may be in an independent thread, and the decapsulation thread may decapsulate the file to be played in sequence according to a preset order.
The preset order may be an order in which the user adds a plurality of files to be played to the player library. Specifically, the user selects the file to be played, adds the file to the player library, and decapsulates the file to be played according to the sequence of the file to be played in the player library in the decapsulation thread, so as to obtain the data packet.
Referring to fig. 2, in an implementation, decapsulating a plurality of files to be played may include:
step S21, obtaining the file to be played, wherein the file to be played comprises file header information and original file data;
and step S22, reading the file header information to determine a corresponding demultiplexer, where the demultiplexer is used to decapsulate the original file data.
In specific implementation, the description data is written into a file header of the original file data to obtain a complete file to be played, which includes the description data and the original file data, where the description data is the file header information. The process of writing description data to a file header is called encapsulation. Wherein the description data includes coding type, time, etc. As mentioned previously, common packaging formats are MP4, FLA, AVI, etc. De-encapsulation of files to be played in different encapsulation formats requires the use of de-multiplexers with different parameters, and the encapsulation format of the files to be played can be determined by reading the file header information of the files to be played, so that the de-encapsulator required to be used is determined.
In a specific implementation, the original file data includes at least one of audio data and video data, and the data packet set includes at least one of an audio data packet set and a video data packet set, where the audio data packet set includes data packets of an audio data portion obtained by decapsulating the file to be played, and the video data packet set includes data packets of a video data portion obtained by decapsulating the file to be played.
Specifically, a data packet obtained after decapsulating original file data including only audio data is an audio data packet, the audio data packet constitutes an audio data packet combination, a data packet obtained after decapsulating original file data including only video data is a video data packet, the video data packet constitutes a video data packet set, and correspondingly, if an original data file includes both audio data and video data, the data packet obtained after decapsulating includes an audio data packet and a video data packet, the audio data packet constitutes an audio data packet set, and the video data packet constitutes a video data packet set.
In a specific implementation, file header information is read, and a decoder for decoding the data packet is determined while a corresponding demultiplexer is determined. The retrieved decoders may be stored in a memory location or decoder list, which may store two or more decoders.
In a specific implementation, the data packets obtained by decapsulation may be stored in a data packet queue, and in order to distinguish that the data packets stored in the data packet queue belong to different files to be played, it is necessary to insert empty data packets between data packet sets of the data packet queue, specifically, referring to fig. 3, the inserting empty data packets between the data packet sets may include:
step S31, storing the data packet set obtained by de-encapsulating a plurality of files to be played into one or a plurality of data packet queues;
in step S32, empty packets are inserted between the packet sets in the packet queue.
The queue is a special linear table, and only allows deletion operation at the front end of the table and insertion operation at the back end of the table.
By storing the obtained data packets into the data packet queue, when the data packets are decoded, the data packets can be obtained according to the decapsulation sequence for decoding, so that the correct data packet obtaining sequence is ensured, and the normal playing of video data and audio data is ensured.
As mentioned above, the data packet set includes a plurality of data packets, and the data packet set obtained by decapsulating a plurality of files to be played is stored in one or more data packet queues, which may be adding a data packet to a data packet queue after decapsulating the data packet, and then continuing decapsulating the data packet to obtain a next data packet. In other specific implementations, the data packet set obtained by decapsulating a plurality of files to be played is stored in one or more data packet queues, or the obtained data packets are added to the data packet queues after decapsulating a file with playback is completed.
In a specific implementation, inserting an empty data packet is to insert an empty data packet into a data packet queue after a file to be played is decapsulated, and perform decapsulation on a next data file after the empty data packet is inserted.
As mentioned above, the original data file may include audio data, video data or both audio data and video data, and thus, the set of decapsulated data packets may include one or more data packets, and the set of decapsulated data packets may be stored in one or more data packet queues. Specifically, referring to fig. 4, storing the data packet set obtained by decapsulating a plurality of files to be played into one or more data packet queues may include at least one of the following:
step S41, storing the audio data packet set obtained by decapsulation into an audio data packet queue;
and step S42, storing the video data packet set obtained by de-encapsulation into a video data packet queue.
In a specific implementation, if only an audio data packet is obtained after an original data file is decapsulated, the audio data packet constitutes an audio data packet set, an audio data packet in the obtained audio data packet set is stored in an audio data packet queue, if only a video data packet is obtained after the original data file is decapsulated, the video data packet constitutes a video data packet set, a video data packet in the obtained video data packet set is stored in a video data packet queue, if an audio data packet and a video data packet are obtained after the original data file is decapsulated, the audio data packet and the video data packet respectively constitute an audio data packet set and a video data packet set, and then the audio data packet and the video data packet in the obtained audio data packet set are respectively stored in the audio data packet queue and the video data packet queue.
Further, storing the set of packets obtained by decapsulating the plurality of files to be played into one or more packet queues may include: determining that the number of packets stored in the packet queue does not exceed the upper limit of the capacity of the stored packet queue. And if the data packet stored in the data packet queue exceeds the upper limit of the capacity of the stored data packet queue, stopping continuously unsealing the original data file.
Specifically, the original data file only comprises audio data, and only needs to confirm whether the audio data packet stored in the audio data packet queue after decapsulation exceeds the upper limit of the capacity of the audio data packet queue, if so, the original data file is stopped to be decapsulated continuously; only video data are included in the original data file, whether a video data packet stored in a video data packet queue after being unpacked exceeds the upper limit of the capacity of the video data packet queue is determined, and if the video data packet exceeds the upper limit of the capacity of the video data packet queue, the original data file is stopped being unpacked continuously; if the original data file comprises audio data and video data, whether the audio data packets stored in the audio data packet queue after being unpacked exceed the upper limit of the capacity of the audio data packet queue and whether the video data packets stored in the video data packet queue exceed the upper limit of the capacity of the video data packet queue need to be simultaneously confirmed, and if the audio data packets exceed the upper limit of the capacity of the audio data packet queue or the upper limit of the capacity of the video data packet queue, the original data file is stopped being unpacked continuously.
FIG. 5 is a flowchart for decoding a file to be played according to an embodiment of the present invention. This will be further explained with reference to fig. 1 to 5.
As shown in fig. 5, when the user needs to play a plurality of files to be played, the files to be played are obtained according to the set sequence, and step S51 reads the file header information of the files to be played, and determines the corresponding decapsulator and decoder. The file to be played comprises file header information and an original data file. The raw data file may include audio data and video data, or the raw data file may include only audio data or only video data.
Further, step S52 decapsulates the original data file. As mentioned above, when the original data file includes both video data and audio data, the audio data packets and the video data packets can be obtained by decapsulating, where the audio data packets form an audio data packet set, and the video data packets form a video data packet set. In other embodiments, only a set of audio packets or only a set of video packets may be obtained.
Further, the data packet is stored in the data packet queue in step S54. The data packet obtained by decapsulating the file to be played may be stored in the data packet queue. As previously mentioned, the decapsulated original data file may only result in audio data packets or video data packets. Therefore, the data packets obtained after the decapsulation are stored in the data packet queue, and only one of the audio data packet set obtained by the decapsulation and the video data packet set obtained by the decapsulation may be stored in the audio data packet queue and the video data packet set obtained by the decapsulation may be stored in the video data packet queue.
Further, step S55 determines whether the upper limit of the capacity of the packet queue is exceeded. After the obtained data packet is stored in the data packet queue, it is necessary to determine whether the data packet stored in the data packet queue exceeds the upper limit of the capacity of the stored data packet queue. Specifically, if the data packet stored in the data packet queue does not exceed the upper limit of the capacity of the stored data packet queue, the original data file continues to be encapsulated, and if the data packet in the data packet queue already exceeds the upper limit of the capacity of the data packet queue, the original data file stops being decapsulated continuously, and step S56 waits for the upper limit of the capacity of the data packet queue not to be exceeded.
In this embodiment, in the process of decapsulating the original data file, step S53 is further included to determine whether decapsulation of the original data file is completed. And if the original data file is not decapsulated, continuing decapsulating the original data file, storing the data packet obtained by decapsulation into a data packet queue, and if the original data file is decapsulated, inserting an empty data packet between data packet sets of the data packet queue. And reading the file head information of the next file to be played while inserting the empty data packet, and performing decapsulation operation on the next file to be played.
In a specific implementation, the playing data is decoded data, and with reference to fig. 1 and fig. 6, the decoding, in step S12, the packet in the packet set in accordance with the position of the null packet includes:
step S61, judging whether the data packet is an empty data packet or a non-empty data packet;
step S62, when the data packet is a non-empty data packet, decoding the non-empty data packet by a decoder to obtain the playing data, wherein the decoder corresponds to the file header information of the file to be played;
in step S63, when the data packet is a null data packet, a decoder required for decoding the next data packet is determined.
In a specific implementation, the null packet is a null structure, which is a null data structure. And judging whether the position information of the data packet is greater than or equal to zero or not, thereby judging whether the data packet is an empty data packet or a non-empty data packet. Specifically, when the position information of the acquired data packet is greater than or equal to zero, the acquired data packet is a non-empty data packet, and if the position information of the acquired data packet is less than zero, the acquired data packet is an empty data packet.
Whether the data packet is an empty data packet or not is judged to determine a decoder required for decoding the next data packet, so that the phenomenon of program collapse caused by the fact that the data packet is decoded by the wrong decoder is avoided, and the normal operation of the decoding process is guaranteed.
In specific implementation, when the obtained data packet is an empty data packet, it is determined that two data packets before and after the empty data packet belong to different files to be played, so as to determine a decoder required by a next data packet.
In a specific implementation of the present invention, an empty data packet is inserted between two data packet sets obtained after decapsulating the file to be played, and the encoding formats of data packets adjacent to the empty data packet may be the same or different. In the decoding process, when an empty data packet is acquired, the next data packet and the previous data packet are judged to belong to different files to be played, and a decoder corresponding to the next data packet is determined according to the sequence of storing the storage bits or the decoder list.
In another embodiment, the null data packets are inserted between the sets of data packets resulting from the decapsulation of the data files of the two different encoding formats. In the process of decoding the data packet, when the acquired numerical control packet is judged to be an empty data packet, it is determined that the decoder needs to be switched, specifically, the decoder is switched by acquiring the storage bit or the next decoder in the decoder list, so as to decode the next data packet.
By inserting the empty data packet between the two data packet sets with different coding formats, when the empty data packet is detected, the decoder is switched, whether the decoder needs to be replaced is not required to be determined, the system operation time is saved, and the decoding process is accelerated.
With continued reference to fig. 1, when the obtained data packet is a non-null data packet, after decoding the non-null data packet, the method may further include: step S14, adding the playing data obtained by decoding the non-empty data packets to one or more queues to be played according to the decoding order, so as to wait for playing.
Specifically, the adding of the playing data obtained by decoding the non-empty data packet to one or more queues to be played according to the decoding order may be adding the playing data obtained by decoding to the queues to be played after the decoding of a single data packet is completed, or adding the playing data obtained by decoding to the queues to be played while decoding the single data packet.
In a specific implementation, the data packets include audio data packets and video data packets, the playing data includes audio sample data and video frame data, the queue to be played includes an audio sample data queue and a video frame data queue, and with reference to fig. 1 and fig. 7, the adding, in step S14, the playing data obtained by decoding the non-empty data packets to one or more queues to be played according to a decoding order includes at least one of:
step S71, adding the audio sample data obtained by decoding the audio data packet to the audio sample data queue;
step S72, adding the video frame data obtained by decoding the video data packet to the video frame data queue.
The audio sampling data and the video frame data obtained by decoding are data obtained in the recording process of the file to be played.
In a specific implementation, decoding the audio data packets and decoding the video data packets are performed in parallel by different threads. The audio data packet is decoded to obtain audio sampling data, the obtained audio sampling data are added to the audio sampling data queue to be an independent thread, the video data packet is decoded to obtain video frame data, the obtained video frame data are added to the video frame data queue to be an independent thread, and the audio decoding thread and the video decoding thread are performed in parallel.
With continued reference to fig. 1, in a specific implementation, the adding, in step S14, the play data obtained by decoding the non-empty data packet to one or more queues to be played according to a decoding order may include: determining that the amount of the playing data added to the queue to be played does not exceed the upper limit of the capacity of the queue to be played.
As mentioned above, the playing data includes audio sampling data and video frame data, the queue to be played includes an audio sampling data queue and a video frame data queue, after the audio sampling data obtained by the decapsulation is added to the audio sampling data queue, it is necessary to determine whether the number of the audio sampling data in the audio sampling data queue exceeds the upper limit of the capacity of the audio sampling data queue, if the number exceeds the upper limit of the capacity, the audio data packet is stopped being decoded continuously, after the video frame data obtained by the decapsulation is added to the video frame data queue, it is necessary to determine whether the number of the video frame data in the video frame data queue exceeds the upper limit of the capacity of the video frame data queue, and if the number exceeds the upper limit of the capacity.
By judging whether the quantity of the playing data of the queue to be played exceeds the upper limit of the capacity of the queue to be played or not, and stopping continuously decapsulating the data packet when the quantity of the playing data of the queue to be played exceeds the upper limit of the capacity, the situation that the data packet is continuously decoded after the quantity of the playing data exceeds the upper limit of the capacity so that the decapsulated playing data is lost and the playing effect is influenced is avoided.
FIG. 8 is a flow chart of decoding a data packet according to an embodiment of the present invention. As will be further explained below in conjunction with fig. 8.
As shown in fig. 8, step S81 obtains a data packet from the data packet queue, and after obtaining the data packet, step S82 determines whether the data packet is an empty data packet, and in a specific implementation, determines that the data packet is a non-empty data packet by determining that the location information of the data packet is greater than or equal to zero, and the location information is less than zero, thereby determining that the data packet is an empty data packet. When it is determined that the data packet is a non-null data packet, step S83 decodes the non-null data packet by using a decoder to obtain the playing data. In a specific implementation, the decoder corresponds to file header information of a file to be played.
Further, after the non-empty data packet is decoded to obtain the play data, step S84 stores the play data in the queue to be played. In a specific implementation, the data packet may include an audio data packet and a video data packet, the audio data packet is decoded to obtain audio sample data, the video data packet is decoded to obtain video frame data, the audio sample data obtained by decoding is stored in an audio sample data queue, and the video frame data obtained by decoding is stored in a video frame data queue.
Further, after the decoded play data is stored in the queue to be played, step S85 determines whether the capacity upper limit of the queue to be played is exceeded. In a specific implementation, if the playing data added to the queue to be played does not exceed the upper limit of the capacity of the queue to be played, the data packet is decoded continuously according to the flow, and if the playing data added to the queue to be played already exceeds the upper limit of the capacity of the queue to be played, the data packet is stopped being decoded continuously, step S86 waits for the upper limit of the capacity of the queue to be played not to be exceeded, and then the data packet is decoded continuously.
In the present embodiment, in step S82, when the obtained data packet is an empty data packet, step S87 switches decoders, and the next data packet is decoded by the new decoder, and the switching of the decoders is as described above and will not be described herein again.
With continued reference to fig. 1, in another specific implementation, after obtaining the audio sample data and the video frame data suitable for playing, the playing method may further include:
step S15, synchronizing the audio sample data and the video frame data;
and step S16, outputting the audio sample data and the video frame data to run playing.
In a particular implementation, the audio sample data and the video frame data are synchronized by adjusting timestamps of the audio sample data and the video frame data. When the audio sampling data is played, the audio sampling data is actively acquired from the audio sampling data queue by the audio drive of the operating system, and the video frame data is sent to the display device for refreshing at a fixed time, so that the audio sampling data and the video frame data are played.
In the implementation of the invention, the audio and video sampling data and the video frame data are synchronized by adjusting the time stamps of the audio sampling data and the video frame data, so that the synchronous playing of the video and the audio played by the video is ensured, and the user experience is increased.
Fig. 9 is a flowchart of playing a file to be played in an embodiment of the present invention, which will be further described with reference to fig. 9.
As shown in fig. 9, according to the user requirement, step S91 obtains a file to be played, in a specific implementation, the file to be played may be multiple, and the multiple files to be played may have different packaging formats and encoding manners.
Further, step S92 decapsulates the file to be played. In specific implementation, a decapsulator is applied to decapsulate the acquired data to be played. The video data packet and the audio data packet can be obtained by de-encapsulating the file to be played. In a specific implementation, the file to be played includes file header information and original file data, and in conjunction with fig. 5, step S51 reads the file header information, and may determine a corresponding demultiplexer and a decoder, where the demultiplexer is used to decapsulate the original file data.
Further, the audio data packet and the video data packet obtained after decapsulation may be added to different data packet queues, that is, the audio data packet obtained after decapsulation is added to the audio data packet queue, and the video data packet obtained after decapsulation is placed in the video data packet queue. In a specific implementation, the decapsulated data packet may only include an audio data packet or a video data packet according to a file to be played, and thus, only the audio data packet may be added to the audio data packet queue or only the video data packet may be added to the video data packet queue.
Further, it is necessary to decode the audio data packet and the video data packet obtained after the decapsulation. Taking the example of decoding the video data packets, step S93 obtains the video data packets in the video data packet queue. In a specific implementation, the video data packets are stored in a video data packet queue according to the order obtained in the decapsulation process, and when the video data packets are decoded, the video data packets are obtained according to the stored order. After obtaining the video data packet from the video data packet queue, step S94 decodes the video data packet. Specifically, the decoder obtained during decapsulation is applied to decode the obtained video data packet to obtain video frame data suitable for playing.
Further, the playing data obtained by decoding may be stored in the queue to be played, and continuing with the process of decoding the video data packet as an example, step S95 stores the obtained video frame data in the video frame data queue.
In a specific implementation, decoding audio data packets and decoding video data packets are performed in parallel by different threads. The process of decoding audio data packets is similar to the process of decoding video data packets, and includes step S96 to obtain audio data packets in the audio data packet queue, step S97 to decode audio data packets, and step S98 to store audio sample data in the audio sample data queue, which is not described herein again for further explanation.
Further, before playing the decoded audio sample data and video frame data, step S99 is included to synchronize the audio sample data and the video frame data. Specifically, the audio sample data and the video frame data are synchronized by adjusting time stamps of the audio sample data and the video frame data.
Further, the synchronized audio sampling data and video frame data are played through a driver or a device. Specifically, the audio sampling data is actively acquired from the audio sampling data queue by the audio driver of the operating system, and the video frame data is sent to the display device for refreshing at a fixed time, so that the audio sampling data and the video frame data are played.
In one embodiment, the decapsulation is performed as an independent thread, the decoding of the audio data packet is performed as an independent thread, the decoding of the video data packet is performed as an independent thread, and the synchronization of the audio sample data and the video frame data and the playback of the audio sample data and the video frame data are performed as an independent thread. The four threads may run concurrently in parallel.
An embodiment of the present invention further provides a playing device, a schematic structural diagram of which is shown in fig. 10, and the playing device specifically includes:
an inserting unit 101, adapted to insert null packets between packet sets, where the packets in a packet set are encoded in the same manner;
a decoding unit 102, adapted to decode the data packets in the data packet set in combination with the positions of the null data packets to obtain playing data suitable for playing.
In a specific implementation, the data packet may be obtained by decapsulating data to be played, and the playing apparatus may further include:
a decapsulation unit 103, adapted to decapsulate a plurality of files to be played before inserting empty data packets between the data packet sets, to obtain data packets in the files to be played, where each data packet in the files to be played is divided into one or more data packet sets.
In specific implementation, the file to be played may include audio data and video data, and the data packet obtained after decapsulating the file to be played may be divided into an audio data packet set and a video data packet set according to the data type.
In a specific implementation, a plurality of files to be played are decapsulated in an independent thread, and the decapsulation thread decapsulates the plurality of files to be played in sequence according to a preset sequence.
With reference to fig. 10 and fig. 11 in combination, after de-encapsulating a plurality of files to be played, in order to distinguish between two adjacent data packets and the different data packet sets, it is necessary to insert a null data packet between the data packet sets, and in a specific implementation, the inserting unit 101 may include:
a data packet storing subunit 111, adapted to store a data packet set obtained by decapsulating a plurality of files to be played into one or more data packet queues;
an inserting subunit 112 adapted to insert empty data packets between the data packet sets of the data packet queue.
In other implementations, the insertion unit 101 may further include:
the packet queue determining subunit 113 is adapted to store the set of decapsulated packets into one or more packet queues, and then determine that the number of packets stored in the packet queues does not exceed the upper limit of the capacity of the stored packet queues.
Further, according to the difference of the files to be played, the obtained data packets are different, and referring to fig. 12, the data packet storing subunit 111 may include at least one of the following modules:
an audio data packet storing module 121, adapted to store the set of audio data packets obtained by decapsulation into an audio data packet queue;
the video data packet storing module 122 is adapted to store the set of video data packets obtained by decapsulation into a video data packet queue.
In a specific implementation, referring collectively to fig. 10 and fig. 13, the decapsulation unit 103 may include:
a data file obtaining subunit 131, adapted to obtain the file to be played, where the file to be played includes file header information and original file data;
a header information reading subunit 132, adapted to read the file header information to determine a corresponding demultiplexer, where the demultiplexer is used to decapsulate the original file data.
Further, the original file data may include at least one of audio data and video data, and the packet set may include at least one of an audio packet set and a video packet set, where the audio packet set may include packets decapsulating an audio data portion of the file to be played, and the video packet set may include packets decapsulating a video data portion of the file to be played.
In a specific implementation, the null data packet is located between the data packet sets, and the data packets in the data packet sets are decoded according to the location of the null data packet, and with reference to fig. 10 and fig. 14, the decoding unit 102 may include:
a data packet determining subunit 141, adapted to determine whether the data packet is an empty data packet or a non-empty data packet;
a decoding subunit 142, adapted to, when the data packet is a non-empty data packet, decode the non-empty data packet by using a decoder to obtain the playing data, where the decoder corresponds to file header information of a file to be played;
a switching subunit 143, adapted to determine a decoder required for decoding a next data packet when the data packet is a null data packet.
In a specific implementation, the packet determining subunit 141 may determine that the data packet is an empty data packet or a non-empty data packet by determining whether the position information of the data packet is greater than or equal to zero.
After obtaining the playing data suitable for playing through decoding, the playing data needs to be stored in the queue to be played to wait for playing, with reference to fig. 10, in another embodiment, the playing apparatus may further include:
the playing data adding unit 104 is adapted to decode the non-empty data packet, and then add the playing data obtained by decoding the non-empty data packet to one or more queues to be played according to a decoding order to wait for playing.
Further, the play data adding unit 104 may include: and the to-be-played queue capacity determining subunit is adapted to determine that the amount of the playing data added to the to-be-played queue does not exceed the to-be-played queue capacity upper limit. And if the number of the data packets in the queue to be played exceeds the upper limit of the capacity of the queue to be played, waiting and stopping continuously decoding the data packets.
With reference to fig. 10 and fig. 15 in combination, in a specific implementation, the data packet includes an audio data packet and a video data packet, the play data includes audio sample data and video frame data, and the queue to be played includes an audio sample data queue and a video frame data queue; the play data adding unit 104 includes at least one of the following sub-units:
an audio data adding subunit 151 adapted to add the audio sample data obtained by decoding the audio data packet to the audio sample data queue;
a video data adding subunit 152, adapted to add the video frame data obtained by decoding the video data packet to the video frame data queue.
Further, decoding the audio data packets and decoding the video data packets are performed in parallel by different threads.
With continued reference to fig. 10, in another specific implementation, after obtaining the audio sample data and the video frame data suitable for playing through decoding, the audio sample data and the video frame data need to be synchronized to output playing, where the playing apparatus further includes:
a synchronization unit 105 adapted to synchronize the audio sample data and video frame data, the playback data comprising the audio sample data and video frame data;
and the output unit 106 is suitable for outputting the audio sampling data and the video frame data so as to run playing.
The explanations, principles, specific implementations and advantageous effects of the terms related to the playing device in the embodiment of the present invention may refer to the playing method in the embodiment of the present invention, and are not described herein again.
The embodiment of the present invention further provides a computer-readable storage medium, on which computer instructions are stored, and when the computer instructions are executed, the steps of the playing method are executed. The computer readable storage medium may be an optical disc, a mechanical hard disk, a solid state hard disk, etc.
The embodiment of the present invention further provides a terminal, which includes a memory and a processor, where the memory stores a computer instruction capable of running on the processor, and the processor executes the steps of the foregoing playing method when running the computer instruction. The terminal can be a mobile phone, a computer, or other equipment capable of executing the playing method in the embodiment of the invention.
Although the present invention is disclosed above, the present invention is not limited thereto. Various changes and modifications may be effected therein by one skilled in the art without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (23)

1. A playback method, comprising:
inserting null data packets between data packet sets, wherein the coding modes of the data packets in one data packet set are the same;
decoding the data packets in the data packet set in combination with the positions of the null data packets to obtain playing data suitable for playing;
the decoding the data packets of the set of data packets in conjunction with the positions of the null data packets comprises:
judging whether the data packet is an empty data packet or a non-empty data packet;
when the data packet is a non-empty data packet, decoding the non-empty data packet by using a decoder to obtain the playing data, wherein the decoder corresponds to the file header information of the file to be played;
when the data packet is a null data packet, a decoder required to decode a next data packet is determined.
2. The playback method as claimed in claim 1, wherein before inserting the empty packet between the set of packets, the method further comprises: and decapsulating the plurality of files to be played to obtain data packets in the files to be played, wherein the data packets in each file to be played are divided into one or more data packet sets.
3. The playback method according to claim 2, wherein the data packets are divided into an audio data packet set and a video data packet set according to data types.
4. The playback method as claimed in claim 2, wherein the inserting empty packets between the data packet sets comprises:
storing a data packet set obtained by de-encapsulating a plurality of files to be played into one or a plurality of data packet queues;
empty packets are inserted between the packet sets of the packet queue.
5. The playback method according to claim 4, wherein storing the set of packets decapsulated from the plurality of files to be played back into one or more packet queues comprises at least one of:
storing the audio data packet set obtained by decapsulation into an audio data packet queue;
and storing the video data packet set obtained by de-encapsulation into a video data packet queue.
6. The playback method according to claim 4, wherein storing the set of packets decapsulated from the plurality of files to be played into one or more packet queues comprises: determining that the number of packets stored in the packet queue does not exceed the upper limit of the capacity of the stored packet queue.
7. The playback method according to claim 2, wherein the decapsulating the plurality of files to be played comprises:
acquiring the file to be played, wherein the file to be played comprises file header information and original file data;
and reading the file header information to determine a corresponding demultiplexer, wherein the demultiplexer is used for de-encapsulating the original file data.
8. The playback method according to claim 7, wherein the original file data includes at least one of audio data and video data, and the packet set includes at least one of an audio packet set and a video packet set, wherein the audio packet set includes packets of audio data portions obtained by decapsulating the file to be played, and the video packet set includes packets of video data portions obtained by decapsulating the file to be played.
9. The playback method according to claim 2, wherein the decapsulating the plurality of files to be played comprises: and the decapsulation thread decapsulates the files to be played in sequence according to a preset sequence.
10. The playback method as claimed in claim 1, wherein the data packet is determined to be a null data packet or a non-null data packet by determining whether the position information of the data packet is greater than or equal to zero.
11. The playback method as claimed in claim 1, further comprising, after decoding the non-null data packet: and adding the playing data obtained by decoding the non-empty data packets to one or more queues to be played according to a decoding sequence to wait for playing.
12. The playback method according to claim 11, wherein the adding the playback data obtained by decoding the non-empty data packets to one or more queues to be played back in decoding order comprises: determining that the amount of the playing data added to the queue to be played does not exceed the upper limit of the capacity of the queue to be played.
13. The playback method according to claim 11, wherein the data packets include audio data packets and video data packets, the playback data includes audio sample data and video frame data, and the queue to be played includes an audio sample data queue and a video frame data queue;
the adding the playing data obtained by decoding the non-empty data packets to one or more queues to be played according to a decoding order includes at least one of the following:
adding the audio sample data obtained by decoding the audio data packet to the audio sample data queue;
and adding the video frame data obtained by decoding the video data packet to the video frame data queue.
14. The playback method as claimed in claim 13, wherein the decoding of the audio data packets and the decoding of the video data packets are performed in parallel by different threads.
15. The playback method as claimed in claim 1, wherein the playback data includes audio sample data and video frame data, and after obtaining the playback data suitable for playback, the method further includes:
synchronizing the audio sample data and video frame data;
and outputting the audio sampling data and the video frame data to run playing.
16. A playback apparatus, comprising:
the data packet transmission device comprises an insertion unit, a transmission unit and a decoding unit, wherein the insertion unit is suitable for inserting null data packets among data packet sets, and the data packets in one data packet set are encoded in the same mode;
a decoding unit, adapted to decode the data packets in the data packet set in combination with the positions of the null data packets to obtain playing data suitable for playing, the decoding unit includes:
a data packet judging subunit, adapted to judge whether the data packet is an empty data packet or a non-empty data packet;
the decoding subunit is suitable for decoding the non-empty data packet by using a decoder to obtain the playing data when the data packet is the non-empty data packet, wherein the decoder corresponds to the file header information of the file to be played;
and the switching subunit is suitable for determining a decoder required for decoding the next data packet when the data packet is a null data packet.
17. The playback device of claim 16, further comprising:
and the decapsulation unit is suitable for decapsulating a plurality of files to be played to obtain data packets in the files to be played before inserting empty data packets between the data packet sets, wherein each data packet in the files to be played is divided into one or more data packet sets.
18. The playback apparatus according to claim 17, wherein the insertion unit includes:
the data packet storage subunit is suitable for storing a data packet set obtained by de-encapsulating a plurality of files to be played into one or a plurality of data packet queues;
an inserting subunit, adapted to insert null packets between the sets of packets of the packet queue.
19. The playback apparatus according to claim 17, wherein the decapsulating unit comprises:
the data file acquisition subunit is suitable for acquiring the file to be played, and the file to be played comprises file header information and original file data;
and the header information reading subunit is suitable for reading the file header information to determine a corresponding demultiplexer, and the demultiplexer is used for decapsulating the original file data.
20. The playback device of claim 16, further comprising: and the playing data adding unit is suitable for decoding the non-empty data packets, and then adding the playing data obtained by decoding the non-empty data packets to one or more queues to be played according to a decoding sequence to wait for playing.
21. The playback apparatus as claimed in claim 20, wherein the data packets include audio data packets and video data packets, the playback data includes audio sample data and video frame data, and the queue to be played includes an audio sample data queue and a video frame data queue;
the playing data adding unit comprises at least one of the following sub-units:
an audio data adding subunit, adapted to add the audio sample data obtained by decoding the audio data packet to the audio sample data queue;
and the video data adding subunit is suitable for adding the video frame data obtained by decoding the video data packet to the video frame data queue.
22. A computer-readable storage medium having computer instructions stored thereon, wherein the computer instructions are operable to perform the steps of the playback method of any one of claims 1 to 15.
23. A terminal comprising a memory and a processor, the memory having stored thereon computer instructions executable on the processor, wherein the processor executes the computer instructions to perform the steps of the playback method according to any one of claims 1 to 15.
CN201810784760.4A 2018-07-17 2018-07-17 Playing method and device, medium and terminal thereof Active CN108966000B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810784760.4A CN108966000B (en) 2018-07-17 2018-07-17 Playing method and device, medium and terminal thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810784760.4A CN108966000B (en) 2018-07-17 2018-07-17 Playing method and device, medium and terminal thereof

Publications (2)

Publication Number Publication Date
CN108966000A CN108966000A (en) 2018-12-07
CN108966000B true CN108966000B (en) 2021-01-29

Family

ID=64495628

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810784760.4A Active CN108966000B (en) 2018-07-17 2018-07-17 Playing method and device, medium and terminal thereof

Country Status (1)

Country Link
CN (1) CN108966000B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110430461A (en) * 2019-08-28 2019-11-08 腾讯科技（深圳）有限公司 A kind of method, apparatus and video playback apparatus controlling video playing
CN113507637A (en) * 2021-07-13 2021-10-15 北京字跳网络技术有限公司 Media file processing method, device, equipment, readable storage medium and product

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6097739A (en) * 1996-03-09 2000-08-01 Fujitsu Limited Data transfer rate control method and data transfer rate controller
US6169843B1 (en) * 1995-12-01 2001-01-02 Harmonic, Inc. Recording and playback of audio-video transport streams
CN1090869C (en) * 1993-11-30 2002-09-11 通用电气公司 Datastream packet allgnment indicator in a system for assembling transport data packets
CN1099808C (en) * 1993-11-30 2003-01-22 通用电气公司 Packed data processor in a system for assembling transport data packets
CN101790075A (en) * 2010-01-14 2010-07-28 北京东方广视科技股份有限公司 Method and device for sending data
CN102131117A (en) * 2011-03-21 2011-07-20 深圳创维数字技术股份有限公司 Digital television program switching method, switching control device and set top box
CN102148812A (en) * 2010-09-02 2011-08-10 华为技术有限公司 Method, server and system for realizing server side playlist
CN102447949A (en) * 2011-08-24 2012-05-09 上海文广科技（集团）有限公司 High efficient frame-accurate TS stream splicing method
CN104135678A (en) * 2014-08-13 2014-11-05 浪潮软件集团有限公司 Method for realizing video advertisement putting in video on demand based on HLS protocol
CN105376613A (en) * 2015-12-10 2016-03-02 华为技术有限公司 Fast channel switching method, server and IPTV system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9009337B2 (en) * 2008-12-22 2015-04-14 Netflix, Inc. On-device multiplexing of streaming media content
CN101442675B (en) * 2008-12-31 2012-01-11 中兴通讯股份有限公司 Multimedia playing method
US8750315B2 (en) * 2009-01-23 2014-06-10 Akamai Technologies, Inc. Efficiently storing transport streams

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1090869C (en) * 1993-11-30 2002-09-11 通用电气公司 Datastream packet allgnment indicator in a system for assembling transport data packets
CN1099808C (en) * 1993-11-30 2003-01-22 通用电气公司 Packed data processor in a system for assembling transport data packets
US6169843B1 (en) * 1995-12-01 2001-01-02 Harmonic, Inc. Recording and playback of audio-video transport streams
US6097739A (en) * 1996-03-09 2000-08-01 Fujitsu Limited Data transfer rate control method and data transfer rate controller
CN101790075A (en) * 2010-01-14 2010-07-28 北京东方广视科技股份有限公司 Method and device for sending data
CN102148812A (en) * 2010-09-02 2011-08-10 华为技术有限公司 Method, server and system for realizing server side playlist
CN102131117A (en) * 2011-03-21 2011-07-20 深圳创维数字技术股份有限公司 Digital television program switching method, switching control device and set top box
CN102447949A (en) * 2011-08-24 2012-05-09 上海文广科技（集团）有限公司 High efficient frame-accurate TS stream splicing method
CN104135678A (en) * 2014-08-13 2014-11-05 浪潮软件集团有限公司 Method for realizing video advertisement putting in video on demand based on HLS protocol
CN105376613A (en) * 2015-12-10 2016-03-02 华为技术有限公司 Fast channel switching method, server and IPTV system

Also Published As

Publication number Publication date
CN108966000A (en) 2018-12-07

Similar Documents

Publication Publication Date Title
JP4421156B2 (en) Image reproducing apparatus and image recording / reproducing apparatus
US10129587B2 (en) Fast switching of synchronized media using time-stamp management
US7965921B2 (en) Storage medium including text-based caption information, reproducing apparatus and reproducing method thereof
RU2010132152A (en) RECORDING MEDIA, PLAYBACK DEVICE AND INTEGRAL DIAGRAM
CN104602117A (en) Double-speed video playing method and device
RU2011135363A (en) PLAYBACK, RECORDING MEDIA AND INTEGRAL DIAGRAM
KR20050118197A (en) Cpi data for stream buffer channels
CN108966000B (en) Playing method and device, medium and terminal thereof
US20200252580A1 (en) Video data processing method and video data processing device
CN106231225A (en) A kind of network hard disk video recorder data processing method and system
KR100604831B1 (en) Audio and video player synchronizing ancillary word and image to audio and method thereof
EP4087266A1 (en) Playback mode determining method and apparatus
JPH10269706A (en) Information reproducing apparatus and information reproducing method
JPH10154125A (en) Dma data transfer device, moving image decoder using the device and dma data transfer controlling method
JP2009105684A (en) Moving image decoder
TWI237806B (en) Audio decoding system with ring buffer and method thereof
WO2016184109A1 (en) Methods for saving record and displaying and playing picture-form record, and terminal
CN114125542A (en) Video insertion method and device for realizing single-channel hardware decoder based on software mode
JP5161323B2 (en) Reproduction method and apparatus
TWI779848B (en) Switching device and switching method using the same
JP2007060480A (en) Reverse playback method, playback apparatus, reverse playback program and recording medium with reverse playback program recorded thereon
JP4490691B2 (en) Apparatus, record carrier and method for recording a sequence of video data signals
JP6236800B2 (en) Information processing system and information processing apparatus
CN115580740A (en) Video playing method, device, equipment, storage medium and program product
US7852351B2 (en) Multiplexed button data system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20190315

Address after: Room 1702-03, Blue Sky and Sheng Building, 32 Zhongguancun Street, Haidian District, Beijing

Applicant after: BEIJING CENTURY TAL EDUCATION TECHNOLOGY CO., LTD.

Address before: 100039 Room 118, Building 3, 6-C, Eight High-tech Parks, Shijingshan District, Beijing

Applicant before: BEIJING XINTANG SICHUANG EDUCATIONAL TECHNOLOGY CO., LTD.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant