CN106791994B - Low-delay quick broadcasting method and device - Google Patents

Low-delay quick broadcasting method and device Download PDF

Info

Publication number
CN106791994B
CN106791994B CN201611259522.9A CN201611259522A CN106791994B CN 106791994 B CN106791994 B CN 106791994B CN 201611259522 A CN201611259522 A CN 201611259522A CN 106791994 B CN106791994 B CN 106791994B
Authority
CN
China
Prior art keywords
sub
video data
frame
client
data
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
CN201611259522.9A
Other languages
Chinese (zh)
Other versions
CN106791994A (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 QIYI Century Science and Technology Co Ltd
Original Assignee
Beijing QIYI Century Science and 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 QIYI Century Science and Technology Co Ltd filed Critical Beijing QIYI Century Science and Technology Co Ltd
Priority to CN201611259522.9A priority Critical patent/CN106791994B/en
Publication of CN106791994A publication Critical patent/CN106791994A/en
Application granted granted Critical
Publication of CN106791994B publication Critical patent/CN106791994B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26241Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the time of distribution, e.g. the best time of the day for inserting an advertisement or airing a children program
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/4302Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/458Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • H04N21/4586Content update operation triggered locally, e.g. by comparing the version of software modules in a DVB carousel to the version stored locally
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85Assembly of content; Generation of multimedia applications
    • H04N21/854Content authoring
    • H04N21/8547Content authoring involving timestamps for synchronizing content

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

The embodiment of the invention discloses a low-delay quick broadcasting method which is applied to a server and comprises the following steps: receiving a data set uploaded by a first client in real time, wherein the data set comprises video data; saving first sub-video data, and modifying a timestamp of each frame in the first sub-video data, wherein the first sub-video data at least comprises a latest received key frame in the video data; and when a playing request sent by a second client is received, sending the first sub-video data to the second client for playing. Therefore, when a playing request sent by the second client is received, the first sub-video data which is modified by the timestamp and can be played quickly is sent to the second client for playing, so that the second client can play quickly without waiting for the next key frame, the video playing delay between the second client and the first client is reduced, and the watching experience of a user at the second client is improved.

Description

Low-delay quick broadcasting method and device
Technical Field
The invention relates to the technical field of live video, in particular to a low-delay quick broadcasting method and device.
Background
The RTMP (Real Time Messaging Protocol) is a Protocol for audio, video, and data transmission between a player and a server. The RTMP protocol has found wide application in video on demand and live applications. A client (e.g., a player) may interact with the server using the RTMP protocol. For example, the client may receive video and audio data pushed by the server and implement local playing at the client.
However, in the process of real-time RTMP playing, the playing entry point of the client accessing the real-time video is random. In order to ensure the normal playing of the client, when the client accesses the real-time video playing and pulls the stream from the server, the server needs to start to send the video data to the client from the key frame in the live video data. If the server starts to send video data to the client from the key frame received after the access time, the client may have a waiting time when the video is played (i.e., the client starts to play the live video), and cannot play the video quickly or immediately, which is not favorable for improving the viewing experience of the client user. If the server starts to send video data to the client from the key frame received before the access time, the playing delay of the client is further increased on the basis of the network delay, which is also not beneficial to improving the watching experience of the client user.
Therefore, those skilled in the art need to provide a low-latency fast broadcasting method and apparatus, which can reduce the waiting time of the user during broadcasting, and at the same time, do not increase the playing latency of the client, thereby improving the viewing experience of the user.
Disclosure of Invention
In order to solve the problems in the prior art, the invention provides a low-delay quick broadcasting method and a low-delay quick broadcasting device, which can reduce the waiting time of a user during broadcasting and simultaneously do not increase the broadcasting delay of a client, thereby improving the watching experience of the user.
The low-delay quick broadcasting method provided by the embodiment of the invention is applied to a server, and comprises the following steps:
receiving a data set uploaded by a first client in real time, wherein the data set comprises video data;
saving first sub-video data, and modifying a timestamp of each frame in the first sub-video data, wherein the first sub-video data at least comprises a latest received key frame in the video data;
and when a playing request sent by a second client is received, sending the first sub-video data to the second client for playing.
Optionally, the modifying the timestamp of each frame in the first sub-video data specifically includes:
and setting the time stamp of each frame in the first sub-video data to be any time within a preset time range.
Optionally, the time within the preset time range is less than or equal to 200 milliseconds.
Optionally, the first sub-video data is a group of latest received pictures in the video data;
the storing the first sub-video data specifically includes:
detecting the frame types of the latest received frames in the video data one by one;
when the frame type of the latest received frame is detected to be a key frame, saving a picture group to which the frame belongs as the first sub-video data;
and when the frame type of the latest received frame is detected to be a key frame again, replacing the picture group of the frame with the first sub-video data.
Optionally, the data set further includes audio data; the sending the first sub video data to the second client for playing further comprises:
continuing to send second sub-video data and second sub-audio data to the second client, so that the second client synchronously plays the second sub-video data and the second sub-audio data;
wherein the second sub video data belongs to the video data, the second sub video data is temporally continuous with the first sub video data and a start time of the first sub video data is earlier than a start time of the second sub video data, and the second sub audio data corresponds to the second sub video data.
The low-delay quick broadcasting device provided by the embodiment of the invention is applied to a server, and the device comprises: the device comprises a data receiving module, a data processing module, a request receiving module and a data sending module;
the data receiving module is used for receiving a data set uploaded by a first client in real time, and the data set comprises video data;
the data processing module is used for storing first sub-video data and modifying a timestamp of each frame in the first sub-video data, wherein the first sub-video data at least comprises a latest received key frame in the video data;
the request receiving module is used for receiving a playing request sent by a second client;
and the data sending module is used for sending the first sub-video data to the second client for playing when the request receiving module receives the playing request.
Optionally, the data processing module includes: a timestamp modification sub-module;
and the timestamp modification sub-module is used for setting the timestamp of each frame in the first sub-video data to be any time within a preset time range.
Optionally, the time within the preset time range is less than or equal to 200 milliseconds.
Optionally, the first sub-video data is a group of latest received pictures in the video data;
the data processing module comprises: the detection submodule and the storage submodule;
the detection submodule is used for detecting the frame types of the latest received frames in the video data one by one;
the storage submodule is used for storing a picture group to which the frame belongs as the first sub-video data when the detection submodule detects that the frame type of the latest received frame is a key frame;
the storage sub-module is further configured to replace the group of pictures of the frame with the first sub-video data when the detection sub-module detects again that the frame type of the latest received frame is a key frame.
Optionally, the data set further includes audio data;
the data sending module is further configured to continue sending second sub-video data and second sub-audio data to the second client after sending the first sub-video data to the second client for playing, so that the second client synchronously plays the second sub-video data and the second sub-audio data;
wherein the second sub video data belongs to the video data, the second sub video data is temporally continuous with the first sub video data and a start time of the first sub video data is earlier than a start time of the second sub video data, and the second sub audio data corresponds to the second sub video data.
Compared with the prior art, the invention has at least the following advantages:
according to the low-delay quick playing method provided by the embodiment of the invention, when the video data and the audio data uploaded by the first client in real time are received, one or more frames including key frames in a group of latest received frames in the video data are stored to obtain the first sub-video data, and the stored first sub-video data are updated in real time along with the transmission of the video data. Meanwhile, the timestamp of each frame in the stored first sub-video data is modified, so that the second client can quickly skip playing the first sub-video data when decoding and playing. Therefore, when a playing request sent by the second client is received, the first sub-video data is sent to the second client for playing, so that the second client can play quickly without waiting for the next key frame. And after the first sub-video data is sent to the second client, the real-time video data is sent to the second client for playing. The modified timestamp of each frame in the first sub-video data enables the second client to quickly play the first sub-video data, and then play real-time video data, so that video playing delay between the second client and the first client can be reduced, and watching experience of a user at the second client is improved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art without creative efforts.
Fig. 1 is a schematic flow chart of an embodiment of a low-latency fast broadcasting method provided by the present invention;
fig. 2 is a schematic structural diagram of a low-latency fast playback apparatus according to an embodiment of the present invention.
Detailed Description
In order to make the technical solutions of the present invention better understood, 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 only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
It should be noted that, the low-latency fast broadcasting method and apparatus provided by the embodiment of the present invention are all applied to a server. The server is respectively communicated with a first client (a live data generating end, a push stream end or a main broadcasting end and the like) and a second client (a live video playing end, a pull stream end or a spectator end and the like) through an RTMP protocol, and the data of the first client is forwarded to the second client in real time. And the second client plays the live video of the first client according to the data received from the server.
The method comprises the following steps:
referring to fig. 1, this figure is a schematic flow chart of an embodiment of a low-latency fast broadcasting method provided in this embodiment.
The low-latency fast broadcasting method provided by the embodiment comprises the following steps:
s101: receiving a data set uploaded by a first client in real time, wherein the data set comprises video data.
When video data is generated by video coding, the first client sets key frames in the video data according to preset settings. For example, a frame key frame is set every 2 seconds. And then, the first client transmits various data related to the live broadcast to the server continuously in real time.
S102: saving first sub-video data and modifying a timestamp of each frame in the first sub-video data, wherein the first sub-video data at least comprises a latest received key frame (I frame) in the video data.
S103: and when a playing request sent by a second client is received, sending the first sub-video data to the second client for playing.
It should be noted here that the first sub video data at least includes an I frame that is newly received by the server. The first sub-video data may further include one or more frames following the latest received I-frame, the one or more frames belonging to the same Group of Pictures (GOP) as the latest received I-frame. In video coding, a GOP is a sequence of frames in a video sequence starting with a first I-frame and ending with a second I-frame, but excluding the second I-frame. A GOP includes an I-frame and several P-frames and B-frames. The second I-frame in the video sequence is the start of another GOP.
In a preferred implementation manner of this embodiment, the first sub-video data is a group of pictures that are received latest in the video data. At this time, the saving the first sub-video data specifically includes: detecting the frame types of the latest received frames in the video data one by one; when the frame type of the latest received frame is detected to be a key frame, saving a picture group to which the frame belongs as the first sub-video data; and when the frame type of the latest received frame is detected to be a key frame again, replacing the picture group of the frame with the first sub-video data.
In specific implementation, when the server receives video data, whether a received frame is an I frame is judged; if so, each frame received is buffered starting with the frame. And when the server judges the received frame as the I frame again, stopping buffering. Thereafter, all the buffered frames are replaced with the first sub video data.
Therefore, after the second client sends the live broadcast request to access the live video broadcast, the second client can immediately receive the first sub-video data sent by the server, waiting time is not needed, and the first sub-video data can be directly decoded and played.
It should be noted here that, obviously, in order to ensure the normal playing of the live video, the data set further includes audio data. However, if the audio data corresponding to the first sub-video data is simultaneously sent to the second client for playing, the second client needs to perform audio and video synchronization operation during decoding. This may delay the playback time of the live video on the second client, delay the playback time of the second client, and also increase the playback delay between the second client and the first client, which is not favorable for improving the viewing experience of the second client user. Therefore, only the first sub-video data is sent to the second client for playing during playing, and corresponding audio data is not transmitted to the second client, so that the playing speed of the second client can be increased to a certain extent, and the playing delay of the second client is reduced.
In a preferred embodiment of this embodiment, after step S103, the method further includes: continuing to send second sub-video data and second sub-audio data to the second client, so that the second client synchronously plays the second sub-video data and the second sub-audio data; wherein the second sub video data belongs to the video data, the second sub video data is temporally continuous with the first sub video data and a start time of the first sub video data is earlier than a start time of the second sub video data, and the second sub audio data corresponds to the second sub video data.
And then, the server can continuously send the video data received in real time and the audio data corresponding to the video data to the second client, so that the second client can normally play the live video.
In one example, the starting frame of the second sub-video data may be the first I-frame after the first sub-video data, so as to ensure the continuity of the video played by the second client. However, the playing of the first sub-video data may increase the playing delay between the second client and the first client, which may affect the watching effect of the second client.
In another example, the starting frame of the second sub-video data may also be an I-frame newly received by the current server, so that the playing delay between the second client and the first client can be reduced. However, the video played by the second client is discontinuous, and the time length of the skipped video is affected by the playing time of the first sub-video data, network transmission and other factors, which is also not beneficial to the watching effect of the second client user.
Therefore, the time for the second client to play the first sub-video data can be shortened by modifying the timestamp of each frame in the first sub-video data, so as to reduce the play delay of the second client. Further, when the starting frame of the second sub-video data is the I frame received by the current server latest, the time length of the skipped live video when the second client plays is reduced.
In some possible implementations of this embodiment, the timestamp of each frame in the first sub-video data may be set to any time within a preset time range.
As one example, the time within the preset time range is less than or equal to 200 milliseconds (ms).
Specifically, the timestamp of each frame in the first sub-video data may be set to 0ms or a time of approximately 0 ms. Therefore, when the second client side decodes and plays, the first sub-video data can be rapidly played according to the timestamp of each frame in the first sub-video data, and the playing delay of the second client side is reduced.
In addition, the timestamps of each frame in the first sub-video data can be sequentially modified into ascending timestamps, but the difference between the timestamps of each frame is small. For example, the timestamp of each frame is set to 0ms, 10ms, 20ms, 30ms, etc., respectively, and the timestamps between two adjacent frames are incremented at intervals of 10 ms. In a specific operation, when the total frame number of the first sub video data is small, the interval between the timestamps of two adjacent frames in the first sub video data can be set to be a larger point; on the contrary, when the total frame number of the first sub-video data is large, the interval between the timestamps of two adjacent frames in the first sub-video data needs to be correspondingly reduced, so as to ensure that the frames in the first sub-video data can be played in a short time during playing.
It should be noted that, when the timestamp of each frame in the first sub-video data is modified, it is required to ensure that the modified actual playing is completed quickly when the modified actual playing is performed. Therefore, in general, the timestamp of the last frame in the first sub-video data should not be greater than 200 ms.
In the low-latency fast playing method provided by this embodiment, when video data and audio data uploaded by a first client in real time are received, one or more frames including a key frame in a group of latest received frames in the video data are saved to obtain first sub-video data, and the saved first sub-video data is updated in real time along with transmission of the video data. Meanwhile, the timestamp of each frame in the stored first sub-video data is modified, so that the second client can quickly skip playing the first sub-video data when decoding and playing. Therefore, when a playing request sent by the second client is received, the first sub-video data is sent to the second client for playing, so that the second client can play quickly without waiting for the next key frame. And after the first sub-video data is sent to the second client, the real-time video data is sent to the second client for playing. The modified timestamp of each frame in the first sub-video data enables the second client to quickly play the first sub-video data, and then play real-time video data, so that video playing delay between the second client and the first client can be reduced, and watching experience of a user at the second client is improved.
Based on the low-latency fast broadcasting method in the above embodiments, the embodiment of the present invention further provides a low-latency fast broadcasting device.
The embodiment of the device is as follows:
referring to fig. 2, it is a schematic structural diagram of an embodiment of a low-latency fast playback apparatus provided in the present invention.
The low-latency fast playback device provided by the embodiment comprises: a data receiving module 100, a data processing module 200, a request receiving module 300 and a data transmitting module 400;
the data receiving module 100 is configured to receive a data set uploaded by a first client in real time, where the data set includes video data;
the data processing module 200 is configured to store first sub-video data, and modify a timestamp of each frame in the first sub-video data, where the first sub-video data at least includes a latest received key frame in the video data;
in some possible implementations of this embodiment, the first sub-video data is a group of pictures that are received latest in the video data.
In this case, the data processing module 200 includes: a detection submodule and a storage submodule (both shown in the figure);
the detection submodule is used for detecting the frame types of the latest received frames in the video data one by one;
the storage submodule is used for storing a picture group to which the frame belongs as the first sub-video data when the detection submodule detects that the frame type of the latest received frame is a key frame;
the storage sub-module is further configured to replace the group of pictures of the frame with the first sub-video data when the detection sub-module detects again that the frame type of the latest received frame is a key frame.
In some possible implementations of this embodiment, the data processing module 200 includes: a timestamp modification submodule (not shown in the figure);
in one example, the timestamp modification sub-module is configured to set a timestamp of each frame in the first sub-video data to an arbitrary time within a preset time range.
The time within the preset time range is less than or equal to 200 milliseconds.
The request receiving module 300 is configured to receive a play request sent by a second client;
the data sending module 400 is configured to send the first sub-video data to the second client for playing when the request receiving module 300 receives the playing request.
Obviously, the data set also comprises audio data. At this time, in some possible implementation manners of this embodiment, the data sending module 400 is further configured to continue sending second sub-video data and second sub-audio data to the second client after sending the first sub-video data to the second client for playing, so that the second client synchronously plays the second sub-video data and the second sub-audio data; wherein the second sub video data belongs to the video data, the second sub video data is temporally continuous with the first sub video data and a start time of the first sub video data is earlier than a start time of the second sub video data, and the second sub audio data corresponds to the second sub video data.
In the low-latency fast playing device provided by this embodiment, when the data receiving module receives video data and audio data uploaded by the first client in real time, the data processing module stores one or more frames including key frames in a group of latest received frames in the video data to obtain first sub-video data, and updates the stored first sub-video data in real time along with transmission of the video data. Meanwhile, the data processing module also modifies the timestamp of each frame in the stored first sub-video data, so that the second client can quickly skip playing the first sub-video data when decoding and playing. Therefore, when the request receiving module receives a playing request sent by the second client, the data sending module sends the first sub-video data to the second client for playing, so that the second client can quickly start playing without waiting for the next key frame. And after the first sub-video data is sent to the second client, the data sending module sends the real-time video data to the second client for playing. The modified timestamp of each frame in the first sub-video data enables the second client to quickly play the first sub-video data, and then play real-time video data, so that the playing delay between the second client and the first client can be reduced, and the watching experience of a user at the second client is improved.
It should be noted that, in the present specification, the embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant part can be referred to the method part for description.
It is further noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The foregoing is merely a preferred embodiment of the invention and is not intended to limit the invention in any manner. Although the present invention has been described with reference to the preferred embodiments, it is not intended to be limited thereto. Those skilled in the art can make numerous possible variations and modifications to the present teachings, or modify equivalent embodiments to equivalent variations, without departing from the scope of the present teachings, using the methods and techniques disclosed above. Therefore, any simple modification, equivalent change and modification made to the above embodiments according to the technical essence of the present invention are still within the scope of the protection of the technical solution of the present invention, unless the contents of the technical solution of the present invention are departed.

Claims (6)

1. A low-latency fast broadcasting method is applied to a server, and the method comprises the following steps:
receiving a data set uploaded by a first client in real time, wherein the data set comprises video data and audio data;
saving first sub-video data, and modifying a timestamp of each frame in the first sub-video data to enable a second client to quickly play the first sub-video data, wherein the first sub-video data at least comprises a latest received key frame in the video data; wherein the time stamps of each frame in the first sub video data are sequentially modified to increasing time stamps;
when a playing request sent by a second client is received, sending the first sub-video data to the second client for playing;
continuing to send second sub-video data and second sub-audio data to the second client, so that the second client synchronously plays the second sub-video data and the second sub-audio data;
wherein the second sub video data belongs to the video data, the second sub video data is temporally continuous with the first sub video data and a start time of the first sub video data is earlier than a start time of the second sub video data, the second sub audio data corresponds to the second sub video data;
the modifying the timestamp of each frame in the first sub-video data specifically includes:
and setting the time stamp of each frame in the first sub-video data to be any time within a preset time range.
2. The low latency fast opening method according to claim 1, wherein the time within the preset time range is less than or equal to 200 milliseconds.
3. The method of claim 1, wherein the first sub-video data is a group of pictures latest received in the video data;
the storing the first sub-video data specifically includes:
detecting the frame types of the latest received frames in the video data one by one;
when the frame type of the latest received frame is detected to be a key frame, saving a picture group to which the frame belongs as the first sub-video data;
and when the frame type of the latest received frame is detected to be a key frame again, replacing the picture group of the frame with the first sub-video data.
4. A low-latency fast broadcasting device is applied to a server, and the device comprises: the device comprises a data receiving module, a data processing module, a request receiving module and a data sending module;
the data receiving module is used for receiving a data set uploaded by a first client in real time, wherein the data set comprises video data and audio data;
the data processing module is used for storing first sub-video data and modifying a timestamp of each frame in the first sub-video data so as to enable a second client to quickly play the first sub-video data, wherein the first sub-video data at least comprises a latest received key frame in the video data; wherein the time stamps of each frame in the first sub video data are sequentially modified to increasing time stamps;
the request receiving module is used for receiving a playing request sent by a second client;
the data sending module is configured to send the first sub-video data to the second client for playing when the request receiving module receives the playing request; after the first sub-video data is sent to the second client side to be played, continuing to send second sub-video data and second sub-audio data to the second client side, so that the second client side can synchronously play the second sub-video data and the second sub-audio data;
wherein the second sub video data belongs to the video data, the second sub video data is temporally continuous with the first sub video data and a start time of the first sub video data is earlier than a start time of the second sub video data, the second sub audio data corresponds to the second sub video data;
the data processing module comprises: a timestamp modification sub-module;
and the timestamp modification sub-module is used for setting the timestamp of each frame in the first sub-video data to be any time within a preset time range.
5. The low-latency fast playback apparatus according to claim 4, wherein the time within the preset time range is less than or equal to 200 milliseconds.
6. The low-latency fast playback apparatus according to claim 4, wherein the first sub-video data is a group of pictures latest received in the video data;
the data processing module comprises: the detection submodule and the storage submodule;
the detection submodule is used for detecting the frame types of the latest received frames in the video data one by one;
the storage submodule is used for storing a picture group to which the frame belongs as the first sub-video data when the detection submodule detects that the frame type of the latest received frame is a key frame;
the storage sub-module is further configured to replace the group of pictures of the frame with the first sub-video data when the detection sub-module detects again that the frame type of the latest received frame is a key frame.
CN201611259522.9A 2016-12-30 2016-12-30 Low-delay quick broadcasting method and device Active CN106791994B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611259522.9A CN106791994B (en) 2016-12-30 2016-12-30 Low-delay quick broadcasting method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611259522.9A CN106791994B (en) 2016-12-30 2016-12-30 Low-delay quick broadcasting method and device

Publications (2)

Publication Number Publication Date
CN106791994A CN106791994A (en) 2017-05-31
CN106791994B true CN106791994B (en) 2020-11-24

Family

ID=58953820

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611259522.9A Active CN106791994B (en) 2016-12-30 2016-12-30 Low-delay quick broadcasting method and device

Country Status (1)

Country Link
CN (1) CN106791994B (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107147919B (en) * 2017-06-19 2020-11-27 网宿科技股份有限公司 Live broadcast quick starting method and system
CN107566918B (en) * 2017-09-21 2019-08-13 中国电子科技集团公司第二十八研究所 A kind of low delay under video distribution scene takes the neutrel extraction of root
CN109756749A (en) * 2017-11-07 2019-05-14 阿里巴巴集团控股有限公司 Video data handling procedure, device, server and storage medium
CN109005447A (en) * 2018-08-10 2018-12-14 高新兴科技集团股份有限公司 A kind of video recording of security protection high definition falls broadcasting method and device
CN109951717B (en) * 2019-03-29 2021-05-18 北京奇艺世纪科技有限公司 Rapid broadcasting method and device
KR20220030736A (en) * 2020-09-03 2022-03-11 라인플러스 주식회사 Method, system, and computer readable record medium to minimize delay in real-time live streaming

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101635848A (en) * 2008-07-22 2010-01-27 北大方正集团有限公司 Method and device for editing video file
US7830908B2 (en) * 2008-11-03 2010-11-09 Cisco Technologies, Inc. Systems and methods of reducing delay in decoding
CN102857730A (en) * 2012-08-23 2013-01-02 苏州阔地网络科技有限公司 Method and system for caching frame data
CN103747287A (en) * 2014-01-13 2014-04-23 合一网络技术(北京)有限公司 Video playing speed regulation method and system applied to flash
CN106162235A (en) * 2016-08-17 2016-11-23 北京百度网讯科技有限公司 Method and apparatus for Switch Video stream

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101854533B (en) * 2010-06-10 2012-05-23 华为技术有限公司 Frequency channel switching method, device and system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101635848A (en) * 2008-07-22 2010-01-27 北大方正集团有限公司 Method and device for editing video file
US7830908B2 (en) * 2008-11-03 2010-11-09 Cisco Technologies, Inc. Systems and methods of reducing delay in decoding
CN102857730A (en) * 2012-08-23 2013-01-02 苏州阔地网络科技有限公司 Method and system for caching frame data
CN103747287A (en) * 2014-01-13 2014-04-23 合一网络技术(北京)有限公司 Video playing speed regulation method and system applied to flash
CN106162235A (en) * 2016-08-17 2016-11-23 北京百度网讯科技有限公司 Method and apparatus for Switch Video stream

Also Published As

Publication number Publication date
CN106791994A (en) 2017-05-31

Similar Documents

Publication Publication Date Title
CN106791994B (en) Low-delay quick broadcasting method and device
CN110248204B (en) Processing method, device, equipment and storage medium for live broadcast cache
CN109714634B (en) Decoding synchronization method, device and equipment for live data stream
CN107147919B (en) Live broadcast quick starting method and system
JP7313445B2 (en) Dynamic shortening in replacement content playback to help align the end of replacement content with the end of replaced content
US8473997B2 (en) Channel changing method, apparatus, and system
US8387107B2 (en) Method, system and device for processing media stream
WO2017067489A1 (en) Set-top box audio-visual synchronization method, device and storage medium
CN110139148B (en) Video switching definition method and related device
CN108471548B (en) Live video quick playing method and device
CA2758763C (en) Method and device for fast pushing unicast stream in fast channel change
CN105247437A (en) Synchronizing multiple over the top streaming clients
CN109714622B (en) Video data processing method and device and electronic equipment
CN106470352B (en) Live channel playing method, device and system
CA2792106C (en) Method and system for inhibiting audio-video synchronization delay
JP2015526005A (en) Provision of media and content for individuals
CN113727199A (en) HLS slice rapid playing starting method
CN106612462B (en) Fast forward and fast backward processing method and terminal
CN105791987A (en) Media data playing method and terminal
US20170048291A1 (en) Synchronising playing of streaming content on plural streaming clients
WO2010022598A1 (en) Method and system for switching iptv channels, method and device for sending audio and video streams
CN106231414B (en) Control method and device for playing mode switching based on IPTV
CN109218809B (en) Streaming media playing method and device
EP2654311B1 (en) Synchronization method and synchronization apparatus for multicast group quick access, and terminal
CN110798713B (en) Time-shifted television on-demand method, terminal, server and 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
GR01 Patent grant
GR01 Patent grant