CN104967884A - Code stream switching method and code stream switching device - Google Patents
Code stream switching method and code stream switching device Download PDFInfo
- Publication number
- CN104967884A CN104967884A CN201510185473.8A CN201510185473A CN104967884A CN 104967884 A CN104967884 A CN 104967884A CN 201510185473 A CN201510185473 A CN 201510185473A CN 104967884 A CN104967884 A CN 104967884A
- Authority
- CN
- China
- Prior art keywords
- code stream
- time
- switching
- playing
- target video
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 59
- 238000009877 rendering Methods 0.000 claims description 21
- 239000012634 fragment Substances 0.000 claims description 19
- 238000004364 calculation method Methods 0.000 claims description 16
- 230000001174 ascending effect Effects 0.000 claims description 12
- 238000009826 distribution Methods 0.000 description 25
- 230000008569 process Effects 0.000 description 18
- 238000010586 diagram Methods 0.000 description 16
- 238000005516 engineering process Methods 0.000 description 12
- 230000003044 adaptive effect Effects 0.000 description 11
- 230000005540 biological transmission Effects 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 230000003247 decreasing effect Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 239000011159 matrix material Substances 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 208000003028 Stuttering Diseases 0.000 description 3
- 230000009471 action Effects 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 3
- 230000003139 buffering effect Effects 0.000 description 3
- 230000008447 perception Effects 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 241000287196 Asthenes Species 0.000 description 1
- BQCADISMDOOEFD-UHFFFAOYSA-N Silver Chemical compound [Ag] BQCADISMDOOEFD-UHFFFAOYSA-N 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 238000009825 accumulation Methods 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000036316 preload Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000003908 quality control method Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 229910052709 silver Inorganic materials 0.000 description 1
- 239000004332 silver Substances 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 230000003827 upregulation 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/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
-
- 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
- H04N21/47217—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for controlling playback functions for recorded or on-demand content, e.g. using progress bars, mode or play-point indicators or bookmarks
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Human Computer Interaction (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
The embodiment of the present invention provides a code stream switching method and a code stream switching device, wherein the method comprises the steps of obtaining a key parameter when the previous video is played, and a target video is played continuously, or when a player is started for the first time to play the target video; based on the key parameter, deciding an actual optimal code stream; when the actual optimal code stream is different from the current playing code stream, calculating a switching opportunity; and when the switching opportunity arrives, switching the current playing code stream of the target video into the actual optimal code stream. According to the present invention, the seamless and smooth switching of the two code streams can be guaranteed, and the user watch experience is improved.
Description
Technical Field
The present invention relates to the field of video playing technologies, and in particular, to a code stream switching method and a code stream switching apparatus.
Background
Streaming media (Streaming media) technology refers to a technology and a process for compressing a series of multimedia data and then continuously transmitting the multimedia data in a Streaming manner in real time for viewing. Compared with the traditional multimedia file downloading and playing mode, the streaming media has the greatest advantage that the user can play the data only by downloading the initial part of the data to the local buffer area, and the data can be downloaded while playing, so that the continuous playing is realized. The streaming transmission mode not only greatly shortens the starting time delay of program playing, but also greatly reduces the requirement on the local cache space of the user.
However, since the internet provides a best effort service, it is not possible to provide QoS (Quality of service) guarantee, and in the process of streaming media playing, there are often bad situations such as playing card pause, video Quality shaking, etc., and users cannot obtain better viewing experience. In order to overcome the influence caused by uncertain network conditions, the streaming media system needs to adaptively adjust the transmission strategy to make the streaming media data transmission process adapt to the changing network environment, so that the user can obtain the best streaming media experience under the current network conditions.
Currently, the mainstream adaptive streaming media transmission technology is divided into two types, namely server-side implementation and client-side implementation. In the adaptive streaming media transmission implemented by the server, the most widely used system is mostly based on an RTP (real time transport protocol) and an RTSP (real time streaming protocol), and the system first obtains streaming media information and related parameters through HTTP, then runs the RTSP to establish communication between the client and the streaming media server, and finally transmits multimedia data through the RTP. Such streaming Media systems are most typical of the Real systems of Real Networks, usa, and Windows Media of microsoft. However, the server side needs more information for realizing the self-adaptive transmission, and the realization of the system is mostly based on a complex private protocol, which restricts the development of the streaming media technology to a certain extent.
The client side can detect the network condition before requesting to download the fragments from the server, and timely requests the most appropriate streaming media fragments from the server according to the current network condition and the cache condition, and the downloading of each fragment is completed through H TT P request-response. In the implementation mode, the interactive information between the client and the server is less, the system is simple to implement, a special streaming media server does not need to be erected, and in addition, compared with RTP/RTSP, HTTP is easy to implement and maintain and has more advantages in the aspect of traversing firewall/NAT.
Currently, adaptive Streaming media technology based on HTTP has become a development trend of Streaming media technology, and there are many HTTP adaptive Streaming media systems, wherein the mainstream systems include Apple HTTP live Streaming, microsoft silver light smooth Streaming, and Adobe HTTP dynamic Streaming. Some international standards organizations have also developed standardization work for HTTP-based adaptive Streaming technologies, and the influential standards are HAS of OIPF, DASH of MPEG, HTTP Live Streaming draft of IETF, and the like. With the gradual realization of the standardization work of technologies such as DASH and the like, in recent years, the academic community has more relevant researches on the technologies, and the practical performance and the optimization method of the technology application are more concerned than the standardization organization pays attention to the format definition related in the technology process. Christopher Muller et al analyzed the performance of IIS Smooth Streaming, Live HTTPstreaming and Dynamic Streaming clients in a real network scene, and discovered that the adaptive strategy of Dynamic Streaming is the most aggressive by observing the requested media fragment bit rate and the buffer state of different clients, the media fragment bit rate changes most violently, the buffer underflow times are the most, the calorie-to-pause ratio is high, IIS Smooth Streaming is the second, and Live HTTP Streaming is relatively stable in performance. However, these technical solutions are all applied to a specific platform, for example, Live HTTP streaming is mainly used in an apple ios system, and is mainly calculated based on two aspects of a network fluctuation condition and a play buffer, and conditions for deciding an optimal code stream are relatively single, and cannot completely reflect the play behavior of an actual player.
Disclosure of Invention
The technical problem to be solved by the embodiments of the present invention is to provide a code stream switching method, so as to ensure seamless and smooth switching between two code streams and improve the viewing experience of a user.
Correspondingly, the embodiment of the invention also provides a code stream switching device, which is used for ensuring the realization and the application of the method.
In order to solve the above problems, the present invention discloses a code stream switching method, which comprises:
when the last video is played and the target video is played continuously, or when the player is started for the first time to start playing the target video, key parameters are obtained;
deciding an actual optimal code stream based on the key parameters;
when the actual optimal code stream is different from the current playing code stream, calculating the switching time;
and when the switching time is up, switching the current playing code stream of the target video into the actual optimal code stream.
Preferably, the step of deciding an actual optimal code stream based on the key parameter includes:
selecting a plurality of key parameters from the key parameters as a plurality of decision factors;
and deciding the actual optimal code stream based on the decision factor.
Preferably, the key parameters include at least:
(1) a code stream type list supported by the target video, wherein the code stream type list comprises various types of code streams;
(2) current player rendering region size;
(3) theoretically optimizing the code stream;
(4) the residual playing time of the downloaded video data in the current playing buffer area;
(5) in the latest first preset time period, performing curve fitting on the residual playing time of the downloaded video data in the playing buffer zone corresponding to each unit time to obtain a fitting curve;
(6) judging the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream according to a preset code stream judgment standard;
(7) stopping the preset time, and judging the current playing code stream as switchable times;
(8) presetting a limit range of a highest code stream and a lowest code stream;
(9) the pause times of the target video playing;
(10) dragging seek record of a target video dragged to a certain position by a user;
(11) the total switching times of the current target video;
(12) and recording the used code stream of the target video film.
Preferably, the multiple types of code streams include code stream grades, and the step of deciding an actual optimal code stream based on the decision factor includes:
setting N decision conditions based on the decision factor, wherein N is a positive integer;
if the decision conditions all meet corresponding threshold value standards, taking the theoretical optimal code stream as the actual optimal code stream;
and if any decision condition does not meet the corresponding threshold value standard, taking the code stream of the next level corresponding to the theoretical optimal code stream as the actual optimal code stream, or taking the currently played code stream as the actual optimal code stream.
Preferably, the decision condition includes part or all of the following conditions:
1) judging whether the remaining playing time of the downloaded video data in the current playing buffer area is greater than a first threshold value, if so, judging that the decision condition meets the threshold value standard, and if not, judging that the decision condition does not meet the threshold value standard;
2) judging whether the fitting curve is in an ascending trend or a descending trend; if the trend is an ascending trend, the decision condition is judged to meet the threshold standard, and if the trend is a descending trend, the decision condition is judged to not meet the threshold standard;
3) adjusting the threshold standard of each decision condition according to the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream;
4) judging whether the currently played code stream is judged to be switchable times larger than a second threshold value, if so, judging that the decision condition meets a threshold value standard, and if not, continuing to accumulate the switchable times or returning the currently accumulated switchable times to zero;
5) judging whether the theoretical optimal code stream is within the preset limit ranges of the highest code stream and the lowest code stream, if so, judging that the decision condition meets the threshold standard, and if not, judging that the decision condition does not meet the threshold standard;
6) selecting a code stream with a size suitable for the rendering area of the current player;
7) if the number of times of the pause is larger than a third threshold, adjusting the threshold standard of each decision condition;
8) if the dragged seek record is larger than a fourth threshold, adjusting the threshold standard of each decision condition;
9) judging whether the total switching times of the target video is greater than a fifth threshold, if so, judging that the decision condition does not meet the threshold standard, and if not, judging that the decision condition meets the threshold standard;
10) and according to the used code stream records, if the existing time of a certain code stream is lower than a sixth threshold value, not selecting the code stream as an actual optimal code stream.
Preferably, the theoretical optimal code stream is obtained as follows:
respectively calculating the quality values of the various types of code streams;
and taking the code stream with the maximum quality value as a theoretical optimal code stream.
Preferably, the following formula is adopted to respectively calculate the quality values of the multiple types of code streams:
G[i]=Q[i]-p0[i]*cost[i]-costs*(i-current_bitstream_index);
wherein i represents the type identification of the code stream, G [ i ] represents the quality value of the code stream, Q [ i ] represents the preset initial quality value corresponding to various types of code streams, and cost [ i ] represents the preset first quality loss value caused by the pause of various code streams during playing; costs represents a preset second quality loss value caused by switching of two code streams; current _ bitstream _ index represents a preset index value of a currently played code stream; p0[ i ] represents the probability that the player buffer is empty.
Preferably, the target video comprises a plurality of logical tiles; said p0[ i ] is obtained as follows:
respectively estimating the downloading time required by downloading a logic fragment by the various types of code streams based on the current network downloading speed, and defining the downloading time required by downloading w logic allocations as t;
respectively calculating expected E (t) corresponding to the downloading time t;
p0[ i ] is calculated using the following formula:
p0[i]=1-1/E(t)[i]*μ;
wherein E (t) i represents the expectation of the code stream i; μ denotes a preset expectation of the decoding time required for the decoder to decode one logical slice.
Preferably, when the actual optimal code stream is different from the currently played code stream, the step of calculating the switching time includes:
setting pre-loading minimum buffer time corresponding to various code streams;
when the actual optimal code stream is different from the current playing code stream, calculating the switching time by adopting the following formula:
time=(bs_rate_[result]*5000)/average_download_speed_+bs_min_buffer_time_[result]);
wherein bs _ rate _ [ result ] represents the code rate of the actual optimal code stream, average _ download _ speed _ is the current average network download speed, and bs _ min _ buffer _ time _ [ result ] represents the preloading minimum buffer time of the actual optimal code stream.
Preferably, the step of switching the currently played code stream of the target video to the actual optimal code stream when the switching time arrives includes:
calculating the optimal key frame position within the preset range of the switching opportunity;
subtracting the preloading minimum buffer time of the actual optimal code stream from the optimal key frame position to obtain a preloading position;
when the target video is played to the preloading position, stopping loading the currently played code stream, and starting loading the actual optimal code stream;
and when the target video is played to the optimal key frame position, sending the key frame with the same position as the optimal key frame in the actual optimal code stream to a decoder.
The invention also discloses a code stream switching device, which comprises:
the key parameter acquisition module is used for acquiring key parameters when the last video is played and the target video is played continuously or when the player is started for the first time to start playing the target video;
the decision module is used for deciding an actual optimal code stream based on the key parameters;
the switching time calculation module is used for calculating the switching time when the actual optimal code stream is different from the current playing code stream;
and the switching module is used for switching the currently played code stream of the target video into the actual optimal code stream when the switching time arrives.
Preferably, the decision module comprises:
the parameter selection submodule is used for selecting a plurality of key parameters from the key parameters to serve as a plurality of decision factors;
and the decision submodule is used for deciding the actual optimal code stream based on the decision factor.
Preferably, the key parameters include at least:
(1) a code stream type list supported by the target video, wherein the code stream type list comprises various types of code streams;
(2) current player rendering region size;
(3) theoretically optimizing the code stream;
(4) the residual playing time of the downloaded video data in the current playing buffer area;
(5) in the latest first preset time period, performing curve fitting on the residual playing time of the downloaded video data in the playing buffer zone corresponding to each unit time to obtain a fitting curve;
(6) judging the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream according to a preset code stream judgment standard;
(7) stopping the preset time, and judging the current playing code stream as switchable times;
(8) presetting a limit range of a highest code stream and a lowest code stream;
(9) the pause times of the target video playing;
(10) dragging seek record of a target video dragged to a certain position by a user;
(11) the total switching times of the current target video;
(12) and recording the used code stream of the target video film.
Preferably, the multiple types of code streams include code stream levels, and the decision sub-module is further configured to:
setting N decision conditions based on the decision factor, wherein N is a positive integer;
if the decision conditions all meet corresponding threshold value standards, taking the theoretical optimal code stream as the actual optimal code stream;
and if any decision condition does not meet the corresponding threshold value standard, taking the code stream of the next level corresponding to the theoretical optimal code stream as the actual optimal code stream, or taking the currently played code stream as the actual optimal code stream.
Preferably, the decision condition includes part or all of the following conditions:
1) judging whether the remaining playing time of the downloaded video data in the current playing buffer area is greater than a first threshold value, if so, judging that the decision condition meets the threshold value standard, and if not, judging that the decision condition does not meet the threshold value standard;
2) judging whether the fitting curve is in an ascending trend or a descending trend; if the trend is an ascending trend, the decision condition is judged to meet the threshold standard, and if the trend is a descending trend, the decision condition is judged to not meet the threshold standard;
3) adjusting the threshold standard of each decision condition according to the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream;
4) judging whether the currently played code stream is judged to be switchable times larger than a second threshold value, if so, judging that the decision condition meets a threshold value standard, and if not, continuing to accumulate the switchable times or returning the currently accumulated switchable times to zero;
5) judging whether the theoretical optimal code stream is within the preset limit ranges of the highest code stream and the lowest code stream, if so, judging that the decision condition meets the threshold standard, and if not, judging that the decision condition does not meet the threshold standard;
6) selecting a code stream with a size suitable for the rendering area of the current player;
7) if the number of times of the pause is larger than a third threshold, adjusting the threshold standard of each decision condition;
8) if the dragged seek record is larger than a fourth threshold, adjusting the threshold standard of each decision condition;
9) judging whether the total switching times of the target video is greater than a fifth threshold, if so, judging that the decision condition does not meet the threshold standard, and if not, judging that the decision condition meets the threshold standard;
10) and according to the used code stream records, if the existing time of a certain code stream is lower than a sixth threshold value, not selecting the code stream as an actual optimal code stream.
16. The apparatus of claim 13, 14 or 15, wherein the key parameter obtaining module is further configured to:
respectively calculating the quality values of the various types of code streams;
and taking the code stream with the maximum quality value as a theoretical optimal code stream.
Preferably, the following formula is adopted to respectively calculate the quality values of the multiple types of code streams:
G[i]=Q[i]-p0[i]*cost[i]-costs*(i-current_bitstream_index);
wherein i represents the type identification of the code stream, G [ i ] represents the quality value of the code stream, Q [ i ] represents the preset initial quality value corresponding to various types of code streams, and cost [ i ] represents the preset first quality loss value caused by the pause of various code streams during playing; costs represents a preset second quality loss value caused by switching of two code streams; current _ bitstream _ index represents a preset index value of a currently played code stream; p0[ i ] represents the probability that the player buffer is empty.
Preferably, the target video comprises a plurality of logical tiles; said p0[ i ] is obtained as follows:
respectively estimating the downloading time required by downloading a logic fragment by the various types of code streams based on the current network downloading speed, and defining the downloading time required by downloading w logic allocations as t;
respectively calculating expected E (t) corresponding to the downloading time t;
p0[ i ] is calculated using the following formula:
p0[i]=1-1/E(t)[i]*μ;
wherein E (t) i represents the expectation of the code stream i; μ denotes a preset expectation of the decoding time required for the decoder to decode one logical slice.
Preferably, the switching opportunity calculating module includes:
the buffer time setting submodule is used for setting the pre-loaded minimum buffer time corresponding to various code streams;
the calculation submodule is used for calculating the switching time by adopting the following formula when the actual optimal code stream is different from the current playing code stream:
time=(bs_rate_[result]*5000)/average_download_speed_+bs_min_buffer_time_[result]);
wherein bs _ rate _ [ result ] represents the code rate of the actual optimal code stream, average _ download _ speed _ is the current average network download speed, and bs _ min _ buffer _ time _ [ result ] represents the preloading minimum buffer time of the actual optimal code stream.
Preferably, the switching module includes:
the position calculation submodule is used for calculating the optimal key frame position within the preset range of the switching opportunity;
the preloading position calculation submodule is used for subtracting the preloading minimum buffer time of the actual optimal code stream from the optimal key frame position to obtain a preloading position;
the preloading submodule is used for stopping loading the currently played code stream and starting loading the actual optimal code stream when the target video is played to the preloading position;
and the switching submodule is used for sending the key frame with the same position as the optimal key frame in the actual optimal code stream to a decoder when the target video is played to the optimal key frame position.
Compared with the prior art, the embodiment of the invention has the following advantages:
the embodiment of the invention decides the actual optimal code stream according to the key parameters, calculates the reasonable switching time, and switches the code stream when the switching time is reached, thereby enriching the decision conditions of the code stream and improving the decision accuracy of the code stream;
in addition, the embodiment of the invention calculates the actual switching, can ensure seamless and smooth switching of two code streams, and improves the watching experience of users;
in addition, the invention has no specific platform depending on the HTTP self-adaptive streaming media system;
in addition, the invention comprehensively considers various key parameters and various decision conditions to decide the actual optimal code stream, so that the invention can give consideration to the video definition and obviously reduce the player pause ratio.
Drawings
FIG. 1 is a flow chart illustrating the steps of an embodiment of a method for switching code streams according to the present invention;
FIG. 2 is a phase flow diagram of an Ek/M/1 queuing system in an embodiment of a code stream switching method of the present invention;
fig. 3 is a schematic diagram illustrating drastic changes in the download speed of different code streams in an embodiment of a code stream switching method according to the present invention under the same network condition;
FIG. 4 is a diagram illustrating distribution results of various checkpoints under various code streams in an embodiment of a code stream switching method according to the present invention;
FIG. 5 is a schematic diagram illustrating the effect of the Caton ratio in an embodiment of a code stream switching method according to the present invention;
fig. 6 is a block diagram of a code stream switching apparatus according to an embodiment of the present invention.
Detailed Description
In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in further detail below.
Referring to fig. 1, a flowchart illustrating steps of an embodiment of a code stream switching method according to the present invention is shown, which may specifically include the following steps:
step 101, when the previous video is played and the target video is played continuously, or when the player is started for the first time to start playing the target video, key parameters are obtained;
the embodiment of the invention is started by the play triggering operation of the target video, and the play triggering operation of the target video can comprise the following steps: and after the last video is played, continuously playing the target video, or playing the target video when the user starts the player for the first time. The trigger operation may be an operation in which the user clicks on the target video to issue an http request for the target video.
The player of the embodiment of the invention periodically detects the play trigger operation of the target video, wherein the periodicity can be detected once every 10 seconds, once every 20 seconds, and the like.
It should be noted that the video of the embodiment of the present invention may include a movie film.
And when the target video is triggered by the playing triggering operation, the player starts to load the default code stream corresponding to the target video, starts to decode the default code stream and plays the default code stream. In the process, the player may obtain a key parameter of the target video, and dynamically adjust the code stream in a self-adaptive manner according to the key parameter, where the key parameter may be a parameter that can be obtained by the player (client) and is related to the target video.
As an example, the key parameters may include at least the following parameters:
(1) a code stream type list supported by the target video, wherein the code stream type list comprises various types of code streams;
(2) current player rendering region size;
(3) theoretically optimizing the code stream;
(4) the residual playing time of the downloaded video data in the current playing buffer area;
(5) in the latest first preset time period, performing curve fitting on the residual playing time of the downloaded video data in the playing buffer zone corresponding to each unit time to obtain a fitting curve;
(6) judging the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream according to a preset code stream judgment standard;
(7) stopping the preset time, and judging the current playing code stream as switchable times;
(8) presetting a limit range of a highest code stream and a lowest code stream;
(9) the pause times of the target video playing;
(10) dragging seek record of a target video dragged to a certain position by a user;
(11) the total switching times of the current target video;
(12) and recording the used code stream of the target video film.
The key parameters are explained below.
For the above key parameter (1), in an embodiment, the obtaining process of the code stream list may be: and the player sends a code stream acquisition request to the video server to acquire a code stream list which can be supported by the target video from the video server. Specifically, multiple resolution versions of the same video may exist in the video server, for example, the same movie, and various resolution versions such as BS _150 (extremely fast, resolution up to 320 × 640), BS _ standard (standard definition, resolution 720 × 576(PAL format) or 720 × 486(NTSC format)), BS _ High (High definition, resolution 1280 × 720 and 1920 × 1080), BS _720p (resolution up to 1280 × 720), BS _1080p (resolution up to 1920 × 1080), BS _4K (ultra High definition, resolution up to 4096 × 2160), and the like are stored in the video server. And when the video server receives the request of the player, returning the stored code stream list of the target video to the player. The code stream refers to the data flow used by the video file in unit time, and is the most important part in picture quality control in video coding, and under the same resolution, the larger the code stream of the video file is, the smaller the compression ratio is, and the better the picture quality is.
In the video server, the higher the resolution level of the same video is, the higher the picture quality is, and under the condition that the network condition allows, the higher the level of the code stream supported by the target video is, the better the video definition is, and the smoothness is ensured.
And the player receives the code stream list to obtain the actual code stream of each resolution supported by the target video, and the nonexistent code stream uses the reference code stream of the corresponding resolution. The code stream (Data Rate) is the Data flow Rate used by the video file in a unit time, also called the code Rate, and is generally used in kbps, i.e., kilobits per second. The embodiment of the invention can use symbols such as BS _150 (super speed), BS _ Standerd (standard definition), BS _ High (High definition), BS _720p, BS _1080p, BS _4K and the like to represent code streams corresponding to all resolutions.
For the key parameter (2), the player can also obtain the size of the rendering window of the target video, automatically update the corresponding size of the rendering window when the playing window is changed, and record the maximum size of the rendering window. For example, when a movie is played by a player, the movie may be played in full screen, the corresponding rendering window size may be 1920 × 1080, the rendering size may be reduced to 800 × 600, the rendering window size may be increased to 1024 × 768 after a while, and so on, and these operations on the playing window are recorded by the player, and 1920 × 1080 of the user since the player was opened is recorded as the maximum rendering window size.
For the key parameter (3), the theoretical optimal code stream is the optimal code stream under the ideal condition, and is selected from various types of code streams.
The acquisition process of the theoretical optimal code stream depends on an Ek/M/1 queuing model. The Ek/M/1 queuing model is described below. The method is applied to the embodiment of the invention, and can adopt an Ek/M/1 queuing model to carry out mathematical modeling on the process that a player downloads the coded data from a server to a playing buffer area, and a decoder decodes the data in the buffer area and provides the decoded data for a renderer to carry out rendering display, and further obtain the theoretical optimal code stream in an ideal state by calculating the target parameter of the queuing model according to the steady-state equation set of the Ek/M/1 queuing model. The establishment of the Ek/M/1 queuing model will be described first.
The establishment of the Ek/M/1 queuing model needs to be applied to a variety of mathematical theoretical knowledge, such as queuing theory, event streams, Poisson (Poisson) streams, negative exponential distributions, irish distributions, and the like. Various mathematical theoretical knowledge is first explained:
queuing theory (queuing theory): or called random service system theory, is that statistical rules of the quantity indexes (waiting time, queuing length, busy period length and the like) are obtained through statistical research on the arrival and service time of service objects, and then the structure of the service system is improved or the served objects are reorganized according to the rules, so that the service system can meet the requirements of the service objects and ensure that the cost of the organization is most economic or certain indexes are optimal. The queuing theory can be applied to the scenes such as shopping in shopping malls, borrowing from libraries, filling from automobiles to gas stations, docking ships, registering for hospital and seeing a doctor, repairing machines with repair, transmitting video and audio signals, storing related data to a computer, transferring telephone calls of telephone offices and the like.
Event stream: the sequence that the homogeneous events randomly come to the service window (batch) and require service is called event flow, such as call flow of telephone exchange, computer fault flow, inbound automobile, etc.; these events are all random variables, and the time between the arrival of the customer at the system and the service time are both non-negative, so they are also non-negative random variables.
Poisson (Poisson) flow: the simplest event stream has the following characteristics: A. and (4) smoothness. In any time interval with the length of t, the probability of any number of events is only related to t and is not related to the position of t; B. without the aftereffects (also called memoryless or markov), the number of events occurring in the two non-disjointed time intervals T1 and T2 are independent of each other; C. and (4) universality. At the same instant, the probability of more than one event occurring is negligible.
Negative exponential distribution: when the customer flow is a poisson flow, T represents the time interval between two successive customers arriving at the system, and T follows a negative exponential distribution.
Ireland distribution: considering the simplest event stream, the sequence of the time intervals of the arrival of each event in the system is recorded as T1, T2 and …, and the sequences are random variables with the same negative exponential distribution, so that the event stream is an Ireland random stream, and the sequence is recorded asThen T follows an irish distribution of order k.
Ek/M/1 queuing model: the model is also called Ek/M/1/∞/∞ model, which means that the time interval between the customers arriving at the system in succession obeys negative exponential distribution, the service time also obeys negative exponential distribution, the system is provided with 1 service window, and the system capacity is infinite (enough to be) waiting queuing model.
The establishment process of the Ek/M/1 queuing model is described as follows:
the target video of the embodiment of the invention comprises a plurality of logical fragments, wherein the logical fragments are logical fragments which are not actually existed but are logical fragments for the current target video by data per unit time. For example, a 100MB movie has a total playing time of 1000 seconds, and if logical slices are performed in units of 1 second, the size of each logical slice is 100 MB/1000-0.1 MB.
Each logic fragment is a customer of the queuing system; the player continuously downloads the video data of the target video to the buffer area, namely the client arrival event stream in the queuing system; the decoder decodes according to the video data code rate, namely the service desk in the queuing system; one player only has one decoder to decode frame by frame, namely, the player is the service event stream in the queuing system; the buffer area stores the video data to be decoded downloaded from the network, namely a customer queue queued for service in the queuing system.
Under the general network condition, the transmission time of a logic fragment can fluctuate randomly by taking a certain mean value as a center, the video data transmission has certain correlation and no memory is not obvious, the Ireland distribution can better fit the real data and is more suitable for the conditions of a plurality of serial processes or no memory is not obvious, so that the Ireland distribution (Ek) is adopted to simulate the downloading time flow of the logic fragment. The video scene change in the target video is frequent and slow, the object movement is violent and weak, and the like, which determine that the code rate of video compression coded data changes randomly every second when the video compression coded data are decoded, the video compression coded data are basically Poisson streams, the decoding time of the coded data with the same size can be simulated by adopting negative exponential distribution (M), one player only has one decoder, namely only one service desk, under the normal condition, a user completely watches the target video, the loaded data cannot be lost, namely the user cannot leave, the player is an infinite waiting system, and meanwhile, the video server can be regarded as infinite in slice source, namely infinite customers, namely infinite customer source.
The arrival time of a customer in the Ireland distribution is regarded as the sum of k mutually independent time periods in the negative exponential distribution, each time period in the negative exponential distribution is regarded as a 'phase', and the time required by the next customer to pass through one phase is in the negative exponential distribution and has no memory property as can be known from the definition of the Ireland distribution.
If there are n customers in the system, the possible phases of the (n + 1) th customer before entering the system are t1, t2, …, tk; therefore, the smooth distribution of the number of customers in the system is:
the corresponding Ek/M/1 queuing system phase flow diagram is shown in FIG. 2. From the phase flow diagram of fig. 2, the Kolmogorv-Chapman (K-C) equation can be written under equilibrium conditions:
wherein, <math>
<mrow>
<mi>P</mi>
<mrow>
<mo>(</mo>
<mi>s</mi>
<mo>)</mo>
</mrow>
<mo>=</mo>
<munderover>
<mi>Σ</mi>
<mrow>
<mi>j</mi>
<mo>=</mo>
<mn>0</mn>
</mrow>
<mo>∞</mo>
</munderover>
<msub>
<mi>p</mi>
<mi>j</mi>
</msub>
<msup>
<mi>s</mi>
<mi>j</mi>
</msup>
</mrow>
</math>
let ρ ═ λ/μ, in combination with the K — C equation, there can be:
from algebraic knowledge, when ρ <1, the denominator of p(s) has one of s1 ═ 0 and the other s0, satisfying | s0| >1, and the remaining k-1 roots must be in the unit circle. When | s | < ═ 1, p(s) converges, so the denominator of p(s) is rooted on the core unit circle within the unit circle. On the unit circle, there is only one root s equal to 1, so that there is:
thus, there are:
since P (1) ═ 1, s ≈ 1 results inSubstituting the formula to obtain:
and since s0 is a root of the P(s) denominator, namely:
thus:
a smooth distribution of phases can be obtained:
a smooth distribution of the number of customers in the system is thus obtained:
from this, the corresponding target variable can be determined:
a. average captain of system:
b. customer stay in the system
Based on the above-established Ek/M/1 queuing model, in a preferred embodiment of the present invention, the theoretically optimal code stream can be obtained as follows:
substep S11, respectively calculating quality values of the multiple types of code streams;
in particular, the quality value of the codestream may be the ultimate perceived quality of the codestream. In one embodiment, the following formula may be used to calculate the quality values of the multiple types of code streams respectively:
G[i]=Q[i]-p0[i]*cost[i]-costs*(i-current_bitstream_index);
wherein i represents the type identifier of the code stream, and Q [ i ], cost [ i ], costs and current _ bitstream _ index are preset values and are empirical values; g [ i ] represents the quality value of the code stream, Q [ i ] represents the preset initial quality value corresponding to various types of code streams, namely the initial user perception; cost [ i ] represents a preset first quality loss value caused by the pause of various code streams during playing, namely a user perception loss value caused by the pause of the code streams; costs represents a preset second quality loss value caused by switching of the two code streams, namely a user perception loss value caused by switching of the two code streams, and the loss is larger when the span of the two code streams is larger; current _ bitstream _ index represents a preset index value of a currently played code stream, and is an index value set during encoding, for example, an index value corresponding to BS _150 is 1, an index value corresponding to BS _ standard is 2, an index value corresponding to BS _ High is 3, an index value corresponding to BS _ Super is 4, an index value corresponding to BS _720p is 5, an index value corresponding to BS _1080p is 6, an index value corresponding to BS _4K is 7, and the like.
p0[ i ] indicates the probability of the player buffer being empty, or underflow, and in one embodiment, p0[ i ] can be obtained as follows:
1) respectively estimating the downloading time required by downloading a logic fragment by the various types of code streams based on the current network downloading speed, and defining the downloading time required by downloading w logic allocations as t;
in order to ensure the accuracy of the statistical downloading speed, the network downloading speed in the embodiment of the invention filters the abnormal downloading speed, and the severe change of the network speed in a short time can be filtered if the difference between the downloading speed of a certain time and the downloading speeds before and after is extremely large, so that the frequent code stream switching in a short time can be prevented.
In a specific implementation, the download time required for downloading one logical allocation may be estimated based on the current download speed, and the download time t of W logical slices may be calculated based on the download time of the one logical allocation.
2) Respectively calculating expected E (t) corresponding to the downloading time t;
after obtaining the download time t of each code stream for each logical fragment, the expectation e (t) of the download time t can be further calculated.
It should be noted that, while the desired e (t) of the download time t, the variance d (t) of the download time t may also be calculated.
3) P0[ i ] is calculated using the following formula:
p0[i]=1-1/E(t)[i]*μ;
wherein E (t) i represents the expectation of the code stream i; μ denotes a preset expectation of the decoding time required for the decoder to decode one logical slice.
Specifically, according to the expectation and variance formula of the k-th order irish distribution:
and combining the obtained expectation and the variance to obtain:
according to the stable distribution of the established Ek/M/1 queuing model, the solving formula of the target parameter can be known, and the key is to solve the equationIs the solution S outside the unique unit circle0For all roots of the polynomial equation of the nth order of the real coefficient, a QR method is adopted to convert the problem of solving all roots of the equation into the problem of solving all eigenvalues of a matrix, wherein the matrix is an upper H matrix (a Heishiber matrix), and then the solution which is more than 1 is selected from all eigenvalues, namely S0Where p is λ/μ, and μ is an expectation of a negative exponent distribution in the queue model when the player decodes the logic slice event stream, where the logic slice is set as undecoded data per unit time (1 second), that is, the code rate of the corresponding code stream, and it is known that the service rate μ of the decoder is 1, and then the average queue length formula is used to calculate the average queue lengthFinding Ls(ii) a The probability p that the player buffer is empty can be known by the smooth distribution formula of the Ek/M/1 queuing model01- ρ. Combined with the above formula, synthesizeThe formula p0[ i ] can be obtained]=1-1/E(t)[i]*μ。
And a substep S12, taking the code stream with the maximum quality value as a theoretical optimal code stream.
After the obtained G [ i ] of each code stream, the largest G [ i ], namely the code stream with the largest impression quality is finally used as the theoretical optimal code stream under the ideal condition.
In the concrete implementation, because the network speed of a user generally has not great change, the invention can also automatically update the default code stream into the calculated theoretical optimal code stream under the ideal condition, and the default code stream is used for preloading the next video during the video continuous broadcasting. When the player is closed, the calculated theoretical optimal code stream is stored locally, and when the player is started next time, the theoretical optimal code stream is used as a code stream loaded by the video default.
The reason why the theoretical optimal code stream is adopted instead of the actual optimal code stream (the actual optimal code stream will be described later) is that the code stream of the current film does not necessarily have all code streams from BS _150 to BS _4K, the theoretical optimal code stream in an ideal case is the optimal code stream calculated according to the network speed, the default initial code stream is most suitable, and the pause of starting the player for a period of time can be effectively reduced by adopting the theoretical optimal code stream calculated when the video is watched last time.
For the key parameter (4), the remaining playing time of the downloaded video data in the current playing buffer area is the remaining playing time of the loaded current playing code stream (i.e. the default code stream when the video data loading starts) in the playing buffer area, i.e. how many downloaded code streams are not played in the playing buffer area. For example, the remaining playing time may be 10 seconds, 20 seconds, and the like.
For the above-mentioned key parameter (5), to characterize the data change in the play buffer, a fitted curve may be obtained by recording the remaining play time of the downloaded video data per unit time (e.g. 1 second) in the play buffer for the latest first preset time period (the first preset time period may be represented by buffer _ time _ window — for example, the last 30 seconds, and the value of buffer _ time _ window _ is 30) in the play buffer, that is, by recording the remaining play time in the play buffer for the latest buffer _ time _ window — and performing curve fitting (curve fitting) on the recorded remaining play time.
Curve fitting refers to selecting a proper curve type to fit observation data, analyzing the relation between two variables by using a fitted curve equation, and in specific implementation, performing curve fitting by using a least square method. The method is called least square method, in which a fitting curve is selected according to the principle of minimum deviation sum of squares and a binomial equation is adopted as the fitting curve.
It should be noted that the smaller the buffer _ time _ window _ value is, the more sensitive it is, but the larger the error of the fitting curve is; the larger the buffer _ time _ window _ value is, the more dull the buffer _ time _ window _ value is, but the more correctly the linear fitting curve can reflect the change direction of the buffer data.
Because the video data downloading of the current player is interrupted by the seek operation (the operation of dragging the progress bar to a certain time point of the target video by the user), or the remaining playing time of the playing buffer area is greatly influenced when the player stops downloading data, thereby influencing the accuracy of curve fitting, the embodiment of the invention can clear the buffer _ time _ window _andrestart recording when the seek operation is performed by the user or the player stops downloading data.
For the key parameter (6), the embodiment of the present invention may select one code stream from the multiple code streams as the code stream determination criterion, for example, select a BS _ High code stream as the code stream determination criterion, take BS _ High as a boundary, take the BS _ High as a High-quality code stream, and take the BS _ High as a low-quality code stream.
For the key parameter (7), in a specific implementation, it is determined whether code stream switching is required, and not only a result of one-time segment determination but also accumulation of multiple determination results is performed, for example, when it is determined that the current code stream is switchable for the first time, the number of times of switchability is recorded as 1, when it is determined that the current code stream is switchable for the next time, the number of times of switchability is recorded as 2, and so on, and until the number of times of switchability reaches a second threshold, one-time switching is performed.
For the key parameter (8), the video server and/or the player can set the range of the switchable code stream, namely set the limit range of the highest code stream and the lowest code stream.
For the key parameter (9), the pause times are the pause times of the current code stream playing target video, and the pause times are increased by 1 after the current code stream playing target video is paused.
For the key parameter (10), the seek operation is an operation of the user dragging the progress bar to a certain time point of the movie, the seek operation of the user on the target video is detected, and the number of times of the seek operation at present is counted.
For the above key parameter (11), the total switching times of the target videos can be accumulated up to now.
In a specific implementation, the code stream switching frequency, that is, the minimum switching (including up-switching and down-switching, where up-switching is to a code stream one level higher than the currently played code stream, and down-switching is to a code stream one level lower than the currently played code stream) interval time may be set, so as to control the number of times of video switching. For example, the minimum time interval of the down-switch is controlled to be 60 seconds to 300 seconds and the minimum time interval of the up-switch is controlled to be 300 seconds to 600 seconds, so as to control the total switching times of a movie.
For the key parameters (12), the target video can use various types of code streams in the playing process, and the player can record the used code streams.
102, deciding an actual optimal code stream based on the key parameters;
after the player obtains the key parameters of the target video, an actual optimal code stream can be decided according to the key parameters, and the actual optimal code stream is not necessarily the same as the theoretical optimal code stream for the following reasons: the theoretical optimal code stream under the ideal condition calculated based on the Ek/M/1 queuing model only considers the network downloading speed (namely the network speed), and the result is credible when the requirement on the accuracy of the network speed is high, meanwhile, the ideal condition in the queuing model does not damage the stable process of the whole queuing model like the seek operation of a user, so the theoretical optimal code stream is only the optimal code stream under the ideal condition, and the result obtained by the Ek/M/1 queuing model alone is not very reliable. In specific implementation, various decision conditions need to be comprehensively considered to decide the actual optimal code stream.
In a preferred embodiment of the present invention, step 102 may comprise the following sub-steps:
a substep S21, selecting a plurality of key parameters from the key parameters as a plurality of decision factors;
in a specific implementation, all of the above key parameters may be used as the decision factor, or a part of the key parameters may be selected from the above key parameters to be used as the decision factor.
And a substep S22, deciding the actual optimal code stream based on the decision factor. After a plurality of decision factors are selected, the actual optimal code stream can be decided according to the decision factors. In a preferred embodiment of the present invention, the sub-step S22 further includes the following sub-steps:
substep S221, setting N decision conditions based on the decision factor, where N is a positive integer;
the decision condition is a condition which needs to be met by determining the actual optimal code stream. As an example, the decision condition may include some or all of the following conditions:
1) judging whether the remaining playing time of the downloaded video data in the current playing buffer area is greater than a first threshold value, if so, judging that the decision condition meets the threshold value standard, and if not, judging that the decision condition does not meet the threshold value standard;
the first threshold is a remaining playing time threshold corresponding to the theoretical optimal code stream, for example, a high-definition film is currently played, the network speed is relatively good, the theoretical optimal code stream is 720p calculated through an Ek/M/1 queuing model, that is, the current network speed can meet the normal playing of the 720p code stream, but if the remaining playing time of the video data downloaded in the playing buffer area is very small at the moment, for example, only 10 seconds (less than 20 seconds preset by 720 p), the probability that the code stream switched by 720p causes the pause is very high, and therefore it can be finally determined that the decision condition does not meet the threshold standard. If the remaining playing time of the video data downloaded by the playing buffer at this time is enough (more than 720p of the preset 20 seconds), the decision condition is determined to meet the threshold criterion.
2) Judging whether the fitting curve is in an ascending trend or a descending trend; if the trend is an ascending trend, the decision condition is judged to meet the threshold standard, and if the trend is a descending trend, the decision condition is judged to not meet the threshold standard;
the curve fitted is an upward trend or a downward trend, which can be determined by the slope of the curve, if the slope is less than 0, it indicates that the data in the buffer area has a decreasing trend, otherwise, it indicates that the data in the buffer area has an increasing trend.
The slope may be calculated by the formula y ═ ax + b, where x is the unit time, y is the remaining playing time of the downloaded video data in the playing buffer in the unit time, a is the slope, and b is the correction value. The values of a and b can be obtained from the values of x and y. When a <0, the data in the buffer area has a decreasing trend, otherwise, the data in the buffer area has an increasing trend.
3) Adjusting the threshold standard of each decision condition according to the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream;
and when the current code stream is judged to be a high-quality code stream or a low-quality code stream, the threshold standard of each decision condition can be adaptively adjusted according to the judgment result, wherein the threshold standard of each decision condition is a threshold for increasing or decreasing the key parameter. For example, if the current code stream is a high-quality code stream, such as BS _720P, the key parameters used when it is determined to switch up to BS _1080P will be stricter than the normal values; if the current code stream is a low-quality code stream, such as BS _150, the key parameter used when up-switching to a higher code stream is more relaxed than the normal value. Because the user has a good look and feel when the currently played code stream is a high-quality code stream, the user can switch to a higher-quality code stream upwards unless the network speed condition is very good, and can switch to a high-level code stream when the network speed condition is improved if the currently played code stream is a low-quality code stream.
In the embodiment of the invention, the selection of the key parameters and the setting of the threshold thereof need to be combined with player iteration to carry out actual test, and suitable key parameters and optimal thresholds are selected.
4) Judging whether the currently played code stream is judged to be switchable times larger than a second threshold value, if so, judging that the decision condition meets a threshold value standard, and if not, continuously accumulating the switchable times, or returning the currently accumulated switchable times to zero to continuously accumulate the switchable times, or returning the currently accumulated switchable times to zero;
the current playing code stream is judged to be switchable, namely the theoretical optimal code stream is the switchable code stream. When the number of switchable times reaches a second threshold value, for example, the currently played code stream is BS _ High, the second threshold value is set to 10 times, and the theoretical optimal code streams calculated for 10 consecutive times are all BS _720p, the decision condition 4) meets the threshold value standard, otherwise, the decision result does not need switching. For example, if the theoretical optimal code stream calculated at the current time of 8 times is BS _720p, and the optimal code stream calculated at the 9 th time is BS _ Hig, it is determined that the statistical frequency of the BS _720p switchable code stream returns to zero, and the statistical frequency is accumulated from the beginning.
5) Judging whether the theoretical optimal code stream is within the preset limit ranges of the highest code stream and the lowest code stream, if so, judging that the decision condition meets the threshold standard, and if not, judging that the decision condition does not meet the threshold standard;
6) selecting a code stream with a size suitable for the rendering area of the current player;
for example, if the optimal code stream is a high-quality code stream, but the rendering window of the current player is very small, the current player can clearly watch the code stream without very high speed, and even if the downloading speed is very high, the player does not need to switch to the high-quality code stream, so that the flow of the user is saved.
7) If the number of times of the pause is larger than a third threshold, adjusting the threshold standard of each decision condition;
for example, if the number of times of the pause is large, it is indicated that the threshold values of the key parameters of the up-regulation code stream in the adaptive code stream calculation process are unreasonable, and the threshold values can be properly expanded, so that the standard of the up-switching is improved.
8) If the dragged seek record is larger than a fourth threshold, adjusting the threshold standard of each decision condition;
the seek operation of the user can affect the film preloading, for example, when the user seek is to a position without preloading, the player needs to load data from the time point again, the previously buffered data will be discarded, if the seek operation times are many, the key parameter threshold used in the adaptive code stream calculation process will not be completely suitable, the thresholds can be expanded appropriately, and the standard for calculating the optimal code stream is improved.
9) Judging whether the total switching times of the target video is greater than a fifth threshold, if so, judging that the decision condition does not meet the threshold standard, and if not, judging that the decision condition meets the threshold standard;
and if the total switching times of the recorded target video is larger than a fifth threshold value, indicating that the target video has frequently switched code streams, and at the moment, the decision condition does not meet the threshold value standard. Otherwise, the decision condition satisfies a threshold criterion.
10) And according to the used code stream records, if the existing time of a certain code stream is lower than a sixth threshold value, not selecting the code stream as an actual optimal code stream.
The decision factor (10) can be applied to a special case, as shown in fig. 3, in the case found during the test, the code stream is frequently switched between BS _150 and BS _720, because the same movie is under the same network condition, the downloading speed is fast when the BS _150 code stream is adopted, the downloading speed is rapidly reduced after the BS _720 is switched, the downloading speed is continuously maintained, after the BS _150 code stream is switched, the network speed is normal, the downloading speed is rapidly reduced after the BS _720 code stream is switched again, and …. This situation is not common, but may also exist, so the embodiment of the present invention adds a record of the code stream used by the film and the existence time of the code stream, and when a decision is made, if the existence time of a certain previously used code stream is found to be short, it is not suitable to switch to this code stream.
In the substep S222, if the decision conditions all meet the corresponding threshold criteria, taking the theoretical optimal code stream as the actual optimal code stream;
and a substep S223 of taking the next-level code stream corresponding to the theoretical optimal code stream as the actual optimal code stream or taking the currently played code stream as the actual optimal code stream if any decision condition does not meet the corresponding threshold standard. For example, the currently played code stream is BS _ Standard, the user network speed gradually becomes better, the theoretical optimal code stream calculated by the adaptive code stream module is BS _720p, but it is found from the code stream existence list played by the movie that the existence time of the movie in the BS _720p code stream is too short to be suitable for playing the BS _720p code stream again, at this time, a level, that is, BS _ High, may be adjusted downward to be the actual optimal code stream determined, and if the BS _ High film source of the movie does not exist, the currently played code stream is the actual optimal code stream. In another case, the currently played code stream is BS _ High, the calculated theoretical optimal code stream is BS _720p, and if the above similar cases occur, the currently played code stream is exactly the down-regulated one level.
And after the decision conditions are set, when the decision conditions all meet the requirements, the theoretical optimal code stream is used as the actual optimal code stream, if not all the decision conditions all meet the requirements, the actual optimal code stream can be lowered to the next-level code stream of the theoretical optimal code stream by comprehensively referring to other decision conditions, or the currently played code stream is used as the actual optimal code stream.
For example, the network speed is relatively good when a high-definition film is played currently, and the theoretical optimal play code stream calculated by an Ek/M/1 queuing model is 720p, that is, the current network speed can meet the normal play of the 720p code stream. The set decision conditions include the above (1), (2) and (9), if the remaining buffer data in the play buffer area is little at this time, such as only 10 seconds (less than the preset 20 seconds), the probability of blockage caused by switching the 720p code stream is very large, the decision condition (1) is not satisfied, and the actual optimal code stream of the final decision is the current play code stream; if the data of the buffer area is enough (more than the preset 20 seconds), namely the decision condition (1) is met, and if the fitting curve obtained after linear fitting according to the residual playing time of the playing buffer area has a decreasing trend and does not meet the decision condition (2), the actual optimal code stream of the final decision is also the current playing code stream; if the data in the buffer area is enough (the decision factor (1) is met), and the fitting curve has a gradual increasing trend (the decision factor (2) is met), if the switching frequency of the local film is judged to exceed a fifth threshold value, and if the switching frequency exceeds (the decision factor (4) is not met), the finally decided actual optimal code stream is also the current playing code stream; and if the code stream does not exceed the decision factor (4), the finally decided actual optimal code stream is also the theoretical optimal code stream.
103, when the actual optimal code stream is different from the current playing code stream, calculating a switching time;
the actual optimal code stream is different from the currently played code stream, which indicates that the currently played code stream needs to be switched to the actual optimal code stream. In a preferred embodiment of the present invention, step 103 may comprise the following sub-steps:
substep S31, setting the preloading minimum buffer time corresponding to each code stream;
the calculation of the switching time directly influences the fluency of code stream switching, and the seamless switching of two code streams is required to improve the viewing experience of a user, so that the key frames of the two code streams on a server are aligned, the audio tracks are aligned, and the pre-loading of the data of the code stream to be switched (the optimal code stream) is ensured when the code stream is switched by a client. Therefore, the embodiment of the invention sets the pre-loading minimum buffer time corresponding to various code streams, and the selection of the pre-loading minimum buffer time can select different times according to different code streams.
And a substep S32, when the actual optimal code stream is different from the current playing code stream, calculating the switching time by adopting the following formula:
time=(bs_rate_[result]*5000)/average_download_speed_+bs_min_buffer_time_[result]);
wherein bs _ rate _ [ result ] represents the code rate of the optimal code stream, average _ download _ speed _ is the current average network download speed, and bs _ min _ buffer _ time _ [ result ] represents the preset minimum buffer time. The higher the code stream quality, the larger the value of Time.
And 104, switching the currently played code stream of the target video into the actual optimal code stream when the switching time is up.
In a preferred embodiment of the present invention, step 104 may comprise the following sub-steps:
substep S41, calculating an optimal key frame position within a preset range of the switching opportunity;
the embodiment of the invention corrects the calculated switching time according to the optimal key frame position, wherein the optimal key frame position is the position of a key frame closest to the switching time. For example, the calculated switching opportunity is a 320s switching of the movie, but there is not necessarily a key frame at 320s, but there is a key frame at 317.120s and a key frame at 321.300s, then the optimal key frame is 321.300s, i.e. the final switching opportunity is 321.300s of the movie.
Substep S42, subtracting the preloading minimum buffer time of the actual optimal code stream from the optimal key frame position to obtain a preloading position;
step S43, when the target video is played to the preloading position, stopping loading the current playing code stream, and starting loading the actual optimal code stream;
in order to ensure seamless switching, the embodiment of the invention can pre-load the actual optimal code stream at the minimum buffering time away from the optimal key frame position. Specifically, the embodiment of the invention subtracts the preloading minimum buffering time from the optimal key frame position to obtain a preloading position; and carrying out loading switching at the preloading position, namely stopping loading the current code stream and starting loading the actual optimal code stream. For example, the code stream played by the current movie is high definition, the network gradually gets better in the playing process, the actual optimal code stream is determined to be 720p, the switching time is 320s, the current playing time is 300s, namely, the network can be switched to 720p after 20s, the optimal key frame position corresponding to 320s is 320.766s, the minimum buffering time of the actual optimal code stream is 20s, the loading of the high definition code stream data can be stopped at 300s, and the 720p data can be preloaded.
And a substep S44, when the target video is played to the optimal key frame position, sending the key frame with the same position as the optimal key frame in the actual optimal code stream to a decoder.
When the method and the device are applied to the embodiment of the invention, the current code stream can be switched to the key frame with the same preloaded optimal code stream when the current code stream is played to the optimal key frame position, and the seamless switching is completed. For example, in the above example, when the current code stream is played to 320.766s, the same code stream of 720p is switched to and transmitted to the decoder, and the seamless switching is completed.
In the embodiment of the invention, when the player detects that the last video is played and the target video is played continuously, or the player is started for the first time to start playing the target video, the player obtains the key parameter, decides the actual optimal code stream according to the key parameter, calculates the reasonable switching time when the actual optimal code stream is different from the currently played code stream, and switches the code streams when the switching time is reached, thereby ensuring seamless and smooth switching of the two code streams and improving the watching experience of a user.
In addition, the present invention does not rely on a specific platform for HTTP adaptive streaming systems.
In addition, the invention comprehensively considers various key parameters and various decision conditions to decide the actual optimal code stream, so that the invention can give consideration to the video definition and obviously reduce the player card pause ratio, and as can be seen from fig. 4, about 55% of the card pauses appear when the code stream is BS _150, which shows that the invention is practical and effective, because the BS _150 code stream is the lowest code stream provided by the video server, the card pauses appear when the code stream is played, which shows that the user network is very poor, and the card pauses can not be avoided due to the network speed difference. The ratio of the number of times of blocking in the code stream to the total number of times of blocking is higher than the sum of the number of times of blocking in other code streams, which shows that the embodiment of the invention has accurate control on the code stream. As can be seen from FIG. 5, the effect of the player's Caton ratio is obvious after the invention is used, the average Caton ratio is 6.1% when the invention is not used, and the average Caton ratio is 3.8% after the invention is used, and the Caton ratio is reduced by 37.7%.
However, the ratio of the number of stutter times in the BS _150 code stream to the total number of stutter times is not higher, and is better, because the invention not only needs to reduce the stutter ratio, but also needs to consider the video definition, and the optimal adaptive dynamic code stream scheme is obtained by reasonably compromising the two.
It should be noted that, for simplicity of description, the method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present invention is not limited by the illustrated order of acts, as some steps may occur in other orders or concurrently in accordance with the embodiments of the present invention. Further, those skilled in the art will appreciate that the embodiments described in the specification are presently preferred and that no particular act is required to implement the invention.
Referring to fig. 6, a block diagram of a code stream switching apparatus according to an embodiment of the present invention is shown, and specifically includes the following modules:
a key parameter obtaining module 601, configured to obtain a key parameter when a previous video is played and a target video is played continuously, or when a player is started for the first time and starts to play the target video;
a decision module 602, configured to decide an actual optimal code stream based on the key parameter;
a switching time calculation module 603, configured to calculate a switching time when the actual optimal code stream is different from the currently played code stream;
a switching module 604, configured to switch the currently played code stream of the target video to the actual optimal code stream when the switching time arrives.
In a preferred embodiment of the present invention, the decision module 602 includes:
the parameter selection submodule is used for selecting a plurality of key parameters from the key parameters to serve as a plurality of decision factors;
and the decision submodule is used for deciding the actual optimal code stream based on the decision factor.
As a preferred example of the embodiment of the present invention, the key parameters at least include:
(1) a code stream type list supported by the target video, wherein the code stream type list comprises various types of code streams;
(2) current player rendering region size;
(3) theoretically optimizing the code stream;
(4) the residual playing time of the downloaded video data in the current playing buffer area;
(5) in the latest first preset time period, performing curve fitting on the residual playing time of the downloaded video data in the playing buffer zone corresponding to each unit time to obtain a fitting curve;
(6) judging the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream according to a preset code stream judgment standard;
(7) stopping the preset time, and judging the current playing code stream as switchable times;
(8) presetting a limit range of a highest code stream and a lowest code stream;
(9) the pause times of the target video playing;
(10) dragging seek record of a target video dragged to a certain position by a user;
(11) the total switching times of the current target video;
(12) and recording the used code stream of the target video film.
In a preferred embodiment of the present invention, the multiple types of code streams include code stream levels, and the decision sub-module is further configured to:
setting N decision conditions based on the decision factor, wherein N is a positive integer;
if the decision conditions all meet corresponding threshold value standards, taking the theoretical optimal code stream as the actual optimal code stream;
and if any decision condition does not meet the corresponding threshold value standard, taking the code stream of the next level corresponding to the theoretical optimal code stream as the actual optimal code stream, or taking the currently played code stream as the actual optimal code stream.
As a preferred example of the embodiment of the present invention, the decision condition includes part or all of the following conditions:
1) judging whether the remaining playing time of the downloaded video data in the current playing buffer area is greater than a first threshold value, if so, judging that the decision condition meets the threshold value standard, and if not, judging that the decision condition does not meet the threshold value standard;
2) judging whether the fitting curve is in an ascending trend or a descending trend; if the trend is an ascending trend, the decision condition is judged to meet the threshold standard, and if the trend is a descending trend, the decision condition is judged to not meet the threshold standard;
3) adjusting the threshold standard of each decision condition according to the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream;
4) judging whether the currently played code stream is judged to be switchable times larger than a second threshold value, if so, judging that the decision condition meets a threshold value standard, and if not, continuing to accumulate the switchable times or returning the currently accumulated switchable times to zero;
5) judging whether the theoretical optimal code stream is within the preset limit ranges of the highest code stream and the lowest code stream, if so, judging that the decision condition meets the threshold standard, and if not, judging that the decision condition does not meet the threshold standard;
6) selecting a code stream with a size suitable for the rendering area of the current player;
7) if the number of times of the pause is larger than a third threshold, adjusting the threshold standard of each decision condition;
8) if the dragged seek record is larger than a fourth threshold, adjusting the threshold standard of each decision condition;
9) judging whether the total switching times of the target video is greater than a fifth threshold, if so, judging that the decision condition does not meet the threshold standard, and if not, judging that the decision condition meets the threshold standard;
10) and according to the used code stream records, if the existing time of a certain code stream is lower than a sixth threshold value, not selecting the code stream as an actual optimal code stream.
In a preferred embodiment of the present invention, the key parameter obtaining module 601 is further configured to:
respectively calculating the quality values of the various types of code streams;
and taking the code stream with the maximum quality value as a theoretical optimal code stream.
In a preferred embodiment of the present invention, the following formula is adopted to calculate the quality values of the multiple types of code streams respectively:
G[i]=Q[i]-p0[i]*cost[i]-costs*(i-current_bitstream_index);
wherein i represents the type identification of the code stream, G [ i ] represents the quality value of the code stream, Q [ i ] represents the preset initial quality value corresponding to various types of code streams, and cost [ i ] represents the preset first quality loss value caused by the pause of various code streams during playing; costs represents a preset second quality loss value caused by switching of two code streams; current _ bitstream _ index represents a preset index value of a currently played code stream; p0[ i ] represents the probability that the player buffer is empty.
In a preferred embodiment of the present invention, the target video comprises a plurality of logical slices; said p0[ i ] is obtained as follows:
respectively estimating the downloading time required by downloading a logic fragment by the various types of code streams based on the current network downloading speed, and defining the downloading time required by downloading w logic allocations as t;
respectively calculating expected E (t) corresponding to the downloading time t;
p0[ i ] is calculated using the following formula:
p0[i]=1-1/E(t)[i]*μ;
wherein E (t) i represents the expectation of the code stream i; μ denotes a preset expectation of the decoding time required for the decoder to decode one logical slice.
In a preferred embodiment of the present invention, the switching opportunity calculating module 603 includes:
the buffer time setting submodule is used for setting the pre-loaded minimum buffer time corresponding to various code streams;
the calculation submodule is used for calculating the switching time by adopting the following formula when the actual optimal code stream is different from the current playing code stream:
time=(bs_rate_[result]*5000)/average_download_speed_+bs_min_buffer_time_[result]);
wherein bs _ rate _ [ result ] represents the code rate of the actual optimal code stream, average _ download _ speed _ is the current average network download speed, and bs _ min _ buffer _ time _ [ result ] represents the preloading minimum buffer time of the actual optimal code stream.
In a preferred embodiment of the present invention, the switching module 604 includes:
the position calculation submodule is used for calculating the optimal key frame position within the preset range of the switching opportunity;
the preloading position calculation submodule is used for subtracting the preloading minimum buffer time of the actual optimal code stream from the optimal key frame position to obtain a preloading position;
the preloading submodule is used for stopping loading the currently played code stream and starting loading the actual optimal code stream when the target video is played to the preloading position;
and the switching submodule is used for sending the key frame with the same position as the optimal key frame in the actual optimal code stream to a decoder when the target video is played to the optimal key frame position.
For the device embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment.
The embodiments in the present specification are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, embodiments of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
Embodiments of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing terminal to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing terminal to cause a series of operational steps to be performed on the computer or other programmable terminal to produce a computer implemented process such that the instructions which execute on the computer or other programmable terminal provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present invention have been described, additional variations and modifications of these embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the embodiments of the invention.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or terminal. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or terminal that comprises the element.
The above provides a code stream switching method and a code stream switching apparatus, which are introduced in detail, and the specific examples are applied herein to explain the principle and implementation of the present invention, and the descriptions of the above embodiments are only used to help understanding the method and the core idea of the present invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.
Claims (20)
1. A code stream switching method is characterized by comprising the following steps:
when the last video is played and the target video is played continuously, or when the player is started for the first time to start playing the target video, key parameters are obtained;
deciding an actual optimal code stream based on the key parameters;
when the actual optimal code stream is different from the current playing code stream, calculating the switching time;
and when the switching time is up, switching the current playing code stream of the target video into the actual optimal code stream.
2. The method according to claim 1, wherein the step of deciding the actual optimal code stream based on the key parameter comprises:
selecting a plurality of key parameters from the key parameters as a plurality of decision factors;
and deciding the actual optimal code stream based on the decision factor.
3. The method according to claim 2, characterized in that said key parameters comprise at least:
(1) a code stream type list supported by the target video, wherein the code stream type list comprises various types of code streams;
(2) current player rendering region size;
(3) theoretically optimizing the code stream;
(4) the residual playing time of the downloaded video data in the current playing buffer area;
(5) in the latest first preset time period, performing curve fitting on the residual playing time of the downloaded video data in the playing buffer zone corresponding to each unit time to obtain a fitting curve;
(6) judging the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream according to a preset code stream judgment standard;
(7) stopping the preset time, and judging the current playing code stream as switchable times;
(8) presetting a limit range of a highest code stream and a lowest code stream;
(9) the pause times of the target video playing;
(10) dragging seek record of a target video dragged to a certain position by a user;
(11) the total switching times of the current target video;
(12) and recording the used code stream of the target video film.
4. The method according to claim 3, wherein the plurality of types of code streams include code stream levels, and the step of deciding an actual optimal code stream based on the decision factor includes:
setting N decision conditions based on the decision factor, wherein N is a positive integer;
if the decision conditions all meet corresponding threshold value standards, taking the theoretical optimal code stream as the actual optimal code stream;
and if any decision condition does not meet the corresponding threshold value standard, taking the code stream of the next level corresponding to the theoretical optimal code stream as the actual optimal code stream, or taking the currently played code stream as the actual optimal code stream.
5. The method of claim 4, wherein the decision condition comprises some or all of the following conditions:
1) judging whether the remaining playing time of the downloaded video data in the current playing buffer area is greater than a first threshold value, if so, judging that the decision condition meets the threshold value standard, and if not, judging that the decision condition does not meet the threshold value standard;
2) judging whether the fitting curve is in an ascending trend or a descending trend; if the trend is an ascending trend, the decision condition is judged to meet the threshold standard, and if the trend is a descending trend, the decision condition is judged to not meet the threshold standard;
3) adjusting the threshold standard of each decision condition according to the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream;
4) judging whether the currently played code stream is judged to be switchable times larger than a second threshold value, if so, judging that the decision condition meets a threshold value standard, and if not, continuing to accumulate the switchable times or returning the currently accumulated switchable times to zero;
5) judging whether the theoretical optimal code stream is within the preset limit ranges of the highest code stream and the lowest code stream, if so, judging that the decision condition meets the threshold standard, and if not, judging that the decision condition does not meet the threshold standard;
6) selecting a code stream with a size suitable for the rendering area of the current player;
7) if the number of times of the pause is larger than a third threshold, adjusting the threshold standard of each decision condition;
8) if the dragged seek record is larger than a fourth threshold, adjusting the threshold standard of each decision condition;
9) judging whether the total switching times of the target video is greater than a fifth threshold, if so, judging that the decision condition does not meet the threshold standard, and if not, judging that the decision condition meets the threshold standard;
10) and according to the used code stream records, if the existing time of a certain code stream is lower than a sixth threshold value, not selecting the code stream as an actual optimal code stream.
6. The method according to claim 3, 4 or 5, wherein the theoretical optimal code stream is obtained as follows:
respectively calculating the quality values of the various types of code streams;
and taking the code stream with the maximum quality value as a theoretical optimal code stream.
7. The method according to claim 6, wherein the quality values of the plurality of types of code streams are respectively calculated by using the following formula:
G[i]=Q[i]-p0[i]*cost[i]-costs*(i-current_bitstream_index);
wherein i represents the type identification of the code stream, G [ i ] represents the quality value of the code stream, Q [ i ] represents the preset initial quality value corresponding to various types of code streams, and cost [ i ] represents the preset first quality loss value caused by the pause of various code streams during playing; costs represents a preset second quality loss value caused by switching of two code streams; current _ bitstream _ index represents a preset index value of a currently played code stream; p0[ i ] represents the probability that the player buffer is empty.
8. The method of claim 7, wherein the target video comprises a plurality of logical tiles; said p0[ i ] is obtained as follows:
respectively estimating the downloading time required by downloading a logic fragment by the various types of code streams based on the current network downloading speed, and defining the downloading time required by downloading w logic allocations as t;
respectively calculating expected E (t) corresponding to the downloading time t;
p0[ i ] is calculated using the following formula:
p0[i]=1-1/E(t)[i]*μ;
wherein E (t) i represents the expectation of the code stream i; μ denotes a preset expectation of the decoding time required for the decoder to decode one logical slice.
9. The method according to claim 1 or 2, wherein the step of calculating the switching time when the actual optimal code stream is different from the currently played code stream comprises:
setting pre-loading minimum buffer time corresponding to various code streams;
when the actual optimal code stream is different from the current playing code stream, calculating the switching time by adopting the following formula:
time=(bs_rate_[result]*5000)/average_download_speed_+bs_min_buffer_time_[result]);
wherein bs _ rate _ [ result ] represents the code rate of the actual optimal code stream, average _ download _ speed _ is the current average network download speed, and bs _ min _ buffer _ time _ [ result ] represents the preloading minimum buffer time of the actual optimal code stream.
10. The method according to claim 9, wherein the step of switching the currently played code stream of the target video to the actually optimal code stream when the switching occasion is reached comprises:
calculating the optimal key frame position within the preset range of the switching opportunity;
subtracting the preloading minimum buffer time of the actual optimal code stream from the optimal key frame position to obtain a preloading position;
when the target video is played to the preloading position, stopping loading the currently played code stream, and starting loading the actual optimal code stream;
and when the target video is played to the optimal key frame position, sending the key frame with the same position as the optimal key frame in the actual optimal code stream to a decoder.
11. A code stream switching apparatus, comprising:
the key parameter acquisition module is used for acquiring key parameters when the last video is played and the target video is played continuously or when the player is started for the first time to start playing the target video;
the decision module is used for deciding an actual optimal code stream based on the key parameters;
the switching time calculation module is used for calculating the switching time when the actual optimal code stream is different from the current playing code stream;
and the switching module is used for switching the currently played code stream of the target video into the actual optimal code stream when the switching time arrives.
12. The apparatus of claim 11, wherein the decision module comprises:
the parameter selection submodule is used for selecting a plurality of key parameters from the key parameters to serve as a plurality of decision factors;
and the decision submodule is used for deciding the actual optimal code stream based on the decision factor.
13. The apparatus of claim 12, wherein the key parameters comprise at least:
(1) a code stream type list supported by the target video, wherein the code stream type list comprises various types of code streams;
(2) current player rendering region size;
(3) theoretically optimizing the code stream;
(4) the residual playing time of the downloaded video data in the current playing buffer area;
(5) in the latest first preset time period, performing curve fitting on the residual playing time of the downloaded video data in the playing buffer zone corresponding to each unit time to obtain a fitting curve;
(6) judging the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream according to a preset code stream judgment standard;
(7) stopping the preset time, and judging the current playing code stream as switchable times;
(8) presetting a limit range of a highest code stream and a lowest code stream;
(9) the pause times of the target video playing;
(10) dragging seek record of a target video dragged to a certain position by a user;
(11) the total switching times of the current target video;
(12) and recording the used code stream of the target video film.
14. The apparatus of claim 13, wherein the plurality of types of codestreams include a codestream level, and wherein the decision sub-module is further configured to:
setting N decision conditions based on the decision factor, wherein N is a positive integer;
if the decision conditions all meet corresponding threshold value standards, taking the theoretical optimal code stream as the actual optimal code stream;
and if any decision condition does not meet the corresponding threshold value standard, taking the code stream of the next level corresponding to the theoretical optimal code stream as the actual optimal code stream, or taking the currently played code stream as the actual optimal code stream.
15. The apparatus of claim 14, wherein the decision condition comprises some or all of the following conditions:
1) judging whether the remaining playing time of the downloaded video data in the current playing buffer area is greater than a first threshold value, if so, judging that the decision condition meets the threshold value standard, and if not, judging that the decision condition does not meet the threshold value standard;
2) judging whether the fitting curve is in an ascending trend or a descending trend; if the trend is an ascending trend, the decision condition is judged to meet the threshold standard, and if the trend is a descending trend, the decision condition is judged to not meet the threshold standard;
3) adjusting the threshold standard of each decision condition according to the judgment result that the current playing code stream is a high-quality code stream or a low-quality code stream;
4) judging whether the currently played code stream is judged to be switchable times larger than a second threshold value, if so, judging that the decision condition meets a threshold value standard, and if not, continuing to accumulate the switchable times or returning the currently accumulated switchable times to zero;
5) judging whether the theoretical optimal code stream is within the preset limit ranges of the highest code stream and the lowest code stream, if so, judging that the decision condition meets the threshold standard, and if not, judging that the decision condition does not meet the threshold standard;
6) selecting a code stream with a size suitable for the rendering area of the current player;
7) if the number of times of the pause is larger than a third threshold, adjusting the threshold standard of each decision condition;
8) if the dragged seek record is larger than a fourth threshold, adjusting the threshold standard of each decision condition;
9) judging whether the total switching times of the target video is greater than a fifth threshold, if so, judging that the decision condition does not meet the threshold standard, and if not, judging that the decision condition meets the threshold standard;
10) and according to the used code stream records, if the existing time of a certain code stream is lower than a sixth threshold value, not selecting the code stream as an actual optimal code stream.
16. The apparatus of claim 13, 14 or 15, wherein the key parameter obtaining module is further configured to:
respectively calculating the quality values of the various types of code streams;
and taking the code stream with the maximum quality value as a theoretical optimal code stream.
17. The apparatus according to claim 16, wherein the quality values of the plurality of types of codestreams are respectively calculated using the following formula:
G[i]=Q[i]-p0[i]*cost[i]-costs*(i-current_bitstream_index);
wherein i represents the type identification of the code stream, G [ i ] represents the quality value of the code stream, Q [ i ] represents the preset initial quality value corresponding to various types of code streams, and cost [ i ] represents the preset first quality loss value caused by the pause of various code streams during playing; costs represents a preset second quality loss value caused by switching of two code streams; current _ bitstream _ index represents a preset index value of a currently played code stream; p0[ i ] represents the probability that the player buffer is empty.
18. The apparatus of claim 17, wherein the target video comprises a plurality of logical tiles; said p0[ i ] is obtained as follows:
respectively estimating the downloading time required by downloading a logic fragment by the various types of code streams based on the current network downloading speed, and defining the downloading time required by downloading w logic allocations as t;
respectively calculating expected E (t) corresponding to the downloading time t;
p0[ i ] is calculated using the following formula:
p0[i]=1-1/E(t)[i]*μ;
wherein E (t) i represents the expectation of the code stream i; μ denotes a preset expectation of the decoding time required for the decoder to decode one logical slice.
19. The apparatus according to claim 11 or 12, wherein the switching occasion calculation module comprises:
the buffer time setting submodule is used for setting the pre-loaded minimum buffer time corresponding to various code streams;
the calculation submodule is used for calculating the switching time by adopting the following formula when the actual optimal code stream is different from the current playing code stream:
time=(bs_rate_[result]*5000)/average_download_speed_+bs_min_buffer_time_[result]);
wherein bs _ rate _ [ result ] represents the code rate of the actual optimal code stream, average _ download _ speed _ is the current average network download speed, and bs _ min _ buffer _ time _ [ result ] represents the preloading minimum buffer time of the actual optimal code stream.
20. The apparatus of claim 19, wherein the switching module comprises:
the position calculation submodule is used for calculating the optimal key frame position within the preset range of the switching opportunity;
the preloading position calculation submodule is used for subtracting the preloading minimum buffer time of the actual optimal code stream from the optimal key frame position to obtain a preloading position;
the preloading submodule is used for stopping loading the currently played code stream and starting loading the actual optimal code stream when the target video is played to the preloading position;
and the switching submodule is used for sending the key frame with the same position as the optimal key frame in the actual optimal code stream to a decoder when the target video is played to the optimal key frame position.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510185473.8A CN104967884B (en) | 2015-04-17 | 2015-04-17 | A kind of bitstreams switching method and apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510185473.8A CN104967884B (en) | 2015-04-17 | 2015-04-17 | A kind of bitstreams switching method and apparatus |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104967884A true CN104967884A (en) | 2015-10-07 |
CN104967884B CN104967884B (en) | 2018-01-26 |
Family
ID=54221807
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510185473.8A Active CN104967884B (en) | 2015-04-17 | 2015-04-17 | A kind of bitstreams switching method and apparatus |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104967884B (en) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106878828A (en) * | 2017-02-21 | 2017-06-20 | 微鲸科技有限公司 | The method and device of automatic switchover multimedia code check |
CN106921870A (en) * | 2015-12-24 | 2017-07-04 | 北京奇虎科技有限公司 | A kind of video broadcasting method and device |
CN106937141A (en) * | 2017-03-24 | 2017-07-07 | 北京奇艺世纪科技有限公司 | A kind of bitstreams switching method and device |
CN107071529A (en) * | 2017-03-29 | 2017-08-18 | 咪咕视讯科技有限公司 | A kind of HLS video broadcasting methods, terminal and server |
CN108307248A (en) * | 2018-02-01 | 2018-07-20 | 腾讯科技(深圳)有限公司 | Video broadcasting method, device, computing device and storage medium |
CN109361756A (en) * | 2018-11-08 | 2019-02-19 | 重庆急视飞救科技发展有限公司 | Cross-platform data transmission method based on 120 network alarmings |
CN109803167A (en) * | 2017-11-17 | 2019-05-24 | 中国电信股份有限公司 | Stream media document transmission method, streaming media clients and computer readable storage medium |
CN110087110A (en) * | 2019-06-12 | 2019-08-02 | 深圳市大数据研究院 | Using the method and device of deep search dynamic regulation video playing |
CN107666593B (en) * | 2017-08-28 | 2020-04-21 | 中国电子科技集团公司第二十八研究所 | Video real-time transmission method under fluctuating network environment |
WO2020151399A1 (en) * | 2019-01-23 | 2020-07-30 | 上海哔哩哔哩科技有限公司 | Method and device for pseudo-seamless switching between different video sources played by web and medium |
CN111866433A (en) * | 2020-07-31 | 2020-10-30 | 腾讯科技(深圳)有限公司 | Video source switching method, video source playing method, video source switching device, video source playing device, video source equipment and storage medium |
CN113721908A (en) * | 2021-08-30 | 2021-11-30 | 湖南快乐阳光互动娱乐传媒有限公司 | Infinite cascade assembly rendering method and device |
CN113948054A (en) * | 2020-07-15 | 2022-01-18 | 北京破壁者科技有限公司 | Audio track processing method, device, electronic equipment and storage medium |
CN114025211A (en) * | 2021-10-27 | 2022-02-08 | 福建野小兽健康科技有限公司 | Video issuing method and system adaptive to user equipment |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101421936A (en) * | 2006-03-03 | 2009-04-29 | 维德约股份有限公司 | System and method for providing error resilience, random access and rate control in scalable video communications |
US20100166056A1 (en) * | 2002-12-10 | 2010-07-01 | Steve Perlman | System and method for encoding video using a selected tile and tile rotation pattern |
CN102291599A (en) * | 2011-05-07 | 2011-12-21 | 董友球 | Network video playing method and network video playing device |
WO2013059930A1 (en) * | 2011-10-28 | 2013-05-02 | Avvasi Inc. | Methods and apparatus for providing a media stream quality signal |
CN103248953A (en) * | 2013-04-24 | 2013-08-14 | Tcl集团股份有限公司 | Method and system for processing TV advertisement time and TV programme playing terminal |
US20130227080A1 (en) * | 2012-02-27 | 2013-08-29 | Qualcomm Incorporated | Dash client and receiver with playback rate selection |
CN103297847A (en) * | 2013-04-28 | 2013-09-11 | 四川长虹电器股份有限公司 | Method for achieving signal source intelligent navigation and switching |
CN103428105A (en) * | 2012-05-14 | 2013-12-04 | 中国科学院声学研究所 | Self-adaptive HTTP streaming code stream switching method and system based on bandwidth estimation |
CN103428107A (en) * | 2012-05-14 | 2013-12-04 | 中国科学院声学研究所 | Self-adaptive bitstream switching method and system based on cache underflow probability estimation |
CN103686167A (en) * | 2013-12-24 | 2014-03-26 | 广东威创视讯科技股份有限公司 | Multi-stream broadcast method and device |
CA2804741A1 (en) * | 2013-01-21 | 2014-07-21 | Disternet Technology, Inc. | Media server |
CN103997680A (en) * | 2014-06-06 | 2014-08-20 | 北京奇艺世纪科技有限公司 | Switching method and device of video bitstream |
CN104219579A (en) * | 2014-08-20 | 2014-12-17 | 北京奇艺世纪科技有限公司 | Video switching method and video switching device |
-
2015
- 2015-04-17 CN CN201510185473.8A patent/CN104967884B/en active Active
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100166056A1 (en) * | 2002-12-10 | 2010-07-01 | Steve Perlman | System and method for encoding video using a selected tile and tile rotation pattern |
CN101421936A (en) * | 2006-03-03 | 2009-04-29 | 维德约股份有限公司 | System and method for providing error resilience, random access and rate control in scalable video communications |
CN102291599A (en) * | 2011-05-07 | 2011-12-21 | 董友球 | Network video playing method and network video playing device |
WO2013059930A1 (en) * | 2011-10-28 | 2013-05-02 | Avvasi Inc. | Methods and apparatus for providing a media stream quality signal |
US20130227080A1 (en) * | 2012-02-27 | 2013-08-29 | Qualcomm Incorporated | Dash client and receiver with playback rate selection |
CN103428105A (en) * | 2012-05-14 | 2013-12-04 | 中国科学院声学研究所 | Self-adaptive HTTP streaming code stream switching method and system based on bandwidth estimation |
CN103428107A (en) * | 2012-05-14 | 2013-12-04 | 中国科学院声学研究所 | Self-adaptive bitstream switching method and system based on cache underflow probability estimation |
CA2804741A1 (en) * | 2013-01-21 | 2014-07-21 | Disternet Technology, Inc. | Media server |
CN103248953A (en) * | 2013-04-24 | 2013-08-14 | Tcl集团股份有限公司 | Method and system for processing TV advertisement time and TV programme playing terminal |
CN103297847A (en) * | 2013-04-28 | 2013-09-11 | 四川长虹电器股份有限公司 | Method for achieving signal source intelligent navigation and switching |
CN103686167A (en) * | 2013-12-24 | 2014-03-26 | 广东威创视讯科技股份有限公司 | Multi-stream broadcast method and device |
CN103997680A (en) * | 2014-06-06 | 2014-08-20 | 北京奇艺世纪科技有限公司 | Switching method and device of video bitstream |
CN104219579A (en) * | 2014-08-20 | 2014-12-17 | 北京奇艺世纪科技有限公司 | Video switching method and video switching device |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106921870A (en) * | 2015-12-24 | 2017-07-04 | 北京奇虎科技有限公司 | A kind of video broadcasting method and device |
CN106878828A (en) * | 2017-02-21 | 2017-06-20 | 微鲸科技有限公司 | The method and device of automatic switchover multimedia code check |
CN106937141A (en) * | 2017-03-24 | 2017-07-07 | 北京奇艺世纪科技有限公司 | A kind of bitstreams switching method and device |
CN107071529A (en) * | 2017-03-29 | 2017-08-18 | 咪咕视讯科技有限公司 | A kind of HLS video broadcasting methods, terminal and server |
CN107071529B (en) * | 2017-03-29 | 2018-10-26 | 咪咕视讯科技有限公司 | A kind of HLS video broadcasting methods, terminal and server |
CN107666593B (en) * | 2017-08-28 | 2020-04-21 | 中国电子科技集团公司第二十八研究所 | Video real-time transmission method under fluctuating network environment |
CN109803167A (en) * | 2017-11-17 | 2019-05-24 | 中国电信股份有限公司 | Stream media document transmission method, streaming media clients and computer readable storage medium |
CN108307248B (en) * | 2018-02-01 | 2019-10-29 | 腾讯科技(深圳)有限公司 | Video broadcasting method, calculates equipment and storage medium at device |
US11356739B2 (en) | 2018-02-01 | 2022-06-07 | Tencent Technology (Shenzhen) Company Ltd | Video playback method, terminal apparatus, and storage medium |
WO2019149066A1 (en) * | 2018-02-01 | 2019-08-08 | 腾讯科技(深圳)有限公司 | Video playback method, terminal apparatus, and storage medium |
CN108307248A (en) * | 2018-02-01 | 2018-07-20 | 腾讯科技(深圳)有限公司 | Video broadcasting method, device, computing device and storage medium |
CN109361756A (en) * | 2018-11-08 | 2019-02-19 | 重庆急视飞救科技发展有限公司 | Cross-platform data transmission method based on 120 network alarmings |
WO2020151399A1 (en) * | 2019-01-23 | 2020-07-30 | 上海哔哩哔哩科技有限公司 | Method and device for pseudo-seamless switching between different video sources played by web and medium |
US11589119B2 (en) | 2019-01-23 | 2023-02-21 | Shanghai Bilibili Technology Co., Ltd. | Pseudo seamless switching method, device and media for web playing different video sources |
CN110087110B (en) * | 2019-06-12 | 2021-03-30 | 深圳市大数据研究院 | Method and device for dynamically regulating and controlling video playing by applying deep search |
CN110087110A (en) * | 2019-06-12 | 2019-08-02 | 深圳市大数据研究院 | Using the method and device of deep search dynamic regulation video playing |
CN113948054A (en) * | 2020-07-15 | 2022-01-18 | 北京破壁者科技有限公司 | Audio track processing method, device, electronic equipment and storage medium |
CN111866433A (en) * | 2020-07-31 | 2020-10-30 | 腾讯科技(深圳)有限公司 | Video source switching method, video source playing method, video source switching device, video source playing device, video source equipment and storage medium |
CN113721908A (en) * | 2021-08-30 | 2021-11-30 | 湖南快乐阳光互动娱乐传媒有限公司 | Infinite cascade assembly rendering method and device |
CN113721908B (en) * | 2021-08-30 | 2024-03-22 | 湖南快乐阳光互动娱乐传媒有限公司 | Unlimited cascade component rendering method and device |
CN114025211A (en) * | 2021-10-27 | 2022-02-08 | 福建野小兽健康科技有限公司 | Video issuing method and system adaptive to user equipment |
Also Published As
Publication number | Publication date |
---|---|
CN104967884B (en) | 2018-01-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104967884B (en) | A kind of bitstreams switching method and apparatus | |
US20230209049A1 (en) | Systems and Methods for Encoding Alternative Streams of Video for Use in Adaptive Bitrate Streaming | |
US10623785B2 (en) | Streaming manifest quality control | |
EP3022884B1 (en) | Quality optimization with buffer and horizon constraints in adaptive streaming | |
CN106537923B (en) | The technology of adaptive video stream | |
US9571827B2 (en) | Techniques for adaptive video streaming | |
KR101716071B1 (en) | Adaptive streaming techniques | |
US9313529B2 (en) | Video streaming | |
CN109302623B (en) | QoE model-based dynamic adaptive video transmission method | |
US10827181B1 (en) | Differential adaptive bitrate streaming based on scene complexity | |
Zahran et al. | OSCAR: An optimized stall-cautious adaptive bitrate streaming algorithm for mobile networks | |
US20160269462A1 (en) | Adaptive real-time transcoding method and streaming server therefor | |
US9313243B2 (en) | Video streaming over data networks | |
US9571871B2 (en) | Method for delivering video content encoded at one or more quality levels over a data network | |
CN108989838B (en) | DASH code rate self-adaption method based on video content complexity perception | |
EP3902275A1 (en) | A method for estimating bandwidth between a video server and a video client | |
Xie et al. | A Quality-driven Bit Rate Adaptation Method for Dynamic Adaptive Streaming over HTTP |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |