CN113596568B - Video playing method and device, intelligent terminal and computer readable storage medium - Google Patents
Video playing method and device, intelligent terminal and computer readable storage medium Download PDFInfo
- Publication number
- CN113596568B CN113596568B CN202110745960.0A CN202110745960A CN113596568B CN 113596568 B CN113596568 B CN 113596568B CN 202110745960 A CN202110745960 A CN 202110745960A CN 113596568 B CN113596568 B CN 113596568B
- Authority
- CN
- China
- Prior art keywords
- frame
- video
- frame rate
- playing
- live
- 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
- 238000000034 method Methods 0.000 title claims abstract description 46
- 230000004044 response Effects 0.000 claims abstract description 41
- 238000001514 detection method Methods 0.000 claims description 5
- 238000010586 diagram Methods 0.000 description 8
- 230000000903 blocking effect Effects 0.000 description 7
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/426—Internal components of the client ; Characteristics thereof
- H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4383—Accessing a communication channel
- H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44227—Monitoring of local network, e.g. connection or bandwidth variations; Detecting new devices in the local network
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
The application discloses a video playing method, a device, an intelligent terminal and a computer readable storage medium, wherein the video playing method comprises the following steps: the client receives a video stream sent by a video server; responding to the video frame of the video stream as a quick access frame, playing the quick access frame, and detecting the receiving frame rate of the current received video stream; responding to the received frame rate being greater than or equal to the first set frame rate, continuing to play the quick access frame; and in response to the received frame rate being smaller than the first set frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame. According to the scheme, the video playing method can timely respond to the fact that the video frames of the video stream are switched from the quick access frames to the live video frames, and timely play the live video frames, so that the video playing method can be effectively suitable for different quick access time durations corresponding to different video servers, and can keep lower playing delay.
Description
Technical Field
The present application relates to the field of internet technologies, and in particular, to a video playing method, a video playing device, an intelligent terminal, and a computer readable storage medium.
Background
With the development of the internet and intelligent terminals, the demands of users are also changing, for example, video watching through a network live broadcast manner is more and more sought after and popular with users. The network live broadcast refers to a playing mode that live broadcast data can be watched on an exchange platform through a network. The live data may be multimedia data such as video, audio and/or text. The network live broadcast application based on various intelligent terminal devices such as a computer, a mobile phone, a tablet and the like is greatly popularized, so that a user can watch live broadcast data at any time through the intelligent terminal devices.
In a live scenario, in order to speed up the video "second on", when a video server (CDN, content Delivery Network, content delivery network, herein understood as a video server) is requested by a live APP (application program) on a client, the CDN will typically first issue a "quick access frame" whose corresponding play duration is typically in the range of 1-2 GOPs (Group of Pictures ) (6 seconds or so), depending on how much cache data is at the edge node of the CDN. When the live APP receives the quick access frame, corresponding audio and video can be immediately played. The CDN inserts a quick access frame about 6 seconds before normal live broadcast data, so that a live broadcast APP can quickly receive a large number of video frames in a play-up stage, and on one hand, the video can be quickly played up to play out the video; on the other hand, local cache can be quickly filled to resist the weak network card on phenomenon in the subsequent normal playing process.
However, in practical applications, implementation details of the CDNs will be different, and there is a great difference that the duration of the quick access frames issued by the CDNs will be quite different, and the range of the quick access frames is between 4 and 15 seconds. The live APP of the client cannot detect the difference, and cannot determine whether the currently received video frame is a quick access frame, so that after the client is shifted to a normal live broadcast mode according to its normal setting, the corresponding CDN still does not end the sending of the quick access frame, so that the client can play the currently received video frame in the normal live broadcast mode, but the currently received quick access frame is actually old data, which is equivalent to that the play starting delay is greater for the audience, and the currently watched video frame is the previous video frame, which is hardly accepted for some live broadcast scenes with strict delay requirements.
Disclosure of Invention
The application mainly solves the technical problem of providing a video playing method, a video playing device, an intelligent terminal and a computer readable storage medium, so as to solve the problem of higher playing delay of the video playing method in a live scene in the prior art.
In order to solve the above problems, a first aspect of the present application provides a video playing method of a live scene, where the video playing method includes: the client receives a video stream sent by a video server; responding to the video frame of the video stream as a quick access frame, playing the quick access frame, and detecting the receiving frame rate of the current received video stream; responding to the received frame rate being greater than or equal to the first set frame rate, continuing to play the quick access frame; and in response to the received frame rate being smaller than the first set frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
Wherein, in response to the received frame rate being greater than or equal to the first set frame rate, continuing to play the fast access frame, including: responding to the first set multiple of the received frame rate greater than the playing frame rate, and continuing to play the quick access frame; wherein the first set multiple is greater than 1; and in response to the received frame rate being less than the first set frame rate, determining that the video frame of the currently received video stream is a live video frame, playing the live video frame, including: and in response to the received frame rate being smaller than the first set multiple of the playing frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
Wherein, in response to the received frame rate being less than the first set multiple of the play frame rate, determining that the video frame of the currently received video stream is a live video frame, playing the live video frame, comprising: responding to the first set multiple of which the receiving frame rate is smaller than the playing frame rate and the second set multiple of which is larger than the playing frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame; wherein the second set multiple is less than 1.
Wherein, in response to the received frame rate being less than the set frame rate, determining that the video frame of the currently received video stream is a live video frame, playing the live video frame, comprising: in response to the received frame rate being less than the first set frame rate and greater than the second set frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame; wherein the second set frame rate is less than the first set frame rate.
Wherein, in response to the received frame rate being less than the set frame rate, determining that the video frame of the currently received video stream is a live video frame, playing the live video frame, comprising: and in response to detecting that the received frame rate is smaller than the first set frame rate at least twice continuously, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
Wherein, in response to detecting that the received frame rate is less than the first set frame rate at least twice in succession, determining that the video frame of the currently received video stream is a live video frame, playing the live video frame, comprises: in response to detecting that the received frame rate is less than the first set frame rate and greater than the third set frame rate at least twice in succession, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame; wherein the third set frame rate is less than the first set frame rate.
The network connection bandwidth between the client and the video server is greater than or equal to a first set frame rate.
In order to solve the above-described problems, a second aspect of the present application provides a video playback device, wherein the video playback device includes: the receiving module is used for receiving the video stream sent by the video server; the detection module is used for detecting the receiving frame rate of the current received video stream; and the playing module is used for playing the quick access frame when the video frame of the video stream is the quick access frame, continuing to play the quick access frame when the receiving frame rate is larger than or equal to the first set frame rate, and determining the video frame of the currently received video stream to be a live video frame when the receiving frame rate is smaller than the first set frame rate, and playing the live video frame.
In order to solve the above-mentioned problems, a third aspect of the present application provides a mobile intelligent terminal, wherein the intelligent terminal includes a memory and a processor, which are coupled to each other, and the processor is configured to execute program instructions stored in the memory, so as to implement the video playing method of the first aspect.
In order to solve the above-mentioned problems, a fourth aspect of the present application provides a computer-readable storage medium having stored thereon program instructions which, when executed by a processor, implement the video playback method of the first aspect described above.
The beneficial effects of the application are as follows: compared with the prior art, the video playing method is characterized in that when a client receives a video stream sent by a video server, the video frame responding to the video stream is a quick access frame, the quick access frame is played, the receiving frame rate of the currently received video stream is detected, so that the quick access frame can be further played continuously in response to the receiving frame rate being greater than or equal to a first set frame rate, when the receiving frame rate is smaller than the first set frame rate, the video frame of the currently received video stream is determined to be a live video frame, the live video frame is played, so that the video frame responding to the video stream can be timely switched to the live video frame by the quick access frame, and the playing of the live video frame is timely carried out, thereby being capable of effectively adapting to different quick access durations corresponding to different video servers, keeping lower playing delay, and playing a great optimization effect on the whole end-to-end delay on the premise that the playing buffer strategy of the client is not adjusted and the playing blocking mode is not affected.
Drawings
FIG. 1 is a schematic diagram of a video server sending a video stream to a client in a specific live scene;
FIG. 2 is a flowchart of a video playing method according to a first embodiment of the present application;
FIG. 3 is a flowchart of a video playing method according to a second embodiment of the present application;
FIG. 4 is a schematic diagram of a video playback device according to an embodiment of the present application;
FIG. 5 is a schematic diagram of a framework of an embodiment of a smart terminal according to the present application;
FIG. 6 is a schematic diagram of a frame of one embodiment of a computer-readable storage medium of the present application.
Detailed Description
The inventor finds that in a live broadcast scene, in order to accelerate the speed of video "second on", when a live broadcast APP on a client requests a video stream from a video server, the CDN generally issues a section of "quick access frame" first, and the corresponding play duration is usually in the range of 1-2 GOPs (about 6 seconds) depending on how much cache data of the CDN edge node exists. When the live APP receives the quick access frame, corresponding audio and video can be immediately played. The CDN inserts a quick access frame about 6 seconds before normal live broadcast data, so that a live broadcast APP can quickly receive a large number of video frames in a play-up stage, and on one hand, the video can be quickly played up to play out the video; on the other hand, local cache can be quickly filled to resist the weak network card blocking phenomenon in the subsequent normal playing process, so that the problem of blocking caused by insufficient cache when video is opened for a second is solved.
However, in practical applications, implementation details of CDNs will generally be different, and there is a relatively large difference that the duration of the quick access frames delivered by CDNs will be relatively large, which ranges from 4 to 15 seconds. The live APP of the client cannot detect the difference, and cannot determine whether the currently received video frame is a fast access frame (the video frame has no flag to indicate whether the video frame is a fast access frame), but only considers that the fast access phase is finished after receiving the data (calculated according to the difference between the current frame and the first frame) with the playing duration set to 6 seconds, and defaults all the subsequently received video frames to normal live video frames.
Fig. 1 is a schematic diagram of a video server sending a video stream to a client in a specific live scene, as shown in fig. 1. When the CDN issues more than one quick access frame (for example, a quick access frame with a play duration of 12 seconds), after the live APP transitions to the normal receiving mode according to the set play duration of 6 seconds, that is, after the live APP enters the B-stage from the a-stage, there is still a situation that a large number of quick access frames (for example, 6 seconds) continue to be received, and the live APP considers that these are normal live frames, so that the live APP enters the normal live mode (plays currently received data in real time), that is, the live APP misconsiders that the quick access data received in the B-stage is normal live data. However, the data received in the B-stage is actually old data before 6 seconds, not the current live data generated in real time, which is equivalent to that the delay of playing is increased for the audience, and the audience views the video before 6 seconds, which is hardly acceptable for some scenes with strict delay requirements.
In order to ensure lower play delay, the application provides a video playing method of a live broadcast scene, which optimizes the integral end-to-end delay characteristic in live broadcast on the premise of not adjusting play buffer and not affecting the blocking. The application is described in further detail below with reference to the drawings and examples. It is specifically noted that the following examples are only for illustrating the present application, but do not limit the scope of the present application. Likewise, the following examples are only some, but not all, of the examples of the present application, and all other examples, which a person of ordinary skill in the art would obtain without making any inventive effort, are within the scope of the present application.
Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.
Referring to fig. 2, fig. 2 is a flowchart illustrating a video playing method according to a first embodiment of the present application. Specifically, the method may include the steps of:
s11: the client receives the video stream sent by the video server.
With the rapid development of the live broadcast industry, live broadcast has brought much convenience to people's daily life and work. For the anchor and audience in the live broadcast scene, on the premise of not adjusting the cache mode when the client plays and not affecting the blocking, namely in the scene of still adopting the quick access frame in the playing stage, how to realize low delay when playing from end to end so as to increase the ornamental value and the attractive force, which is a key point affecting the user experience, is also a key factor affecting the user watching frequency and selecting watching intention in the playing stage, and greatly affects the development of the live broadcast platform. In this embodiment, the video playing method of the live broadcast scene may be applied to a terminal device for live broadcast, and live broadcast in the present application may be in various live broadcast forms.
It can be understood that the client is a terminal device corresponding to a viewer who intends to watch live broadcast, and the video server is a server device providing live broadcast network services, so as to be able to distribute a video stream acquired from the live broadcast terminal to each corresponding client.
Specifically, the client continues to receive the video stream sent by the video server. It will be appreciated that the video stream specifically includes a quick access frame and a live video frame, and that the quick access frame occurs only during a start-up phase in which the client initially receives and plays the video stream, and is sent by the video server to the client prior to the live video frame.
The fast access frame specifically means that the corresponding playing time length is within the range of 1-3 GOP (between 4-15 seconds), depending on how much cache data of the CDN edge node is, and the video server can quickly send the fast access frame to the client in any reasonable time that is far lower than the playing time length, for example, 1S or 3S, and immediately starts sending the live video frame after the sending is completed, and the corresponding sending and receiving speeds specifically depend on the bandwidth between the client and the video server, so that the playing of the video stream can be quickly performed in the unstable playing stage of the network, and the occurrence of jamming is avoided.
Optionally, the client may be any reasonable intelligent terminal such as a computer, a tablet computer, a smart phone, a smart watch, and the like, which is not limited in the present application.
S12: and responding to the video frame of the video stream as the quick access frame, playing the quick access frame, and detecting the receiving frame rate of the current received video stream.
It will be appreciated that for a client, the video frame of the video stream itself is a fast access frame without a flag to indicate whether it is a fast access frame, so it is only possible to analyze and identify from other features which frames are fast access frames. The inventor notes that when the video server issues the quick access frame, the sending policy of the video server is usually "burst", that is, how fast and how fast the video server can be sent, because the sending is the previous buffer data, not the real-time data generated by the live end in the live process. It follows that, in the fast access phase, the corresponding data receiving speed is very high, depending on the bandwidth (generally exceeding the code rate of the live video), and this feature is shown in the "receiving frame rate", corresponding to the live APP of the client. In a specific live broadcast scene, the receiving frame rate of the user in the playing process is specifically as follows:
frame info for last 10s[recvFrame：256 31 29l31 29 31 28 34 23 8]
frame info for last 10s[recvFrame：43 34 13 44 39 1 47 36 10 46]
in the fast access stage, the received frame rate is generally far beyond the actual frame rate of the video (the actual frame rate is 30, that is, in an ideal state, the sending frame rate at which the live-broadcast end sends live video frames, and the receiving frame rate and the playing frame rate at which the client receives the live video frames) and is typically more than 100, and then quickly decays to the playing frame rate 30. The above-mentioned 1 st second receiving frame rate is 256, and can be determined as a fast access frame, but from the 2 nd second, the corresponding receiving frame rate only fluctuates up and down at 30, and can be determined as normal live video frame data, that is, in this live scene, the video server sends all the fast access frames (assuming that the playing duration of the fast access frame is 6 seconds) to the client in the 1 st second, and starts the sending of the live video frames in the 2 nd second, and the client can play the fast access frames in the 1 st to 6 seconds to prevent occurrence of network jamming, and can also switch to the live video frames in any time of the 2 nd to 6 seconds to effectively reduce the playing delay. Therefore, the client can specifically determine whether the currently received video stream is a fast access frame by detecting the receiving frame rate of the currently received video stream, so as to further determine whether the fast access phase is finished.
The live video frames are generated in real time by the live terminal in the live process, and the video frames corresponding to the video streams received and played by the client terminal in real time are approximately equal in corresponding sending frame rate, receiving frame rate and playing frame rate.
Specifically, after receiving the video stream sent by the video server, the client sends the video stream to the client in advance of the live video frame, so that the client immediately plays the fast access frame in response to the video frame of the video stream being the fast access frame, and continuously detects the receiving frame rate of the currently received video stream at the same time, for example, every 1 second or 0.5 second or any other reasonable time, so as to determine whether the currently received video stream is still the fast access frame according to the receiving frame rate at each moment.
S13: and continuing playing the quick access frame in response to the received frame rate being greater than or equal to the first set frame rate.
It can be appreciated that the fast access frame and the live video frame have different characteristics corresponding to the received frame rate on the client, respectively, and the received frame rate of the fast access frame is typically greater than the received frame rate of the live video frame. Therefore, the video frame of the video stream currently received by the client can be screened by setting a first set frame rate which is greater than the receiving frame rate of the live video frame but less than or equal to the receiving frame rate of the quick access frame.
Specifically, in response to the receiving frame rate of the video stream currently received by the client being greater than or equal to the first set frame rate, determining that the video frame of the video stream currently received is a fast access frame, and continuing to play the fast access frame.
Optionally, the bandwidth of the network connection between the client and the video server is greater than or equal to the first set frame rate, so that in the process that the video server sends the video stream to the client, the upper limit of the receiving frame rate that the client can actually achieve is not less than the first set frame rate, so as to ensure that the quick access frame and the live video frame can be distinguished.
Optionally, the first set frame rate is determined by a playing frame rate corresponding to a hardware characteristic and a firmware algorithm of the client, a receiving frame rate of the fast access frame received by the client, and a network connection bandwidth between the client and the video server, and may specifically be an intermediate value of a data interval formed by the receiving frame rate and the playing frame rate, or any multiple of the playing frame rate not less than 1, and may be adjusted according to a requirement of an actual application scenario, which is not limited in the present application.
Optionally, the specific corresponding playing frame rates of different clients may also be different, where when the playing frame rate of the client is 30, the first set frame rate may be any reasonable frame rate such as 50, 60, 55, etc.; when the play frame rate of the client is 60, the first set frame rate may be any reasonable frame rate, such as 90, 100, 80, etc., which is not limited in the present application.
S14: and in response to the received frame rate being smaller than the first set frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
Specifically, when the receiving frame rate of the video stream currently received by the client is smaller than the first set frame rate, the video frame of the video stream currently received can be determined to be a live video frame immediately in response to the receiving frame rate being smaller than the first set frame rate, so that a live mode is entered to play the live video frame, that is, the video frame currently received is played in real time.
In a specific embodiment, the client starts to receive the live video frame at the 2 nd or the 3 rd second, and when the fast access frame received at the 1 st second needs 6 seconds to be played, the client still responds to the corresponding time when the receiving frame rate is smaller than the first set frame rate, and starts to play the live video frame at the 2 nd or the 3 rd second, so that the playing delay can be effectively reduced.
In a specific live scenario, referring to FIG. 1 in combination, the frame rate received by the client is shown below as [ I ] [2021-05-18+8.0 19:54:46.208] [13682,13950] [ hysdk ], [ 0] [ FastAccessChecker fast access debug recvFrameRate: [258] realframe Rate:30
[I][2021-05-18+8.0 19:54:47.232][13682,13950][hysdk][,,0][FastAccessChecker fast access debug recvFrameRate:[258,32]realFrameRate:29
[I][2021-05-18+8.0 19:54:48.253][13682,13950][hysdk][,,0][FastAccessChecker fast access debug recvFrameRate:[258,32,30]realFrameRate:30
[I][2021-05-18+8.0 19:54:49.336][13682,13950][hysdk][,,0][FastAccessChecker fast access debug recvFrameRate:[258,32,30,32]realFrameRate:29
[l][2021-05-18+8.0 19:54:49.647][13682,13950][hysdk][,,0][checkVideoFastAccess fast access end.streamld＝7329272119256983304,capStamp＝453313938,gop＝2999.duration＝11999,localDuration＝4530,frameNum＝361
According to the data, when the video server issues the super-many quick access frames, the client side can show that the receiving frame rate is too high in the live APP of the client side no matter in the A stage or the B stage, so that the video server can be obtained by the algorithm of the live APP, the normal live receiving link can not be entered in advance, the quick access stage is finished until the normal receiving frame rate in the C stage is detected, and the video server plays from the C stage, so that the small playing delay is kept.
According to the scheme, the receiving frame rate of the video stream currently received by the client is detected, so that the fast access frame can be continuously played in response to the receiving frame rate being greater than or equal to the first set frame rate, and when the receiving frame rate is smaller than the first set frame rate, the video frame of the video stream currently received is determined to be a live video frame and the live video frame is played, so that the video frame of the video stream can be timely switched from the fast access frame to the live video frame in response to the video frame of the video stream, and the live video frame can be timely played, and therefore the fast access frame can be effectively adapted to different fast access durations corresponding to different video servers, lower playing delay can be kept, and the integral end-to-end delay is greatly optimized on the premise that the playing caching strategy of the client is not adjusted and the playing clamping mode is not influenced.
Further, in an embodiment, the step S14 may specifically further include: and in response to the received frame rate being smaller than the first set frame rate and larger than the second set frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
It will be appreciated that the second set frame rate is smaller than the first set frame rate, and there is typically a risk of network stuck during the start-up phase of the live broadcast process, so that there is a risk that the current corresponding received frame rate of the client will be equal to 0, or close to 0. Therefore, the playing stage of the live video frame cannot be entered at the moment when the receiving frame rate is close to 0, that is, the live mode cannot be adopted to play the current video frame at the moment when the receiving frame rate is close to 0, and the fast access frame received before the playing still needs to be continued, so as to avoid playing the stuck frame, until the current receiving frame rate is detected to be smaller than the first set frame rate and larger than the second set frame rate, the video frame of the current received video stream is determined to be the live video frame, and the network is stable, so that the playing of the live video frame can be performed.
It will be appreciated that the duration of time that a client receives a quick access frame is typically less than the duration of time that it has completed playing the quick access frame. Therefore, when the fast access frame is not played, even if any new video stream is not received, the client can still play the fast access frame, so as to wait for the network to be stable, that is, after the current receiving frame rate is close to the playing frame rate, the client is switched to the playing stage of the live video frame.
Optionally, the second set frame rate is smaller than the play frame rate of the client, and may specifically be any reasonable value such as 10, 15 or 20, which is not limited by the present application.
Further, in an embodiment, the step S14 may specifically further include: and in response to detecting that the received frame rate is smaller than the first set frame rate at least twice continuously, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
It will be appreciated that there will typically be network instability at the start of the live broadcast process, and the duration of the client receiving the quick access frame will typically be less than the duration of the client playing the quick access frame. Therefore, in the time period when the fast access frame is played, for example, when the client is in the 1 st second, the received fast access frame which needs 6 seconds to play is played, but when the total playing time period corresponding to the fast access frame is 12 seconds, whether the current receiving frame rate is smaller than the first set frame rate or not can be continuously detected for multiple times in the 2 nd second and the 12 th second, so that when the receiving frame rate is continuously detected to be smaller than the first set frame rate at least twice, the video frame of the currently received video stream is determined to be a live video frame, and the live video frame is played, so as to avoid the situation of misjudgment caused by the problem of unstable network, for example, the situation that the fast access frame is not sent in the 2 nd second or the 3 rd second due to the network problem is prevented, but the receiving frame rate of the client is smaller than the first set frame rate, and the fast access frame is continuously received in the 4 th second, so that the situation of playing delay is caused.
Optionally, the frequency of detecting the receiving frame rate of the client may be specifically one time every 1 second, 0.5 second or 2 seconds, and the number of times of continuously detecting the receiving frame rate of the client may be any one of 2 times or 3 times, and the total detecting span duration is not more than the total playing duration of the fast access frame, and is specifically determined by an actual live broadcast scene, which is not limited in the present application.
Further, in an embodiment, the step S14 may specifically further include: and in response to detecting that the received frame rate is smaller than the first set frame rate and larger than the third set frame rate at least twice in succession, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
It can be understood that the third set frame rate is smaller than the first set frame rate and is equivalent to the second set frame rate, and the same can be obtained, so as to avoid misjudgment of whether the current video stream should enter the playing stage of the live video frame due to unstable network, when the receiving frame rate of the client is detected to be smaller than the first set frame rate and larger than the third set frame rate at least twice, the video frame of the currently received video stream is determined to be the live video frame, and the live video frame is played.
Optionally, the frequency of detecting the receiving frame rate of the client may be specifically one time every 1 second, 0.5 second or 2 seconds, and the number of times of continuously detecting the receiving frame rate of the client may be any one of 2 times or 3 times, and the total detecting span duration is not more than the total playing duration of the fast access frame, and is specifically determined by an actual live broadcast scene, which is not limited in the present application.
Optionally, the third set frame rate is smaller than the play frame rate of the client, and may specifically be any reasonable value such as 10, 15 or 20, which is not limited by the present application.
Referring to fig. 3, fig. 3 is a flowchart illustrating a video playing method according to a second embodiment of the present application. The video playing method of the present embodiment is a flowchart of a refinement embodiment of the video playing method in fig. 2, and includes the following steps:
s21: the client receives the video stream sent by the video server.
S22: and responding to the video frame of the video stream as the quick access frame, playing the quick access frame, and detecting the receiving frame rate of the current received video stream.
The S21 and S22 are the same as S11 and S12 in fig. 2, and specific reference is made to S11 and S12 and the related text descriptions thereof, which are not repeated here.
S23: and continuing to play the quick access frame in response to the received frame rate being greater than the first set multiple of the play frame rate.
It will be appreciated that the playing frame rate that different clients typically correspond to will also vary, and is determined in particular by their hardware and corresponding firmware algorithms, and that the playing frame rate is typically relatively stable for clients in a live scene, and that the frame rate at which video frames are received by a client is equal to the playing frame rate and the sending frame rate of the video server only in an ideal live state. Therefore, the current received frame rate of the client can be compared with the playing frame rate thereof to judge whether the current received video frame is a quick access frame or not.
Specifically, in response to the current received frame rate of the client being greater than a first set multiple of the play frame rate, determining that the currently received video frame is a fast access frame, and continuing to play the fast access frame.
The first setting multiple is greater than 1, and can be understood as a jitter adjustment coefficient, so as to avoid the occurrence of erroneous judgment, and can be configured and adjusted according to specific network conditions and actual scenes of the video stream sent by the video server.
Optionally, the first set multiple is 1.2-2.
S24: and in response to the received frame rate being smaller than the first set multiple of the playing frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
Specifically, when the receiving frame rate of the current received video stream of the client is smaller than the first set multiple of the playing frame rate, the video frame of the current received video stream can be determined to be a live video frame in response to the receiving frame rate being smaller than the first set multiple of the playing frame rate, so that the live video mode is entered, and playing of the live video frame is performed, that is, the current received video frame is played in real time.
Further, in an embodiment, the step S24 may specifically further include: and in response to the received frame rate being less than the first set multiple of the playing frame rate and greater than the second set multiple of the playing frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
It can be appreciated that the second set multiple is less than 1, there is typically a risk of network blocking during the start-up phase of the live broadcast process, so that the current corresponding received frame rate of the client will be at risk of being equal to 0, or close to 0. Therefore, the playing stage of the live video frame cannot be entered at the moment when the receiving frame rate is close to 0, that is, the live video frame cannot be played in the live mode at the moment when the receiving frame rate is close to 0, but the fast access frame received before the playing still needs to be continued, so as to avoid playing the stuck frame, and the video frame of the currently received video stream is determined to be the live video frame until the situation that the current receiving frame rate is smaller than the first set multiple of the playing frame rate and larger than the second set multiple of the playing frame rate is detected, and the network is stable, so that the playing of the live video frame can be performed.
Optionally, the second set multiple may be any reasonable multiple of 0.2, 0.3, or 0.5, which is not limited in the present application.
Further, in an embodiment, the step S24 may specifically further include: and in response to detecting that the received frame rate is smaller than the first set multiple of the playing frame rate at least twice continuously, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
Further, in an embodiment, the step S24 may specifically further include: and in response to detecting that the received frame rate is smaller than the first set multiple of the playing frame rate and larger than the second set multiple of the playing frame rate at least twice continuously, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
Referring to fig. 4, fig. 4 is a schematic diagram of a frame of a video playing device according to an embodiment of the application. The video playback device 31 includes: a receiving module 311, configured to receive a video stream sent by a video server; a detection module 312, configured to detect a received frame rate of a currently received video stream; the playing module 313 is configured to play the fast access frame when the video frame of the video stream is the fast access frame, and continue playing the fast access frame when the receiving frame rate is greater than or equal to the first set frame rate, and determine that the video frame of the currently received video stream is the live video frame when the receiving frame rate is less than the first set frame rate, and play the live video frame.
Wherein, the bandwidth of the network connection between the video playing device 31 and the video server is greater than or equal to the first set frame rate.
According to the scheme, the receiving frame rate of the video stream currently received by the video playing device 31 is detected, so that the fast access frame can be continuously played in response to the receiving frame rate being greater than or equal to the first set frame rate, and when the receiving frame rate is smaller than the first set frame rate, the video frame of the video stream currently received is determined to be a live video frame, and the live video frame is played, so that the video frame of the video stream can be timely switched to the live video frame in response to the fast access frame, and the live video frame can be timely played, thereby being effectively suitable for different fast access time lengths corresponding to different video servers, keeping lower playing delay, and playing delay from end to end on the premise that the playing buffer strategy of a client is not adjusted and the playing blocking mode is not influenced.
In some embodiments, the play module 313 may be specifically configured to: determining that the video frame of the currently received video stream is a live video frame and playing the live video frame when the received frame rate is smaller than a first set multiple of the playing frame rate and is larger than a second set multiple of the playing frame rate; wherein the second set multiple is less than 1.
In some embodiments, the play module 313 may be specifically configured to: when the receiving frame rate is smaller than the first set frame rate and larger than the second set frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame; wherein the second set frame rate is less than the first set frame rate.
In some embodiments, the play module 313 may be specifically configured to: and when the received frame rate is detected to be smaller than the first set frame rate at least twice continuously, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
In some embodiments, the play module 313 may be specifically configured to: when the received frame rate is detected to be smaller than the first set frame rate and larger than the third set frame rate at least twice continuously, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame; wherein the third set frame rate is less than the first set frame rate.
Referring to fig. 5, fig. 5 is a schematic diagram of a framework of an embodiment of the intelligent terminal of the present application. The intelligent terminal 41 includes a memory 411 and a processor 412 coupled to each other, where the processor 412 is configured to execute program instructions stored in the memory 411 to implement the steps of any of the video playing method embodiments described above.
In one particular implementation scenario, the intelligent terminal 41 may include, but is not limited to: any reasonable intelligent terminal such as a computer, a tablet personal computer, a smart phone and a smart watch is not limited in the application.
In particular, the processor 412 is configured to control itself and the memory 411 to implement the steps of any of the video display method embodiments described above. The processor 412 may also be referred to as a CPU (Central Processing Unit ). The processor 412 may be an integrated circuit chip having signal processing capabilities. The processor 412 may also be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a Field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. In addition, the processor 412 may be commonly implemented by an integrated circuit chip.
Referring to fig. 6, fig. 6 is a schematic diagram illustrating a frame of an embodiment of a computer readable storage medium according to the present application. The computer readable storage medium 51 stores program instructions 511 executable by a processor, the program instructions 511 for implementing the steps of any of the video playing method embodiments described above.
In the several embodiments provided in the present application, it should be understood that the disclosed method and apparatus may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of modules or units is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical, or other forms.
The elements illustrated as separate elements may or may not be physically separate, and elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over network elements. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to execute all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
Claims (9)
1. A video playing method of a live scene, the video playing method comprising:
the client receives a video stream sent by a video server;
responding to the video frame of the video stream as a quick access frame, playing the quick access frame, and detecting the receiving frame rate of the video stream currently received;
responding to the received frame rate being greater than or equal to a first set frame rate, continuing to play the quick access frame; in response to the received frame rate being less than the first set frame rate, determining that a video frame of a currently received video stream is a live video frame, and playing the live video frame; and in response to the received frame rate being less than the set frame rate, determining that a video frame of the currently received video stream is a live video frame, and playing the live video frame, including: in response to detecting that the received frame rate is smaller than the first set frame rate at least twice continuously, determining that a video frame of a currently received video stream is a live video frame, and playing the live video frame; the total detection span duration is not longer than the total play duration of the quick access frame.
2. The video playing method according to claim 1, wherein said continuing to play the quick access frame in response to the received frame rate being greater than or equal to a first set frame rate comprises:
responding to the received frame rate being larger than a first set multiple of the playing frame rate, continuing playing the quick access frame; wherein the first set multiple is greater than 1;
and in response to the received frame rate being less than the first set frame rate, determining that a video frame of a currently received video stream is a live video frame, and playing the live video frame, including:
and responding to the first set multiple of which the receiving frame rate is smaller than the playing frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame.
3. The video playing method according to claim 2, wherein the determining that the video frame of the currently received video stream is a live video frame in response to the received frame rate being less than the first set multiple of the playing frame rate, playing the live video frame, comprises:
responding to the first set multiple of the receiving frame rate smaller than the playing frame rate and the second set multiple of the playing frame rate, determining that the video frame of the currently received video stream is a live video frame, and playing the live video frame; wherein the second set multiple is less than 1.
4. The video playing method according to claim 1, wherein the determining that the video frame of the currently received video stream is a live video frame in response to the received frame rate being smaller than the set frame rate, playing the live video frame, comprises:
responding to the received frame rate being smaller than the first set frame rate and larger than the second set frame rate, determining that a video frame of a currently received video stream is a live video frame, and playing the live video frame; wherein the second set frame rate is less than the first set frame rate.
5. The video playing method according to claim 1, wherein the determining that the video frame of the currently received video stream is a live video frame in response to detecting that the received frame rate is less than the first set frame rate at least two consecutive times, playing the live video frame, comprises:
in response to detecting that the received frame rate is smaller than the first set frame rate and larger than a third set frame rate at least twice in succession, determining that a video frame of a currently received video stream is a live video frame, and playing the live video frame; wherein the third set frame rate is less than the first set frame rate.
6. The method for video playback as set forth in any one of claims 1 to 5, wherein,
the network connection bandwidth between the client and the video server is greater than or equal to the first set frame rate.
7. A video playback device, the video playback device comprising:
the receiving module is used for receiving the video stream sent by the video server;
the detection module is used for detecting the receiving frame rate of the video stream currently received; wherein the total detection span duration is not more than the total play duration of the fast access frame;
and the playing module is used for playing the quick access frame when the video frame of the video stream is a quick access frame, continuously playing the quick access frame when the receiving frame rate is larger than or equal to a first set frame rate, determining that the video frame of the currently received video stream is a live video frame when the receiving frame rate is smaller than the first set frame rate at least two times continuously, and playing the live video frame.
8. An intelligent terminal, characterized in that the intelligent terminal comprises a memory and a processor coupled to each other, the processor being configured to execute program instructions stored in the memory to implement the video playing method according to any one of claims 1-6.
9. A computer readable storage medium having stored thereon program instructions, which when executed by a processor, implement the video playback method of any one of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110745960.0A CN113596568B (en) | 2021-07-01 | 2021-07-01 | Video playing method and device, intelligent terminal and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110745960.0A CN113596568B (en) | 2021-07-01 | 2021-07-01 | Video playing method and device, intelligent terminal and computer readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113596568A CN113596568A (en) | 2021-11-02 |
| CN113596568B true CN113596568B (en) | 2023-10-17 |
Family
ID=78245516
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110745960.0A Active CN113596568B (en) | 2021-07-01 | 2021-07-01 | Video playing method and device, intelligent terminal and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113596568B (en) |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104038813A (en) * | 2014-06-20 | 2014-09-10 | 深圳市九洲电器有限公司 | Multi-screen interaction method and system |
| CN107690073A (en) * | 2016-08-05 | 2018-02-13 | 阿里巴巴集团控股有限公司 | A kind of net cast method and Living streaming server |
| CN108769727A (en) * | 2018-06-15 | 2018-11-06 | 北京奇艺世纪科技有限公司 | A kind of live video preloading method and device |
| CN109561318A (en) * | 2017-09-26 | 2019-04-02 | 阿里巴巴集团控股有限公司 | A kind of method and apparatus of video playing |
| CN109618179A (en) * | 2019-01-21 | 2019-04-12 | 北京数码视讯软件技术发展有限公司 | Ultra high-definition net cast quickly plays broadcasting method and device |
| CN110401845A (en) * | 2019-08-22 | 2019-11-01 | 北京视界云天科技有限公司 | First screen playing method, device, computer equipment and storage medium |
| CN111083514A (en) * | 2019-12-26 | 2020-04-28 | 北京达佳互联信息技术有限公司 | Live broadcast method and device, electronic equipment and storage medium |
| CN111654711A (en) * | 2020-06-17 | 2020-09-11 | 三星电子（中国）研发中心 | Video playing control method, video playing method and device |
| CN112533067A (en) * | 2020-11-12 | 2021-03-19 | 烽火通信科技股份有限公司 | Method and device for quickly starting up super-high-definition video on demand |
| CN112822503A (en) * | 2020-12-30 | 2021-05-18 | 腾讯科技（深圳）有限公司 | Method, device and equipment for playing live video stream and storage medium |
| CN115243063A (en) * | 2022-07-13 | 2022-10-25 | 广州博冠信息科技有限公司 | Video stream processing method, processing device and processing system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10638192B2 (en) * | 2017-06-19 | 2020-04-28 | Wangsu Science & Technology Co., Ltd. | Live streaming quick start method and system |
-
2021
- 2021-07-01 CN CN202110745960.0A patent/CN113596568B/en active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104038813A (en) * | 2014-06-20 | 2014-09-10 | 深圳市九洲电器有限公司 | Multi-screen interaction method and system |
| CN107690073A (en) * | 2016-08-05 | 2018-02-13 | 阿里巴巴集团控股有限公司 | A kind of net cast method and Living streaming server |
| CN109561318A (en) * | 2017-09-26 | 2019-04-02 | 阿里巴巴集团控股有限公司 | A kind of method and apparatus of video playing |
| CN108769727A (en) * | 2018-06-15 | 2018-11-06 | 北京奇艺世纪科技有限公司 | A kind of live video preloading method and device |
| CN109618179A (en) * | 2019-01-21 | 2019-04-12 | 北京数码视讯软件技术发展有限公司 | Ultra high-definition net cast quickly plays broadcasting method and device |
| CN110401845A (en) * | 2019-08-22 | 2019-11-01 | 北京视界云天科技有限公司 | First screen playing method, device, computer equipment and storage medium |
| CN111083514A (en) * | 2019-12-26 | 2020-04-28 | 北京达佳互联信息技术有限公司 | Live broadcast method and device, electronic equipment and storage medium |
| CN111654711A (en) * | 2020-06-17 | 2020-09-11 | 三星电子（中国）研发中心 | Video playing control method, video playing method and device |
| CN112533067A (en) * | 2020-11-12 | 2021-03-19 | 烽火通信科技股份有限公司 | Method and device for quickly starting up super-high-definition video on demand |
| CN112822503A (en) * | 2020-12-30 | 2021-05-18 | 腾讯科技（深圳）有限公司 | Method, device and equipment for playing live video stream and storage medium |
| CN115243063A (en) * | 2022-07-13 | 2022-10-25 | 广州博冠信息科技有限公司 | Video stream processing method, processing device and processing system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113596568A (en) | 2021-11-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10097878B2 (en) | Video playback method and control terminal thereof | |
| US9729600B2 (en) | Switching media streams in a client system based on environmental changes | |
| KR101687640B1 (en) | Method for synchronized content playback | |
| US8861372B2 (en) | Method and device for fast pushing unicast stream in fast channel change | |
| US10638180B1 (en) | Media timeline management | |
| WO2002093808A2 (en) | Method and system for transmitting multicast data signals | |
| CN108259964B (en) | Video playing rate adjusting method and system | |
| US11863841B2 (en) | Video playing control method and system | |
| EP3520421B1 (en) | Viewer importance adaptive bit rate delivery | |
| JP2012514362A (en) | Multimedia stream access delivery changes supported by the service layer | |
| CN106604064A (en) | Rapid broadcasting method and device | |
| CN107295364B (en) | For the real-time streaming transport control method of barrage video, control device | |
| CN114666614A (en) | Media stream sending method, device and equipment | |
| JP5140952B2 (en) | Content distribution system, content distribution server, content reproduction terminal, program, and content distribution method | |
| US20210227264A1 (en) | Minimizing stall duration tail probability in over-the-top streaming systems | |
| CN106791994A (en) | A kind of low delay quickly starts broadcasting method and device | |
| US11350144B2 (en) | Consolidating content streams to conserve bandwidth | |
| CN113596568B (en) | Video playing method and device, intelligent terminal and computer readable storage medium | |
| WO2009053595A1 (en) | Device for the continuous reception of audio and/or video data packets | |
| Cranley et al. | Dynamic content-based adaptation of streamed multimedia | |
| CN113645491A (en) | Method for realizing real-time synchronous playing of multiple live broadcast playing ends | |
| CN115002544A (en) | Video playing method and device, nonvolatile storage medium and electronic equipment | |
| FR2905221A1 (en) | Multimedia content i.e. video, transmitting method for e.g. microcomputer, involves determining encoding rate higher than another encoding rate, where encoding part of content is based on former rate and transmission rate of encoded part |
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 |