Efficient collaboration method for video data
By analyzing the packet loss rate and bandwidth information in RTCP packets, dynamically adjusting the code rate of the video file and switching the video file, the video quality problems caused by bandwidth changes in VoLTE video calls are solved, and the user experience is significantly improved.
Patent Information
- Application Number
- CN202411834231.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-13
- Publication Date
- 2025-04-18
AI Technical Summary
In VoLTE video call scenarios, due to the continuous changes in the mobile phone signal quality and downlink bandwidth of the called user, the fixed bandwidth transmission of video collaborative data may cause audio and video loss, lag, or unclear video, which will affect the user experience.
By analyzing the packet loss rate and TMMBR fields in the RTCP packet, the packet loss rate and bandwidth are smoothed, the appropriate bit rate video file is dynamically selected, and the bit rate is switched when necessary, and the video stream is sent to the called mobile phone. If there is a frame drop but the time to switch the video file is not reached, then retransmit it by searching for the corresponding missing frames by jitter buffer.
It realizes the playback of high-code rate videos when the downlink bandwidth of the mobile phone is high, and the playback of low-code rate videos when the mobile phone is low, which significantly improves the user experience and is suitable for business users' advertising delivery and business promotion in operator video collaboration scenarios.
Smart Images

Figure CN119854435A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of video communication, and in particular relates to an efficient collaboration method for video data. Background Art
[0002] In VoLTE video call scenarios, the voice call platform often needs to convert static data files such as PPT / WORD / PDF into data videos to help enterprise users achieve data video collaboration, such as Figure 1 In the asymmetric audio and video data collaboration scenario shown, the voice call platform transmits the company's external publicity information to the called user in the form of video.
[0003] However, the signal quality of the called user's mobile phone is constantly changing, so the downlink bandwidth on the mobile phone side is also constantly changing, especially when the user's mobile phone is constantly moving, the downlink bandwidth will change more frequently. If the calling platform sends video collaboration data to the user's mobile phone with a fixed bandwidth, there will be problems such as audio and video frame loss, freeze or unclear video, which will affect the user experience. Summary of the invention
[0004] The technical problem to be solved by the present invention is to address the deficiencies of the above-mentioned prior art and to provide an efficient collaboration method for video data. During video collaboration, a video file with a suitable bit rate is dynamically selected according to the packet loss rate and bandwidth information. High-bit rate videos can be played when the mobile phone has high bandwidth, and low-bit rate videos can be played when the bit rate is low, thereby ultimately improving the user experience.
[0005] In order to achieve the above technical objectives, the technical solution adopted by the present invention is:
[0006] An efficient collaborative method for video data analyzes the packet loss rate and TMMBR fields in the RTCP message, smoothes the packet loss rate and bandwidth respectively, selects a video file with a corresponding bit rate based on the packet loss rate and bandwidth results, switches to the video file with the corresponding bit rate, and finally sends the video stream to the called mobile phone; if there is frame loss but the time to switch the video file is not reached, the jitter buffer is used to find the corresponding lost frame for retransmission.
[0007] To optimize the above technical solutions, the specific measures taken also include:
[0008] The above method specifically includes:
[0009] Preset video files with different bit rates;
[0010] Parse RTCP packets and process LOSS, NACK, and TMMBR type packets respectively;
[0011] For LOSS type packets, the bit rate adjustment trend for the next period is selected based on the statistics of the smoothed packet loss rate.
[0012] For TMMBR type messages, the bit rate adjustment trend of the next period is selected based on the smooth prediction of TMMBR;
[0013] According to the result of the bit rate adjustment trend selection, the bit rate of the next cycle is set, the video file with the corresponding bit rate is selected, and the video file with the corresponding bit rate is switched to, and finally the video stream is sent to the called mobile phone;
[0014] For NACK type messages, read the corresponding frame in the jitter buffer and resend it.
[0015] For the above LOSS type messages, based on the statistics of the smoothed packet loss rate, the bit rate adjustment trend of the next period is selected, including:
[0016] 1) For LOSS type messages, the packet loss rate is calculated as the value of the fraction lost field in the RTCP receiver report / 256*100%;
[0017] 2) Smooth packet loss rate prediction through Kalman.
[0018] 3) Determine the packet loss rate interval. If the packet loss rate is greater than or equal to 10%, the bit rate reduction count dec_lost_cnt is increased by 1. If the packet loss rate is greater than 1% and less than 10%, the bit rate retention count keep_lost_cnt is increased by 1. If the packet loss rate is less than or equal to 1%, the bit rate increase count inc_lost_cnt is increased by 1.
[0019] 4) Compare dec_lost_cnt*w1, keep_lost_cnt*w2, and inc_lost_cnt*w3, and select the bit rate adjustment trend corresponding to the maximum value of the three, where w1, w2, and w3 are the bit rate increase weight, bit rate maintenance weight, and bit rate reduction weight, respectively.
[0020] The above w1, w2, and w3 are 3, 2, and 1 / 2 respectively.
[0021] For the TMMBR type message, the bit rate adjustment trend of the next period is selected according to the smooth prediction of TMMBR, including:
[0022] 1) For TMMBR type messages, record the parsed TMMBR bandwidth data;
[0023] 2) Using the Kalman prediction algorithm, the smoothed prediction value of TMMBR is obtained;
[0024] 3) Compare the smoothed predicted value of TMMBR with the TMMBR value recorded last time, and adjust the bit rate increase weight w1, bit rate retention weight w2, and bit rate reduction weight w3 according to the comparison result;
[0025] 4) Compare dec_lost_cnt*w1, keep_lost_cnt*w2, and inc_lost_cnt*w3, and select the rate adjustment trend corresponding to the maximum value of the three, where dec_lost_cnt, keep_lost_cnt, and inc_lost_cnt are the rate reduction count, the rate retention count, and the rate increase count, respectively.
[0026] In the above 3), if the value becomes larger, the bit rate increase weight w1 is adjusted to 1.1; if the value remains unchanged, the bit rate retention weight w2 is adjusted to 1.1; if the value becomes smaller, the bit rate reduction weight w3 is adjusted to 1.1, where the initial values of w1, w2, and w3 are 3, 2, and 1 / 2, respectively.
[0027] In the above 3), the smoothed predicted value of TMMBR is compared with the TMMBR value recorded last time. If the deviation exceeds + / -10%, the bit rate increase or bit rate decrease adjustment trend is selected.
[0028] The statistical method of dec_lost_cnt, keep_lost_cnt, and inc_lost_cnt in 4) above is:
[0029] In a statistical period, if the packet loss rate is greater than or equal to 10%, the bit rate reduction count dec_lost_cnt is increased by 1; if the packet loss rate is greater than 1% and less than 10%, the bit rate retention count keep_lost_cnt is increased by 1; if the packet loss rate is less than or equal to 1%, the bit rate increase count inc_lost_cnt is increased by 1.
[0030] The video playback process is as follows:
[0031] 1) Set the initial bit rate and the initial index to 1;
[0032] 2) Read the video file with the corresponding bit rate;
[0033] 3) Record the index number;
[0034] 4) Read the frame and save it to the jitter buffer;
[0035] 5) Read the first frame from the jitter buffer and send it out;
[0036] 6) Repeat 4) until the video file is played completely;
[0037] 7) Index number + 1, repeat 2).
[0038] The present invention has the following beneficial effects:
[0039] The present invention introduces a Kalman filter algorithm to smooth the packet loss rate and the receiving end bandwidth respectively, selects the corresponding bit rate video file according to the smoothed predicted packet loss rate and bandwidth value and plays it to the called mobile phone, can play high bit rate video when the mobile phone downlink bandwidth is high, and play low bit rate video when the bit rate is low, thereby significantly improving the user experience.
[0040] The present invention can be applied to operator video collaboration scenarios to implement services such as enterprise user advertising and business promotion. BRIEF DESCRIPTION OF THE DRAWINGS
[0041] Figure 1 It is a schematic diagram of asymmetric audio and video data collaboration;
[0042] Figure 2 It is the measured value of the downlink bandwidth of the called mobile phone;
[0043] Figure 3 Bandwidth statistics are sent at a fixed bit rate of 600kbps;
[0044] Figure 4 This is the bit rate adjustment and playback effect diagram;
[0045] Figure 5 Describe the diagram for the basic scheme;
[0046] Figure 6 Automatic adjustment flow chart for frame loss and bit rate;
[0047] Figure 7 Compare the bandwidth reported by TMMBR with the predicted value. DETAILED DESCRIPTION
[0048] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.
[0049] Although the steps in the present invention are arranged with numbers, they are not used to limit the order of the steps. Unless the order of the steps is clearly stated or the execution of a certain step requires other steps as a basis, the relative order of the steps can be adjusted. It is understood that the term "and / or" used in this article involves and covers any and all possible combinations of one or more of the associated listed items.
[0050] The invention discloses an efficient collaborative method for video data. The method analyzes the packet loss rate and TMMBR field in the RTCP message, respectively smoothes the packet loss rate and bandwidth, selects a video file with a corresponding bit rate based on the packet loss rate and bandwidth result, switches to the video file with the corresponding bit rate, and finally sends the video stream to the called mobile phone. If there is frame loss but the time for switching the video file is not reached, the jitter buffer is used to find the corresponding lost frame for retransmission.
[0051] In specific implementation, the called mobile phone will continue to report bandwidth information and packet loss rate information through RTCP TMMBR during video reception. Figure 2 As shown in Figure 2, during the movement of the mobile phone, the downlink bandwidth fluctuates from 330kbps to 860kbps, especially in the first half ( Figure 2 The first 85 seconds) of the video are very jittery due to the frequent movement of the mobile phone; the second half ( Figure 2 85 seconds after the call), after the mobile phone stays at a fixed position, the bandwidth basically remains stable at around 330kbps. In view of the changes in signal quality and mobile phone bandwidth, if the video stream is pushed to the called mobile phone at a constant rate, in order to minimize the jamming and frame loss, only a low bit rate can be selected to transmit the video, such as 300kbps, but the cost is the sacrifice of picture quality and user experience. Transmitting video at a constant high bit rate, such as 600kbps, will cause frame loss and jamming, such as in the second half, when the bandwidth is 330kbps, it will be more serious. Therefore, it is necessary to dynamically adjust the bit rate of sending the video according to the bandwidth and packet loss rate. Different from ordinary real-time video call scenarios, the video collaboration platform plays video files or video clips to the receiving mobile phone, and it is not suitable to switch the bit rate frequently. In this scenario, it is more suitable to use a relatively fixed period (such as 10s) to determine whether to switch the bit rate, and switch or maintain the bit rate when playing the next video clip.
[0052] The bitrate adjustment determination algorithm and the logic of switching video files based on the bitrate determination results become the two key points of bitrate adjustment in video collaboration scenarios.
[0053] The bitrate adjustment decision algorithm cannot be simply determined by the RTCP TMMBR reporting result, because when the bitrate sent to the receiving side is too high, the packet loss retransmission amount is large, and the TMMBR value will become smaller, so it cannot actually reflect the actual bandwidth level. It is necessary to combine the packet loss rate to determine whether the bitrate of the next slice should be increased, decreased, or maintained unchanged. Assuming that the bitrate of the next 10 seconds is determined with a statistical cycle of 10 seconds, there will be a variety of statistical result jitters, such as the previous second is considered to increase the bitrate, and the next second is considered to decrease or maintain the bitrate unchanged.
[0054] The algorithm of the present invention evaluates the matching of bit rate and bandwidth based on the packet loss rate:
[0055] - If the packet loss rate is greater than 10%, count once and reduce the bitrate statistics;
[0056] - If the packet loss rate is greater than 1% and less than 10%, it is counted once to maintain the bit rate statistics;
[0057] -If the packet loss rate is less than 1%, it is counted once to improve the bit rate statistics;
[0058] The number of statistics reflects the matching of the sending bandwidth and the receiving status. In a statistical cycle, especially when at the bandwidth boundary, there will be three statistical values that are not much different or close. In line with the principle of maintaining the bit rate stable as much as possible, reducing the bit rate quickly, and increasing the bit rate cautiously, it is necessary to adjust the weight value based on the experimental data and the Kalman prediction trend of the TMMBR value, assign corresponding weight values to the three statistical values, and obtain a bit rate adjustment count:
[0059] -TMMBR prediction result is better than last time, bitrate increase weight is multiplied by 1.1;
[0060] -TMMBR prediction result is lower than last time, and the bitrate reduction weight is multiplied by 1.1;
[0061] -TMMBR prediction results remain the same as last time, and the bitrate remains weighted by 1.1;
[0062] At the end of the statistical cycle, the three statistical values are compared. The maximum value reflects the stage trend, so as to determine the bit rate adjustment direction for the next cycle: maintain, increase, or decrease. There are not too many preset file bit rates. You can use 300k, 600k, 900k, 1200k, etc. Therefore, the increase or decrease of the bit rate is limited to the supported fixed bit rates. The statistical results of the 600kbps fixed bit rate transmission bandwidth are as follows: Figure 3 shown.
[0063] The logic of video file switching is relatively simple. In this application, the file name of the corresponding bit rate is generated according to the bit rate adjustment result. In the next cycle, the newly specified video file segment is opened and played and pushed to the called party's mobile phone. The final result is similar to Figure 4 shown.
[0064] The present invention proposes to pre-set video files with different bit rates, and dynamically select corresponding video file segments to play to the called mobile phone according to the packet loss rate and bandwidth changes, so as to play high-bit rate videos when the mobile phone has high bandwidth, and play low-bit rate videos when the mobile phone has low bit rate, thereby significantly improving the user experience.
[0065] like Figure 5As shown in the figure, the solution is based on analyzing the packet loss rate and TMMBR field in the RTCP message, smoothing the packet loss rate and bandwidth respectively, selecting the video file with the corresponding bit rate according to the packet loss rate statistics and bandwidth results, switching to the video file with the corresponding bit rate, and finally sending the video stream to the called mobile phone; if the threshold for switching the video file is not reached, but there is frame loss, the jitter buffer is used to find the corresponding lost frame and retransmit it to solve the problem of partial frame loss. The final result is smooth switching or retransmission of video frames to achieve clear and smooth playback of video files.
[0066] In the embodiment, the core process of frame loss and bit rate adjustment Figure 6 shown.
[0067] The video playback process is as follows:
[0068] 1. Set the initial bit rate and the initial index to 1;
[0069] 2. Read the video file with the corresponding bit rate;
[0070] 3. Record index number;
[0071] 4. Read the frame and save it to the jitter buffer;
[0072] 5. Read the first frame from the jitter buffer and send it out;
[0073] 6. Repeat 4 until the video file is finished playing;
[0074] 7. Index number +1, repeat 2.
[0075] The RTCP processing process is as follows:
[0076] 1. Parse RTCP packets and process LOSS / NACK / TMMBR type packets respectively;
[0077] 2. If it is LOSS, the packet loss rate is calculated as the fraction lost field value in the RTCP receiver report / 256*100% to get the percentage rate;
[0078] 3. The packet loss rate reported by RTCP is relatively random and cannot be used directly as a trend judgment. It needs to be smoothed through Kalman packet loss rate prediction.
[0079] 4. Determine the packet loss rate range. If the packet loss rate is greater than 10%, the bit rate reduction count is increased by 1 (dec_lost_cnt++); if the packet loss rate is greater than 1% and less than 10%, the bit rate retention count is increased by 1 (keep_lost_cnt++); if the packet loss rate is less than 1%, the bit rate increase count is increased by 1 (inc_lost_cnt++);
[0080] 5. Trend judgment, compare the relationship between the three values in step 4, based on the principle of maintaining the bit rate stable as much as possible, reducing the bit rate quickly, and increasing the bit rate cautiously, dec_lost_cnt*3, keep_lost_cnt*2, inc_lost_cnt / 2, the largest of the three values represents the corresponding trend, for example, if dec_lost_cnt*3 is the largest, the bit rate should be reduced, if keep_lost_cnt*2 is the largest, the bit rate should be kept unchanged, and if inc_lost_cnt / 2 is the largest, the bit rate should be increased;
[0081] 6. According to the trend judgment results, set the bit rate for the next cycle;
[0082] 7. If it is NACK, read the corresponding frame in the jitter buffer and resend it;
[0083] 8. If it is TMMBR, record the parsed TMMBR bandwidth data;
[0084] 9. Use the Kalman prediction algorithm to obtain the smoothed prediction value of TMMBR;
[0085] 10. Compare with the TMMBR value recorded last time. If the value becomes larger, the bit rate is increased and the weight is adjusted (inc_lost_cnt*1.1). Otherwise, the bit rate is reduced and the weight is adjusted (dec_lost_cnt*1.1).
[0086] 11. If the deviation exceeds a threshold, such as + / -10%, the bit rate is adjusted upward or downward.
[0087] Based on the above analysis, the method of the present invention specifically includes:
[0088] Preset video files with different bit rates;
[0089] Parse RTCP packets and process LOSS, NACK, and TMMBR type packets respectively;
[0090] For LOSS type packets, the bit rate adjustment trend for the next period is selected based on the statistics of the smoothed packet loss rate.
[0091] For TMMBR type messages, the bit rate adjustment trend of the next period is selected based on the smooth prediction of TMMBR;
[0092] According to the result of the bit rate adjustment trend selection, the bit rate of the next cycle is set, the video file with the corresponding bit rate is selected, and the video file with the corresponding bit rate is switched to, and finally the video stream is sent to the called mobile phone;
[0093] For NACK type messages, read the corresponding frame in the jitter buffer and resend it.
[0094] In the embodiment, for LOSS type messages, selecting the bit rate adjustment trend of the next period based on the statistics of the smoothed packet loss rate includes:
[0095] 1) For LOSS type messages, the packet loss rate is calculated as the value of the fraction lost field in the RTCP receiver report / 256*100%;
[0096] 2) Smooth packet loss rate prediction through Kalman.
[0097] 3) Determine the packet loss rate interval. If the packet loss rate is greater than or equal to 10%, the bit rate reduction count dec_lost_cnt is increased by 1. If the packet loss rate is greater than 1% and less than 10%, the bit rate retention count keep_lost_cnt is increased by 1. If the packet loss rate is less than or equal to 1%, the bit rate increase count inc_lost_cnt is increased by 1.
[0098] 4) Compare dec_lost_cnt*w1, keep_lost_cnt*w2, and inc_lost_cnt*w3, and select the bit rate adjustment trend corresponding to the maximum value of the three, where w1, w2, and w3 are the bit rate increase weight, bit rate maintenance weight, and bit rate reduction weight, respectively.
[0099] In the embodiment, w1, w2, and w3 are 3, 2, and 1 / 2 respectively.
[0100] In the embodiment, for the TMMBR type message, selecting the bit rate adjustment trend of the next period according to the smooth prediction of the TMMBR includes:
[0101] 1) For TMMBR type messages, record the parsed TMMBR bandwidth data;
[0102] 2) Using the Kalman prediction algorithm, the smoothed prediction value of TMMBR is obtained;
[0103] 3) Compare the smoothed predicted value of TMMBR with the TMMBR value recorded last time, and adjust the bit rate increase weight w1, bit rate retention weight w2, and bit rate reduction weight w3 according to the comparison result;
[0104] 4) Compare dec_lost_cnt*w1, keep_lost_cnt*w2, and inc_lost_cnt*w3, and select the rate adjustment trend corresponding to the maximum value of the three, where dec_lost_cnt, keep_lost_cnt, and inc_lost_cnt are the rate reduction count, the rate retention count, and the rate increase count, respectively.
[0105] In the embodiment, in 3), if the value becomes larger, the bit rate increase weight w1 is adjusted to 1.1; if the value remains unchanged, the bit rate retention weight w2 is adjusted to 1.1; if the value becomes smaller, the bit rate reduction weight w3 is adjusted to 1.1, where the initial values of w1, w2, and w3 are 3, 2, and 1 / 2, respectively.
[0106] In the embodiment, in 3), the smoothed prediction value of TMMBR is compared with the TMMBR value recorded last time, and if the deviation exceeds + / -10%, the bit rate increase or bit rate decrease adjustment trend is selected.
[0107] In the embodiment, the statistical method of dec_lost_cnt, keep_lost_cnt and inc_lost_cnt in 4) is:
[0108] In a statistical period, if the packet loss rate is greater than or equal to 10%, the bit rate reduction count dec_lost_cnt is increased by 1; if the packet loss rate is greater than 1% and less than 10%, the bit rate retention count keep_lost_cnt is increased by 1; if the packet loss rate is less than or equal to 1%, the bit rate increase count inc_lost_cnt is increased by 1.
[0109] like Figure 7 As shown in the figure, the solid line is the analytical value curve of the TMMBR field in the RTCP message, and the dotted line is the bandwidth curve that is continuously predicted based on the TMMBR field in the RTCP message. Compared with the actual reported value, it is smoother and has a smaller jitter amplitude. Figure 7 As shown, after comparing the two predicted values, if the value becomes larger, the weight of the bit rate increase is increased by 10%, otherwise, the weight of the bit rate decrease is increased by 10%.
[0110] The above terms are explained as follows:
[0111] VoLTE (Voice over LTE): A 4G IP transmission technology that allows high-definition audio and video calls on 4G networks;
[0112] SIP (Session Initiation Protocol): Session Initiation Protocol;
[0113] RTP (Real-Time Transport Protocol): Real-time Transport Protocol;
[0114] RTCP (Real-Time Transport Control Protocol): Real-time Transport Control Protocol;
[0115] NACK: packet loss retransmission message in RTCP;
[0116] TMMBR: RTCP flow control field, used to specify the maximum bit rate;
[0117] Jitter buffer: Jitter buffer, usually used to handle audio and video jitter.
[0118] It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above and that the invention can be implemented in other specific forms without departing from the spirit or essential features of the invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description, and it is intended that all variations falling within the meaning and range of equivalent elements of the claims be included in the invention. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.
[0119] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.
Claims
1. An efficient collaborative method for video data, characterized in that: By analyzing the packet loss rate and TMMBR fields in the RTCP message, the packet loss rate and bandwidth are smoothed respectively, and then the video file with the corresponding bit rate is selected based on the packet loss rate and bandwidth results, and the video file with the corresponding bit rate is switched to finally send the video stream to the called mobile phone; if there is frame loss but the time to switch the video file has not come, the jitter buffer is used to find the corresponding lost frame for retransmission.
2. The efficient collaborative method for video data according to claim 1, characterized in that: The method specifically comprises: Preset video files with different bit rates; Parse RTCP packets and process LOSS, NACK, and TMMBR type packets respectively; For LOSS type packets, the bit rate adjustment trend for the next period is selected based on the statistics of the smoothed packet loss rate. For TMMBR type messages, the bit rate adjustment trend of the next period is selected based on the smooth prediction of TMMBR; According to the result of the bit rate adjustment trend selection, the bit rate of the next cycle is set, the video file with the corresponding bit rate is selected, and the video file with the corresponding bit rate is switched to, and finally the video stream is sent to the called mobile phone; For NACK type messages, read the corresponding frame in the jitter buffer and resend it.
3. The efficient collaborative method for video data according to claim 1, characterized in that: For LOSS type messages, the bit rate adjustment trend of the next period is selected based on the statistics of the smoothed packet loss rate, including: 1) For LOSS type messages, calculate the packet loss rate; 2) Smooth packet loss rate prediction through Kalman. 3) Determine the packet loss rate interval. If the packet loss rate is greater than or equal to 10%, the bit rate reduction count dec_lost_cnt is increased by 1. If the packet loss rate is greater than 1% and less than 10%, the bit rate retention count keep_lost_cnt is increased by 1. If the packet loss rate is less than or equal to 1%, the bit rate increase count inc_lost_cnt is increased by 1. 4) Compare dec_lost_cnt*w1, keep_lost_cnt*w2, and inc_lost_cnt*w3, and select the bit rate adjustment trend corresponding to the maximum value of the three, where w1, w2, and w3 are the bit rate increase weight, bit rate maintenance weight, and bit rate reduction weight, respectively.
4. The efficient video data collaboration method according to claim 3, characterized in that: The packet loss rate is the value range of the fraction lost field in the RTCP receiver report / 256*100%.
5. The efficient video data collaboration method according to claim 3, characterized in that: The w1, w2, and w3 are 3, 2, and 1 / 2 respectively.
6. The efficient video data collaboration method according to claim 1, characterized in that: For the TMMBR type message, selecting the bit rate adjustment trend of the next period according to the smooth prediction of TMMBR includes: 1) For TMMBR type messages, record the parsed TMMBR bandwidth data; 2) Using the Kalman prediction algorithm, the smoothed prediction value of TMMBR is obtained; 3) Compare the smoothed predicted value of TMMBR with the TMMBR value recorded last time, and adjust the bit rate increase weight w1, bit rate retention weight w2, and bit rate reduction weight w3 according to the comparison result; 4) Compare dec_lost_cnt*w1, keep_lost_cnt*w2, and inc_lost_cnt*w3, and select the rate adjustment trend corresponding to the maximum value of the three, where dec_lost_cnt, keep_lost_cnt, and inc_lost_cnt are the rate reduction count, the rate retention count, and the rate increase count, respectively.
7. The efficient video data collaboration method according to claim 6, characterized in that: In the above 3), if the value increases, the bit rate increase weight w1 is adjusted to 1.1; if the value remains unchanged, the bit rate retention weight w2 is adjusted to 1.1; if the value decreases, the bit rate reduction weight w3 is adjusted to 1.1, where the initial values of w1, w2, and w3 are 3, 2, and 1 / 2, respectively.
8. The efficient video data collaboration method according to claim 6, characterized in that: In the above 3), the smoothed predicted value of TMMBR is compared with the TMMBR value recorded last time. If the deviation exceeds + / -10%, the bit rate increase or bit rate decrease adjustment trend is selected.
9. The efficient video data collaboration method according to claim 6, characterized in that: 4) The statistical method of dec_lost_cnt, keep_lost_cnt, and inc_lost_cnt is: In a statistical period, if the packet loss rate is greater than or equal to 10%, the bit rate reduction count dec_lost_cnt is increased by 1; if the packet loss rate is greater than 1% and less than 10%, the bit rate retention count keep_lost_cnt is increased by 1; if the packet loss rate is less than or equal to 1%, the bit rate increase count inc_lost_cnt is increased by 1.
10. The efficient video data collaboration method according to claim 1, characterized in that: The video playback process is as follows: 1) Set the initial bit rate and the initial index to 1; 2) Read the video file with the corresponding bit rate; 3) Record the index number; 4) Read the frame and save it to the jitter buffer; 5) Read the first frame from the jitter buffer and send it out; 6) Repeat 4) until the video file is played completely; 7) Index number + 1, repeat 2).
Citation Information
Patent Citations
Method for dynamic network state adaptation of video stream
CN105471865A
Video call code rate adjustment method and device based on VoLTE (Voice & Video over Long Term Evolution) and a mobile terminal.
CN106937073A
Realization method and device of multipath video conversation and multipass terminal
CN108206925A
Unmanned ship video transmission system and method under network resource limitation
CN118678166A
QoS (Quality of Service) comprehensive processing method of video conference system
CN118945147A