CN113242436B - Live broadcast data processing method and device and electronic equipment - Google Patents
Live broadcast data processing method and device and electronic equipment Download PDFInfo
- Publication number
- CN113242436B CN113242436B CN202011606495.4A CN202011606495A CN113242436B CN 113242436 B CN113242436 B CN 113242436B CN 202011606495 A CN202011606495 A CN 202011606495A CN 113242436 B CN113242436 B CN 113242436B
- Authority
- CN
- China
- Prior art keywords
- data
- sending
- smooth
- live broadcast
- speed
- 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
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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/218—Source of audio or video content, e.g. local disk arrays
- H04N21/2187—Live feed
-
- 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
-
- 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management 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/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
The application relates to a live data processing method, a live data processing device and electronic equipment, wherein the method comprises the following steps: responding to a live broadcast request sent by a playing end, and sending image data of an I frame of a first image group at a first smooth sending speed; and sending the image data of other frames except the I frame of the first image group at a second smooth sending speed, wherein the first smooth sending speed is greater than the second smooth sending speed. According to the embodiment of the invention, corresponding smooth sending processing strategies are executed according to different live data sending stages, so that the problems of packet loss and image blockage caused by data burst are relieved, and more smooth live broadcast experience is provided for a user at a playing end.
Description
Technical Field
The application relates to a live data processing method and device and electronic equipment, and belongs to the technical field of computers.
Background
In the current live broadcast, a Content Delivery Network (CDN) technology is used to deliver live broadcast data, a live broadcast end sends video data to a CDN node closer to a play end for caching, and then the CDN node sends the live broadcast data to the play end.
In some cases, due to network jitter of the live broadcast end, for example, wifi and 4G signals are interfered, a short-time network may be blocked, and then all data are sent to the CDN node instantaneously, and the CDN node needs to send data to a large number of broadcast ends, which may cause network congestion and cause the broadcast end to be blocked. In addition, for the situation that the live broadcast end with an excessively large access amount carries out live broadcast, a spike of data may also occur, the processing capacity of the CDN node may be directly filled, and a large range of blocking of the broadcast end is caused, which is a situation that a large number of broadcast ends are simultaneously flooded into a live broadcast room, in order to implement second-turn live broadcast, the CDN node may send a large number of Group of Pictures (GOP) cache data, thereby causing a data burst, which easily exceeds the load capacity of a UDP (User Datagram Protocol) link, causing a large amount of packet loss and causing a screen-splash and blocking phenomenon during second-turn-on.
Disclosure of Invention
The embodiment of the invention provides a method and a device for processing live broadcast data and electronic equipment, which are used for dealing with data burst and reducing the pause phenomenon.
In order to achieve the above object, an embodiment of the present invention provides a method for processing live data, including:
responding to a live broadcast request sent by a playing end, and sending image data of a key frame of a first image group at a first smooth sending speed;
and sending the image data of other frames except the key frame of the first image group at a second smooth sending speed, wherein the first smooth sending speed is greater than the second smooth sending speed.
An embodiment of the present invention further provides a device for processing live broadcast data, including:
the first smoothing processing module is used for responding to a live broadcast playing request sent by a playing end and sending image data of a key frame of a first image group at a first smoothing sending speed;
and the second smoothing processing module is used for sending the image data of other frames except the key frame of the first image group at a second smoothing sending speed, wherein the first smoothing sending speed is greater than the second smoothing sending speed.
The embodiment of the invention also provides a method for processing live broadcast data, which comprises the following steps:
acquiring the code rate of a live broadcast end and/or the number of playing ends requesting live broadcast data;
determining smooth sending speeds of multiple levels according to the code rate of the live broadcast end and/or the number of the playing ends requesting live broadcast data;
and dynamically configuring the smooth sending speeds of the multiple levels according to the live broadcasting process corresponding to each playing end to send the live broadcasting data.
An embodiment of the present invention further provides an electronic device, including:
a memory for storing a program;
and the processor is used for operating the program stored in the memory so as to execute the processing method of the live broadcast data.
According to the processing method, the processing device and the electronic equipment of the live broadcast data, the corresponding smooth sending processing strategies are executed according to different live broadcast data sending stages to alleviate the problems of packet loss and image blockage caused by data burst, especially for the second-starting live broadcast stage, the key frame is sent at a high smooth sending speed, so that a playing end can obtain the key frame as soon as possible and play the key frame, and then the image data of other frames in the first GOP data are sent at a low smooth sending speed, so that the data spike in the live broadcast starting stage can be effectively alleviated, and the fast display of live broadcast pictures at the playing end is not influenced.
The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.
Drawings
Fig. 1 is one of application scenarios of a live data processing method according to an embodiment of the present invention;
fig. 2 is a second schematic view of an application scenario of the live data processing method according to the embodiment of the present invention;
fig. 3 is a schematic structural diagram of a CDN node according to an embodiment of the present invention;
fig. 4 is a schematic diagram of a change in live data volume in a live scene according to an embodiment of the present invention;
fig. 5 is a schematic diagram of a live data smoothing effect in a live scene according to an embodiment of the present invention;
fig. 6 is a flowchart illustrating a method for processing live data according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram of a device for processing live data according to an embodiment of the present invention;
fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
The technical solution of the present invention is further illustrated by some specific examples.
As shown in fig. 1 and fig. 2, which are schematic diagrams of application scenarios of a live data processing method according to an embodiment of the present invention. The network live broadcast of the embodiment of the invention adopts the CDN to distribute live broadcast data, and the live broadcast data is firstly transmitted to each CDN node on the CDN, and then is sent to a playing end by the CDN node. In a live broadcast scene, a process of sending live broadcast data to a CDN network by a live broadcast end is called streaming, and a process of requesting live broadcast data from a CDN node by a play end is called streaming. The playing end obtains the stream pulling address through interaction with the live broadcast service platform, the playing end can pull the stream from the CDN node with the closer network path distance, so that delay of live broadcast data is reduced, the whole CDN can be deployed in a large-range area, and the live broadcast data of the live broadcast end can be quickly and efficiently provided for numerous playing ends. The processing of the stream pushing can adopt two modes, one mode is that the live broadcast end directly sends live broadcast data to the CDN network, as shown in fig. 1, the live broadcast end obtains a stream pushing address through interaction with the live broadcast service platform, and then sends live broadcast data to the CDN network according to the stream pushing address, and the other mode is that the live broadcast end sends the live broadcast data to the live broadcast service platform, and then the live broadcast service platform performs stream pushing to the CDN network.
With the increase of the volume of internet live broadcasting, users participating in live broadcasting at the same time are often in an order of magnitude larger, and even tens of millions of users can participate in live broadcasting at the same time at a live broadcasting end with an extremely large access amount. Under the condition that network jitter or a large number of users instantly rush into a live broadcast room, a large network data spike is often caused, so that a large amount of packet loss is caused, the phenomenon of screen splash or blocking can occur on a playing end, and the experience of participation of the users in live broadcast is greatly influenced. The problem is more serious in a scene of second live broadcast, and some live broadcast terminals with an ultra-large access amount often have a large number of users simultaneously joining a live broadcast room during live broadcast or during activity.
The processing method of the live broadcast data of the embodiment of the invention is provided aiming at the problems, and various problems caused by data burst are relieved by executing corresponding smooth sending processing strategies according to different live broadcast data sending stages. As shown in fig. 3, which is a schematic structural diagram of a CDN node according to an embodiment of the present invention, the live data processing method of the present invention may be applied to each CDN node, and a scenario shown in fig. 3 is that a live end pushes live data to the CDN node and then the live data is sent from the CDN node to a playback end.
In the embodiment of the present invention, the live broadcast data may include two parts, i.e., video data and audio data, where the video data may be encoded in the form of a Group of Pictures (GOP), and at the live broadcast end, after encoding multiple Pictures, an image encoder generates a Group of GOP data, and at the play end, an image decoder decodes the Group of GOP data to reconstruct a video image. The GOP is a group of continuous images, which is composed of an I frame (also called a key frame) and a B/P frame, and is a basic unit for access and processing of a video image encoder and decoder, and the arrangement of the I frame and the B/P frame is repeated until the end of live video. Where I-frames are intra-coded frames, I-frames are a complete picture, and P-frames and B-frames record changing data relative to I-frames, P-frames are forward predicted frames (forward reference frames), B-frames are bi-directional interpolated frames (bi-directional reference frames), both P-frames and B-frames rely on I-frames for decoding, and in GOP format, I-frames are the first frames of GOP data. The audio data is encoded and decoded independently from the video data, and is aligned with each frame of image data of the video in a time stamp manner, and in a data transmission manner, an audio-video interleaving manner is generally adopted for data transmission.
As shown in fig. 3, after live data is pushed to the CDN node, video data and audio data are respectively put into the GOP data cache and the audio data cache. And then, according to a preset live data processing strategy, carrying out graded smoothing processing on live data in different stages, wherein the smoothing processing logic is completed by a second-start processing module, a live data processing module and a smoothing processing module in a coordinated mode. The smooth sending processing refers to sending the buffered video data and audio data according to the configured smooth sending rate, and smoothly sending the burst data volume, so as to avoid network congestion. In the embodiment of the present invention, the smoothing strategy may be divided into three stages:
1) First second frame
As mentioned above, the I frame is located in the first frame of the GOP data and is a complete picture, and the following P frame and B frame need to be decoded depending on the I frame, so the data amount of the I frame is much larger than that of the P frame and B frame in the GOP data of the same group. In addition, for live video, the I frame of GOP data of a video stream has a special meaning, and this I frame is the starting frame of the whole video image sequence, generally called IDR frame, and besides having the function of a general I frame, it is also a mark of the beginning of the video image sequence, and all frames after the IDR frame cannot refer to the content of any frame before the IDR frame. It should be noted that, in this embodiment of the present invention, the first group of pictures refers to a first group of GOP data that is sent to the playback end by the CDN node after the playback end requests to join live broadcast, that is, after the playback end sends a request for live broadcast data to the CDN node, and the above-mentioned second start frame and the following second start GOP cache are processing strategies for the first group of GOP data.
For a video live broadcast scene, live broadcast second is an important index for evaluating user experience, so that a playing end can obtain a first I frame as soon as possible in the configuration of a smooth sending strategy, a live broadcast picture can be rapidly presented on the playing end, preparation is made for subsequent decoding of P frames and B frames, and the playing starting stage is smoother. Therefore, when the smooth transmission speed is configured, the first smooth transmission speed having the highest speed is configured for the first I frame.
2) Second GOP cache
And after the first I frame is transmitted, transmitting the residual P frames and B frames in the first group of GOP data by using a second smooth transmission speed which is relatively larger. Because the data volume of the P frame and the B frame is smaller than that of the I frame, the playing end can still continuously obtain the image frame under the condition that the data volume of the P frame and the B frame is smaller than the first smooth sending speed, and therefore a user can immediately see continuous images after quickly opening a live video image. Meanwhile, audio data corresponding to the first group of GOP data may be transmitted in an interleaved manner with the video data.
3) Regular live data transmission
The processing of second start live broadcast stage is accomplished in aforementioned 1) and 2), and after second start is accomplished, to conventional live broadcast data in the back, live broadcast data behind the first group GOP data promptly, can adopt the third smooth speed of sending that is less than above-mentioned second smooth speed of sending to carry out video data's sending, thereby let the live broadcast data transmission of whole live broadcast in-process in back gently handle on the time dimension, avoid the data spike, improve the smoothness nature of live broadcast in-process.
Because at least one group of GOP data is obtained at the side of the playing end, wherein the GOP data comprises an I frame, a plurality of P frames and B frames of a complete image, based on the image frames, even if delay of some GOP data exists in the live broadcasting process, based on the received GOP data, a video picture can still be rendered in a short time, and therefore the phenomenon of black screen or severe blockage can not occur.
In addition, since the I frame is inevitably present in each group of GOP data, and the data amount of the I frame is large relative to the B frame and the P frame, that is, after the first I frame, data impact caused by the I frame still occurs in the transmission process of the normal live broadcast data, but the I frame has been received before, and even if the current I frame is stuck, the live broadcast picture display can still be maintained based on the previously received I frame and the images corresponding to the P frame and the B frame. However, under the condition of insufficient bandwidth, the large I-frame impact may cause the audio data to lag, so that when an I-frame is transmitted, the corresponding audio data is sent first, and then the data of the I-frame is transmitted, so that a user can hear continuous sound at a playing end, and the live broadcasting process is not affected.
As shown in fig. 4, which is a schematic diagram of a change in live data volume in a live broadcast scenario according to an embodiment of the present invention, where a horizontal axis represents a time dimension, and a vertical axis represents a live data volume, it can be seen from the diagram that a high data spike occurs at regular intervals, and the data spike corresponds to data transmission of an I frame. Turning to fig. 5, which is a schematic diagram of a live data smoothing effect in a live broadcast scenario according to an embodiment of the present invention, where fig. 5 (a) is a fluctuation situation of live data that is not subjected to smooth transmission processing according to the embodiment of the present invention, and fig. 5 (b) is a fluctuation situation of live data that is subjected to smooth transmission processing according to the embodiment of the present invention, in fig. 5 (a), a large data spike occurs just after broadcasting, which is because a large number of users enter a live broadcast room, and a broadcast end corresponding to each user almost simultaneously requests live data, and in order to implement a second startup, a CDN node needs to send live data to a large number of broadcast ends, thereby causing a first data spike, for example, in a time period of 0.5 to 2 seconds in the figure, in this data spike time period, retransmission may be triggered due to a large amount of packet loss caused by network congestion, and further aggravating the data spike. When the period of the second-time live broadcast is over, the live broadcast data stream received by the playing end is relatively stable, but a data spike still occurs in a part of the time, for example, when an I frame is transmitted, but the data spike is relatively gentle due to the period of the second-time live broadcast. In fig. 5 (b), after the smooth transmission processing according to the embodiment of the present invention is applied, the large data spike in the second-start live broadcast stage is smoothed to a time period of 0.5 to 5 seconds, the data peak value is significantly reduced, and it can be seen from fig. 5 (b) that in the smoothed data, a small spike higher than that in the subsequent smooth stage is present in the vicinity of 0.5 seconds, which corresponds to the strategy of the second-start first frame described above, that is, the first smooth transmission speed transmits the first I frame, since this processing is only for the first I frame, the data spike as large as that in fig. 5 (a) is not caused, and therefore, a large amount of packet loss does not occur. In addition, in the subsequent processing of the data spike, it can be seen that the smooth sending processing of the embodiment of the present invention also significantly weakens or removes the data spike, thereby obtaining a smoother live broadcast experience.
The staged smooth transmission strategy for the live broadcast process is introduced above, and after determining the smooth transmission speed used in a certain stage, data transmission can be performed by calling a data packet transmission interface function based on the UDP protocol, and control of the smooth speed is achieved by controlling the time interval for calling the data packet transmission interface function and the data amount transmitted each time. In the embodiment of the invention, a UDP multi-packet sending mechanism can be adopted to send UDP data packets in batch, thereby reducing the times of calling interface functions and saving the occupancy rate of a CPU. Specifically, the sendmsg function may be called for bulk transmission of multiple UDP packets. Specifically, the UDP multi-packet sending function may be called at preset time intervals, and the amount of data sent for each call of the UDP multi-packet sending function may be determined according to the preset time intervals and the currently adopted smooth sending rate. For example, the time interval may be set to 10ms, and if the currently set smooth transmission speed is 8000kbps (the number of bytes transmitted per second, 8 bits per byte), the amount of data transmitted may be calculated to be (8000 k/8) × (10/1000) =10kB. It should be noted that the data volume transmitted by calling the sendmsg function once can be regarded as being sent instantaneously or sent smoothly in an interval time, and the specific transmission speed of the data volume is controlled by the system, which is not in the scope of the smoothing control strategy of the embodiment of the present invention. Therefore, in the embodiment of the present invention, the time interval for calling the packet transmission interface function determines the control granularity of the smooth control, the shorter the time interval is set, the finer the control granularity of the smooth speed is, and the specific time interval setting may be determined by integrating the CPU utilization efficiency and the smooth control granularity desired to be realized.
In addition, for the selection of the smooth sending speed, both the smooth and the playing experience need to be considered, especially in the second on stage, if the first smooth sending speed is too large, the smooth effect cannot be achieved in the second on period, and if the first smooth sending speed is too small, the data sending speed is too slow, and the playing experience is influenced. Therefore, in the embodiment of the invention, the most suitable smooth sending speed can be selected according to the code rate of the live broadcast end and the feedback of the live broadcast data, thereby realizing the balance of smooth and broadcast experience. The code rate of the live broadcast end refers to the data size coded by the encoder per second, the unit is kbps, for example, 800kbps represents that the encoder generates 800kb data per second, the code rate of the live broadcast end can be selected by the anchor, because the live broadcast project is generally carried out based on the live broadcast service platform and the CDN network, therefore, the code rate selected by a user (generally the anchor) of the live broadcast end depends on the hardware setting of the user on the one hand, and on the other hand, the user of the live broadcast end also depends on the live broadcast service level provided by the live broadcast service platform, the higher the code rate selected by the user of the live broadcast end, the higher the corresponding bandwidth cost may also be, the code rate of the live broadcast end belongs to a preset value before live broadcast, generally, the higher the code rate of the live broadcast end is, and the higher the required smooth sending speed is. The live broadcast data feedback refers to a post-event feedback mechanism, that is, after a smoothing process is performed at a certain smooth sending speed, feedback data is obtained from a broadcast end to evaluate whether the currently set smooth sending speed is reasonable, for example, after data sending of the first I frame and the remaining frames in the first group of GOP data is completed at the current first smooth sending speed and the second smooth sending speed, a large number of broadcast ends can obtain data feedback of the fluency degree of the actual second live broadcast picture and the subsequent several frames of pictures, so that the first smooth sending speed and the second smooth sending speed are optimized according to the information, and a broadcast end subsequently reentering the live broadcast room can obtain better user experience of second live broadcast.
In addition, because the key frame includes a complete image picture and does not need to be decoded at the playing end, the playing end can only select the key frame from the received image group data to play, and even on the CDN side, the key frame can only be sent to the playing end, so that on one hand, the decoding processing of the playing end on non-key frames such as B frames or P frames can be greatly reduced, thereby speeding up video presentation, and on the other hand, the amount of video data transmitted to the playing end is also reduced, although such processing may lose a certain picture quality and continuity, when a data burst suddenly occurs, the phenomenon that the played picture is not presented in time or the image is stuck and the like due to the delay of B frame or P frame transmission is avoided. In addition, in the above technical solution, a play log may be recorded at the play end, and the play log is used to record processing conditions of receiving and decoding of received video data in a play process, where the processing conditions may include abnormal conditions of data burst and packet loss, and the play log may be used for playback, test, and the like of data processing in a live broadcast process, so as to further optimize a smoothing processing strategy and improve a live broadcast effect. According to the processing method of the live broadcast data, the problems of packet loss and image blockage caused by data burst are solved by executing corresponding smooth sending processing strategies according to different live broadcast data sending stages, especially aiming at the second-starting live broadcast stage, a larger smooth sending speed is adopted for sending the I frame, so that the playing end can obtain the I frame as soon as possible and play the I frame, and then the image data of other frames in the first GOP data is sent at a smaller smooth sending speed, so that the data spike at the live broadcast starting stage can be effectively reduced, and the fast presenting of a live broadcast picture at the playing end is not influenced.
Example one
As shown in fig. 6, which is a flowchart illustrating a method for processing live data according to an embodiment of the present invention, the method may be applied to a CDN node that sends live data, and the method may include:
s101: and responding to a live broadcast request sent by a broadcast end, and sending the image data of the I frame of the first group of pictures (GOP) at a first smooth sending speed.
The I frame is positioned in the first frame of the image group and is a complete image, the following P frame and B frame need to be decoded depending on the I frame, the first I frame is the initial frame of the whole video image sequence, and the live broadcast picture can be displayed as long as the first I frame is obtained. Therefore, in configuring the smooth transmission speed, the first smooth transmission speed having the highest speed is configured for the first I frame, and the first smooth transmission speed may be configured as the maximum transmission speed in the case where no packet loss occurs.
S102: and transmitting the image data of other frames except the I frame of the first image group at a second smooth transmission speed, wherein the first smooth transmission speed is greater than the second smooth transmission speed.
After the first I frame is transmitted, the remaining P and B frames in the data for the first group of pictures can be transmitted using a second, relatively large smooth transmission rate. Because the data volume of the P frame and the B frame is smaller than that of the frame, the playing end can still continuously obtain the image frame under the condition that the data volume is smaller than the first smooth sending speed, so that a user can immediately see continuous images after quickly opening a live video image, and the smoothness of data sending and the image continuity in the second opening stage are considered.
The above steps S101 and S102 complete the smooth sending processing for the first image group, and since the time period with the most serious data burst in the live broadcast scene is the initial stage of requesting live data when a large number of broadcasters enter the live broadcast room at the same time, it is desirable to provide the second-turn-on experience of quickly entering the live broadcast picture for the user in this stage, and therefore, a higher smooth sending speed is configured. After the second-on stage, the data of the subsequent image group can be transmitted at different transmission speeds according to the network conditions, for example, the image data of the video frame in the subsequent image group is transmitted at the transmission speed determined by the congestion control strategy, because the data burst phenomenon is relatively weakened. Alternatively, the transmission may be performed by the following processing of step S103.
S103: image data of a video frame of a subsequent image group is transmitted at a third smooth transmission speed, which is smaller than the second smooth transmission speed. After the second-starting live broadcast stage, the urgency degree of the playing end for quickly playing subsequent live broadcast images is reduced because at least one group of image group data is obtained at the side of the playing end, wherein the data comprises an I frame, a plurality of P frames and a B frame of a complete image, based on the image frames, even if in the live broadcast process, some delay of the image group data exists, based on the received image group data, a video picture can be still rendered in a short time, and therefore the phenomenon of black screen or severe pause cannot occur. Therefore, after the second start is completed, for the following conventional live broadcast data, namely the live broadcast data after the data of the first group of image groups, the third smooth sending speed which is less than the second smooth sending speed can be adopted to send the video data, so that the live broadcast data transmission in the whole live broadcast process is smoothly processed in the time dimension, the data spike is avoided, and the fluency in the live broadcast process is improved.
In addition, for the subsequent image group, since an I frame is inevitably present in each image group, in the case of insufficient bandwidth, data shock due to the I frame still occurs. Since a large I-frame impact may cause a lag in audio data, it is possible to process this in such a manner that, in the smooth transmission processing for the subsequent image group, audio data corresponding to image data in the image group is preferentially transmitted and then image data is transmitted. And at the second starting stage, the image group data and the audio data can be sent in a default audio-video interleaving mode, the video data of the image group can be sent preferentially, and then the corresponding audio data is sent, so that the requirement of quickly starting the live broadcast picture in seconds is met as far as possible.
Alternatively, the video data corresponding to the first image group may be smoothly transmitted at a rate of two levels. Specifically, the image data of the I frame in the subsequent image group is transmitted at a fourth smooth transmission speed, and the image data of the other frames than the I frame in the subsequent image group is transmitted at a fifth smooth transmission speed, wherein the fourth smooth transmission speed is lower than the second smooth transmission speed, and the fifth smooth transmission speed is lower than the fourth smooth transmission speed.
Further, the smooth sending speed of each stage can be determined according to the code rate of the live broadcast end and/or according to the feedback of the live broadcast data. The code rate of the live broadcast end refers to the data size coded by the coder per second, the code rate of the live broadcast end can be set by the live broadcast end and can be regarded as a preset value, and the higher the code rate of the live broadcast end is, the higher the required smooth sending speed is. The live broadcast data feedback refers to a post-event feedback mechanism, that is, after a smoothing process is performed at a certain smooth sending speed, feedback data is obtained from a broadcast end to evaluate whether the currently set smooth sending speed is reasonable, and after data sending of the first I frame and the remaining frames in the first group of GOP data is completed at the current first smooth sending speed and the second smooth sending speed, for example, a second-on stage is taken as an example, data feedback of the fluency degree of actual second-on live broadcast pictures and subsequent several frames of pictures can be obtained from a large number of broadcast ends, so that the first smooth sending speed and the second smooth sending speed are optimized according to the information, and the broadcast end which subsequently reenters the live broadcast room can obtain better user experience of second-on live broadcast.
Further, after the smooth transmission speed used at a certain stage is determined, data transmission may be performed by calling a packet transmission interface function based on the UDP protocol. In the embodiment of the invention, a UDP multi-packet sending mechanism can be adopted to send UDP data packets in batch, thereby reducing the times of calling interface functions and saving the occupancy rate of a CPU. Specifically, the sendmsg function may be invoked for bulk transmission of multiple UDP packets.
Further, the UDP multi-packet sending function may be called at a preset time interval, and the amount of data sent by calling the UDP multi-packet sending function each time, that is, the number of UDP data packets, may be determined according to the preset time interval and the currently adopted smooth sending rate.
According to the processing method of the live broadcast data, disclosed by the embodiment of the invention, the corresponding smooth sending processing strategies are executed according to different live broadcast data sending stages, so that the phenomena of packet loss and image blockage caused by data burst are relieved, and a smoother live broadcast experience is provided for a user at a playing end.
Example two
As shown in fig. 7, which is a schematic structural diagram of a live data processing apparatus according to an embodiment of the present invention, the apparatus may be applied to a CDN node that sends live data, and specifically, the apparatus includes:
and the first smoothing processing module 11 is configured to send, in response to a live broadcast request sent by a play end, image data of an I frame of a first image group at a first smoothing sending speed.
The I frame is positioned in the first frame of the image group and is a complete image, the following P frame and B frame need to be decoded depending on the I frame, the first I frame is the initial frame of the whole video image sequence, and the live broadcast picture can be displayed as long as the first I frame is obtained. Therefore, in configuring the smooth transmission speed, the first smooth transmission speed with the highest speed is configured for the first I frame, and the first smooth transmission speed may be configured as the maximum transmission speed without occurrence of packet loss.
A second smoothing processing module 12, configured to send image data of other frames than the I frame of the first image group at a second smoothing sending speed, where the first smoothing sending speed is greater than the second smoothing sending speed.
After the first I frame is transmitted, the remaining P and B frames in the data for the first group of pictures can be transmitted using a second, relatively large smooth transmission rate. Because the data volume of the P frame and the B frame is smaller than that of the I frame, the playing end can still continuously obtain the image frames under the condition that the data volume is smaller than the first smooth sending speed, so that a user can immediately see continuous pictures after quickly opening a live video picture, and the smoothness of data sending and the picture continuity in the second opening stage are considered.
The module finishes smooth sending processing aiming at the first image group, and because the time period with the most serious data burst is the initial stage of requesting live data when a large number of playing terminals simultaneously enter a live broadcasting room in a live broadcasting scene, the second-turn-on experience of quickly entering a live broadcasting picture is hoped to be provided for a user in the stage, and the configured smooth sending speed is higher. After the second-on stage, the data of the subsequent image group can be transmitted at different transmission speeds according to the network conditions, for example, the image data of the video frame in the subsequent image group is transmitted at the transmission speed determined by the congestion control strategy, because the data burst phenomenon is relatively weakened. Alternatively, the following modules may be used for transmission.
And a third smoothing processing block 13 configured to transmit image data of a video frame of a subsequent image group at a third smoothing transmission rate, which is lower than the second smoothing transmission rate.
After the second live broadcast stage, the urgency of the broadcast end for fast broadcasting the subsequent live broadcast image is reduced, because at least one group of image group data is obtained at the broadcast end side, wherein the data comprises an I frame, a plurality of P frames and a B frame of a complete image, and based on the image frames, even if some image group data delay exists in the live broadcast process, based on the received image group data, the video picture can be still rendered in a short time, so that the phenomenon of black screen or serious blockage can not occur. Therefore, after the second-starting is completed, for the later conventional live broadcast data, namely the live broadcast data after the data of the first group of image groups, the third smooth sending speed which is less than the second smooth sending speed can be adopted to send the video data, so that the live broadcast data transmission in the whole live broadcast process is gently processed in the time dimension, the data spike is avoided, and the fluency in the live broadcast process is improved.
In addition, for the subsequent image group, since an I frame is inevitably present in each image group, in the case of insufficient bandwidth, data shock due to the I frame still occurs. Since a large I-frame impact may cause a lag in audio data, it is possible to process this in such a manner that, in the smooth transmission processing for the subsequent image group, audio data corresponding to image data in the image group is preferentially transmitted and then image data is transmitted. And at the second starting stage, the image group data and the audio data can be sent in a default audio-video interleaving mode, the video data of the image group can be sent preferentially, and then the corresponding audio data is sent, so that the requirement of quickly starting the live broadcast picture in seconds is met as far as possible.
Alternatively, the video data corresponding to the first image group may be smoothly transmitted at a rate of two levels. Specifically, image data of an I frame in a subsequent image group is transmitted at a fourth smooth transmission speed, which is lower than the second smooth transmission speed, and image data of frames other than the I frame in the subsequent image group is transmitted at a fifth smooth transmission speed, which is lower than the fourth smooth transmission speed.
Further, the apparatus may further include a smooth sending speed determining module 14, configured to determine a smooth sending speed corresponding to the live broadcast end according to the code rate of the live broadcast end and/or the live broadcast data feedback. The code rate of the live broadcast end refers to the data size coded by the coder per second, the code rate of the live broadcast end can be set by the live broadcast end and can be regarded as a preset value, and the higher the code rate of the live broadcast end is, the higher the required smooth sending speed is. The above-mentioned feedback of live broadcast data refers to a post-event feedback mechanism, that is, after performing smoothing processing at a certain smooth sending speed, feedback data is obtained from the playing end to evaluate whether the currently set smooth sending speed is reasonable.
Further, after the smooth transmission speed used at a certain stage is determined, data transmission may be performed by calling a packet transmission interface function based on the UDP protocol. In the embodiment of the invention, a UDP multi-packet sending mechanism can be adopted to send UDP data packets in batch, thereby reducing the times of calling interface functions and saving the occupancy rate of a CPU. Specifically, the sendmsg function may be invoked for bulk transmission of multiple UDP packets. Further, the UDP multi-packet sending function may be called at preset time intervals, and the data amount sent by calling the UDP multi-packet sending function each time, that is, the number of UDP data packets, may be determined according to the preset time intervals and the currently adopted smooth sending rate.
According to the processing device of the live broadcast data, disclosed by the embodiment of the invention, the corresponding smooth sending processing strategies are executed according to different live broadcast data sending stages, so that the phenomena of packet loss and image blockage caused by data burst are relieved, and a smoother live broadcast experience is provided for a user at a playing end.
EXAMPLE III
The embodiment of the invention provides a method for processing live broadcast data, which can be applied to CDN nodes for sending the live broadcast data, and specifically comprises the following steps:
s201: and acquiring the code rate of the live broadcast end and/or the number of the playing ends requesting the live broadcast data. The code rate of the live broadcast end is the data size coded by a coder configured by the live broadcast end per second, the code rate can be set by a user of the live broadcast end within the processing capacity range of hardware and software configuration of the live broadcast end, and the code rate can also be set by the live broadcast service platform according to the grade of a live broadcast user or a selected service grade in live broadcast based on the live broadcast service platform. The code rate of the live broadcast end directly determines the transmission quantity of live broadcast data in the live broadcast process, and the higher the code rate of the live broadcast end is, the higher the required smooth sending speed is. In addition, the playing end requesting live data includes a playing end that has just joined the live broadcast and requests live data, and also includes a playing end that has sent the live broadcast data request and is currently in the live broadcast. For live broadcasting of a certain live broadcasting end, the larger the number of the playing ends requesting live broadcasting data is, the larger the data volume that the CDN network needs to transmit to the playing ends is, and thus, a data burst situation is more easily formed. The code rate of the live broadcast end can be obtained from the configuration data of the live broadcast service platform to the live broadcast end, and can also be directly obtained from the live broadcast end when the live broadcast end is started.
S202: and determining smooth sending speeds of multiple levels according to the code rate of the live broadcast end and/or the number of the playing ends requesting the live broadcast data. As described above, the bit rate of the live broadcast end and the number of the broadcast ends have a large influence on the amount of live broadcast transmission data, and the situation of data burst can be effectively estimated by acquiring the two data, so as to determine a reasonable smooth transmission speed. It should be noted that the code rate of the live broadcast end and the number of the broadcast ends may be dynamically changed, and the CDN node may periodically obtain the code rate of the live broadcast end and count the number of the broadcast ends requesting the live broadcast data, so as to dynamically determine the smooth sending speed. The smooth sending speed of the multiple levels can be determined according to the actual smooth sending strategy, and for example, the smooth sending speed can be set to three levels or four levels so as to correspond to different stages of the live broadcasting process. The specific setting value of the smooth sending speed can be set according to an empirical value, and can also be dynamically adjusted according to the feedback of the live broadcast data of the broadcast end.
S203: and dynamically configuring the smooth sending speeds of the multiple levels according to the live broadcasting process corresponding to each playing end to send the live broadcasting data. As described in the foregoing embodiments, the embodiment of the present invention may adopt a hierarchical smoothing process for live data in different stages, and as an example, the following two smoothing sending strategies may be adopted: 1) Smooth transmission speed is divided into three levels: a first smooth transmission speed, a second smooth transmission speed and a third smooth transmission speed which are decreased in sequence. Accordingly, the step S203 may include:
responding to a live broadcast request sent by a broadcast end, sending image data of a key frame of a first image group at a first smooth sending speed, then sending image data of other frames except the key frame of the first image group at a second smooth sending speed, and finally sending image data of a video frame of a subsequent image group at a third smooth sending speed. In this strategy, the image data of the first image group is classified into the first key frame and frames other than the first key frame for hierarchical transmission, and the image group following the first image group is transmitted as normal video data at a relatively low smoothing speed.
2) Smooth transmission speeds are divided into four levels: a first smooth transmission speed, a second smooth transmission speed, a fourth smooth transmission speed, and a fifth smooth transmission speed that are sequentially decreased. Accordingly, the step S203 may include:
and responding to a live broadcast request sent by a playing end, sending the image data of the key frame of the first image group at a first smooth sending speed, and then sending the image data of other frames except the key frame of the first image group at a second smooth sending speed. Then, the image data of the key frame in the subsequent image group is transmitted at the fourth smooth transmission speed, and the image data of the other frames than the key frame in the subsequent image group is transmitted at the fifth smooth transmission speed. In this strategy, image data of the first image group is classified into the first key frame and frames other than the first key frame for hierarchical transmission, and the image groups subsequent to the first image group are still classified into two levels and transmitted at a fourth smooth transmission speed and a fifth smooth transmission speed, which are relatively small.
The foregoing introduces a sending policy for image data, and for audio data, different policies may also be adopted according to different stages of live broadcasting, and specifically, may include: in the process of sending the image data of the first image group, the image data and the corresponding audio data can be sent in an audio-video interlaced mode, in addition, in the process of sending the image data of the subsequent image group, the corresponding audio data can be sent firstly, and then the image data is sent.
It should be noted that, the above-mentioned strategies are performed separately for the live broadcast process of each playing end, so that each playing end can obtain a smooth processing effect, and the live broadcast effect is smoother.
According to the processing method of the live broadcast data, the grading smooth processing strategy is implemented according to different live broadcast stages, and the reasonable smooth sending speed is determined according to the code rate of the live broadcast end and the number of the broadcast ends, so that the problems of packet loss and image blockage caused by data burst can be effectively reduced, and the live broadcast quality is improved.
Example four
The foregoing embodiment describes a flow process and a device structure of a live data processing method, and functions of the method and the device may be implemented by an electronic device, as shown in fig. 8, which is a schematic structural diagram of the electronic device according to an embodiment of the present invention, and specifically includes: a memory 110 and a processor 120.
And a memory 110 for storing a program.
In addition to the programs described above, the memory 110 may also be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device, contact data, phonebook data, messages, pictures, videos, and so forth.
The memory 110 may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.
The processor 120, coupled to the memory 110, is configured to execute the program in the memory 110 to perform the operation steps of the processing method of the live data described in the foregoing embodiments.
Furthermore, the processor 120 may also include various modules described in the foregoing embodiments to perform processing of live data, and the memory 110 may be used, for example, to store data required by the modules to perform operations and/or output data.
The above detailed descriptions of the processing procedure, the technical principle, and the technical effect are detailed in the foregoing embodiments, and are not repeated herein.
Further, as shown, the electronic device may further include: communication components 130, power components 140, audio components 150, display 160, and other components. Only some of the components are schematically shown in the figure and it is not meant that the electronic device comprises only the components shown in the figure.
The communication component 130 is configured to facilitate wired or wireless communication between the electronic device and other devices. The electronic device may access a wireless network based on a communication standard, such as WiFi, a mobile communication network such as 2G, 3G, 4G/LTE, 5G, or a combination thereof. In an exemplary embodiment, the communication component 130 receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 130 further includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UWB) technology, bluetooth (BT) technology, and other technologies.
A power supply component 140 provides power to the various components of the electronic device. The power components 140 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for an electronic device.
The audio component 150 is configured to output and/or input audio signals. For example, the audio component 150 includes a Microphone (MIC) configured to receive external audio signals when the electronic device is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal may further be stored in the memory 110 or transmitted via the communication component 130. In some embodiments, audio assembly 150 also includes a speaker for outputting audio signals.
The display 160 includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.
Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The aforementioned program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.
Claims (16)
1. A method for processing live data comprises the following steps:
responding to a live broadcast request sent by a playing end, and sending image data of a key frame of a first image group at a first smooth sending speed;
sending image data of other frames except the key frame of the first image group at a second smooth sending speed, wherein the first smooth sending speed is greater than the second smooth sending speed;
transmitting image data of a key frame in a subsequent image group at a fourth smooth transmission speed, transmitting image data of frames other than the key frame in the subsequent image group at a fifth smooth transmission speed, wherein the fourth smooth transmission speed is lower than the second smooth transmission speed, the fifth smooth transmission speed is lower than the fourth smooth transmission speed,
and determining a smooth sending speed corresponding to the live broadcast end according to the code rate of the live broadcast end and/or the feedback of live broadcast data.
2. The method of claim 1, further comprising:
image data of a video frame of a subsequent image group is transmitted at a third smooth transmission speed, which is smaller than the second smooth transmission speed.
3. The method of claim 1, further comprising:
and transmitting the image data of the video frame in the subsequent image group according to the transmission speed determined by the congestion control strategy.
4. The method according to claim 2 or 3, wherein in transmitting the image data of the subsequent group of images, the corresponding audio data is transmitted first, and then the image data is transmitted.
5. The method of claim 1, wherein during the transmitting of the image data of the first image group, the image data and the corresponding audio data are transmitted in an audio-video interleaved manner.
6. The method according to claim 1 or 2, wherein during the smooth transmission, the data transmission is performed by using a UDP multi-packet transmission mechanism at preset time intervals.
7. The method of claim 6, further comprising: and calculating the number of UDP data packets sent by the UDP multi-packet according to the smooth sending speed and a preset time interval.
8. A device for processing live data, comprising:
the first smoothing processing module is used for responding to a live broadcast playing request sent by a playing end and sending image data of a key frame of a first image group at a first smoothing sending speed;
a second smoothing processing module, configured to send image data of other frames than the key frame of the first image group at a second smoothing sending speed, where the first smoothing sending speed is greater than the second smoothing sending speed, send image data of the key frame in a subsequent image group at a fourth smoothing sending speed, and send image data of other frames than the key frame in the subsequent image group at a fifth smoothing sending speed, where the fourth smoothing sending speed is less than the second smoothing sending speed, and the fifth smoothing sending speed is less than the fourth smoothing sending speed;
and the smooth sending speed determining module is used for determining the smooth sending speed corresponding to the live broadcast end according to the code rate of the live broadcast end and the feedback of the live broadcast data.
9. The apparatus of claim 8, further comprising:
and the third smoothing processing module is used for sending the image data of the video frame of the subsequent image group at a third smoothing sending speed, and the third smoothing sending speed is less than the second smoothing sending speed.
10. The apparatus according to claim 9, wherein in transmitting the image data of the subsequent image group, the corresponding audio data is transmitted first, and then the image data is transmitted.
11. The apparatus according to claim 8 or 9, wherein during the smooth sending, the data is sent using a UDP multi-packet sending mechanism at preset time intervals.
12. A method for processing live data comprises the following steps:
acquiring the code rate of a live broadcast end and/or the number of playing ends requesting live broadcast data;
determining smooth sending speeds of multiple levels according to the code rate of the live broadcast end and/or the number of the playing ends requesting the live broadcast data;
dynamically configuring the smooth sending speeds of the multiple levels to send live broadcast data according to the live broadcast process corresponding to each playing end;
the multiple levels of smooth sending speeds at least comprise a first smooth sending speed, a second smooth sending speed, a fourth smooth sending speed and a fifth smooth sending speed which are sequentially decreased, and the step of dynamically configuring the multiple levels of smooth sending speeds to send live broadcast data according to the stage of the live broadcast process corresponding to each playing end comprises the following steps of:
responding to a live broadcast request sent by a playing end, and sending image data of a key frame of a first image group at a first smooth sending speed;
transmitting image data of frames other than the key frame of the first image group at a second smooth transmission speed; the image data of the key frame in the subsequent image group is transmitted at the fourth smooth transmission speed, and the image data of frames other than the key frame in the subsequent image group is transmitted at the fifth smooth transmission speed.
13. The method as claimed in claim 12, wherein the multiple levels of smooth sending speeds include at least a first smooth sending speed, a second smooth sending speed, and a third smooth sending speed that decrease in sequence, and the dynamically configuring the multiple levels of smooth sending speeds to send live broadcast data according to the stage of the live broadcast process corresponding to each playing terminal includes:
responding to a live broadcast request sent by a playing end, and sending image data of a key frame of a first image group at a first smooth sending speed;
transmitting image data of frames other than the key frame of the first image group at a second smooth transmission speed;
image data of a video frame of a subsequent image group is transmitted at the third smooth transmission speed.
14. The method of claim 13, wherein,
in the process of sending the image data of the first image group, sending the image data and the corresponding audio data in an audio and video interleaving mode;
and/or the presence of a gas in the gas,
and in the process of sending the image data of the subsequent image group, sending the corresponding audio data first and then sending the image data.
15. The method of claim 12, further comprising: and acquiring the live broadcast data feedback reported by a broadcast end, and adjusting the smooth sending speeds of the multiple levels according to the live broadcast data feedback.
16. An electronic device, comprising:
a memory for storing a program;
a processor for executing the program stored in the memory to execute the processing method of live data according to any one of claims 1 to 7 and 12 to 15.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011606495.4A CN113242436B (en) | 2020-12-28 | 2020-12-28 | Live broadcast data processing method and device and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011606495.4A CN113242436B (en) | 2020-12-28 | 2020-12-28 | Live broadcast data processing method and device and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113242436A CN113242436A (en) | 2021-08-10 |
| CN113242436B true CN113242436B (en) | 2023-01-03 |
Family
ID=77129986
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011606495.4A Active CN113242436B (en) | 2020-12-28 | 2020-12-28 | Live broadcast data processing method and device and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113242436B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113765919B (en) * | 2021-09-07 | 2023-11-03 | 深圳市瑞云科技有限公司 | Method for improving UDP message sending efficiency of Linux system |
| CN115396702B (en) * | 2022-05-23 | 2024-01-23 | 广州市奥威亚电子科技有限公司 | Video transmission method, device, electronic equipment and storage medium |
| CN115002086B (en) * | 2022-05-23 | 2024-04-02 | 阿里巴巴（中国）有限公司 | Real-time streaming media transmission method and electronic equipment |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101480469B1 (en) * | 2008-12-01 | 2015-01-09 | 엘지전자 주식회사 | Image display device, image transmitting device, method for transmitting image and recording medium |
| CN101600107B (en) * | 2009-07-08 | 2012-01-25 | 杭州华三通信技术有限公司 | Method for adjusting play speed of videotape as well as system and device |
| US9485546B2 (en) * | 2010-06-29 | 2016-11-01 | Qualcomm Incorporated | Signaling video samples for trick mode video representations |
| EP2413604B1 (en) * | 2010-07-30 | 2014-09-10 | Deutsche Telekom AG | Assessing the quality of a video signal during encoding or compressing of the video signal |
| CN102843580A (en) * | 2012-09-03 | 2012-12-26 | 国网电力科学研究院 | Method for displaying image of video monitoring system by inserting I frame forcibly |
| CN103780907B (en) * | 2014-01-27 | 2018-01-16 | 浙江宇视科技有限公司 | A kind of method and apparatus of video data flow shaping |
| KR102078869B1 (en) * | 2015-03-17 | 2020-02-18 | 삼성전자주식회사 | Method and apparatus for controlling multi connection improving data transfer rate |
| CN107948664B (en) * | 2017-11-20 | 2020-10-16 | 广州虎牙信息科技有限公司 | Live broadcast room video playing control method and device and terminal |
-
2020
- 2020-12-28 CN CN202011606495.4A patent/CN113242436B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN113242436A (en) | 2021-08-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113242436B (en) | Live broadcast data processing method and device and electronic equipment | |
| US10728594B2 (en) | Method and apparatus for transmitting data of mobile terminal | |
| US11349900B2 (en) | Voice encoding and sending method and apparatus | |
| Hu et al. | Energy-aware video streaming on smartphones | |
| US20090222873A1 (en) | Multimedia Channel Switching | |
| US20140108622A1 (en) | Streaming media transmission method, device, and system | |
| JP5421346B2 (en) | High-speed transmission method and apparatus for unicast stream in high-speed channel change | |
| US20080133766A1 (en) | Method and apparatus for streaming media to a plurality of adaptive client devices | |
| US8594184B2 (en) | Method and apparatus for controlling video-audio data playing | |
| US9143810B2 (en) | Method for manually optimizing jitter, delay and synch levels in audio-video transmission | |
| CN112822502B (en) | Live broadcast jitter removal intelligent caching and live broadcast method, equipment and storage medium | |
| JP4903435B2 (en) | Media signal transmission method and reception method, and transmission / reception method and apparatus | |
| CN101938456A (en) | Method, device and system for reducing media delays | |
| JP5140952B2 (en) | Content distribution system, content distribution server, content reproduction terminal, program, and content distribution method | |
| JP2002290974A (en) | Transmission rate control method | |
| WO2007080788A1 (en) | Teleconference control device and teleconference control method | |
| KR20180031673A (en) | Switching display devices in video telephony | |
| CN101090369B (en) | Method for controlling data packet sending speed in flow medium system | |
| US8612552B2 (en) | Method for buffering streaming data and a terminal device | |
| CN116962613A (en) | Data transmission method and device, computer equipment and storage medium | |
| CN105306970B (en) | A kind of control method and device of live streaming media transmission speed | |
| EP3970384B1 (en) | Method and apparatus for playing multimedia streaming data | |
| KR20130122117A (en) | Method and apparatus for transmitting a moving image in a real time | |
| US8791981B2 (en) | Bit rate control apparatus and method thereof | |
| US10097609B1 (en) | Method and system for dynamically adjusting a data rate of a video stream |
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 | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40056828 Country of ref document: HK |
|
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: Room 554, 5 / F, building 3, 969 Wenyi West Road, Wuchang Street, Yuhang District, Hangzhou City, Zhejiang Province Applicant after: Alibaba (China) Co.,Ltd. Address before: 311121 room 508, floor 5, building 4, No. 699, Wangshang Road, Changhe street, Binjiang District, Hangzhou, Zhejiang Province Applicant before: Alibaba (China) Co.,Ltd. |
|
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20221117 Address after: Room 554, 5 / F, building 3, 969 Wenyi West Road, Wuchang Street, Yuhang District, Hangzhou City, Zhejiang Province Applicant after: TAOBAO (CHINA) SOFTWARE CO.,LTD. Address before: Room 554, 5 / F, building 3, 969 Wenyi West Road, Wuchang Street, Yuhang District, Hangzhou City, Zhejiang Province Applicant before: Alibaba (China) Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |