Android video self-adaptive secondary transcoding method and system and medium

Abstract

The invention discloses an Android video self-adaptive secondary transcoding method and system and a medium, mainly relates to the technical field of secondary transcoding, and is used for solving the problem that part of videos cannot be played on some Android devices due to a transcoding mode in an existing scheme. Or the video playing experience is difficult to comprehensively optimize due to the fact that the video playing experience cannot be comprehensively optimized due to the fact that the video playing experience is not combined with the real-time feedback in the playing process. Comprising the steps that when it is determined that a playing report error occurs and the error indicates that the coding format is incompatible, the format with the highest priority in the coding formats supported by equipment is selected from a coding list contained in software parameters to serve as the final coding format, and secondary transcoding is conducted according to the final coding format; triggering a screen resolution and code rate down-regulation program when lagging occurs, a playing error occurs, the error is not incompatible in coding format or playing stagnation occurs, and the CPU load in the hardware parameters is greater than a preset value; and carrying out secondary transcoding based on the down-regulated screen resolution and code rate.

Description

Technical Field

[0001] This application relates to the field of adaptive secondary transcoding technology, and in particular to an Android video adaptive secondary transcoding method, system and medium. Background Art

[0002] With the wide popularity of Android devices, the hardware and software environments of Android devices vary greatly, and the playback effects of videos on different devices are uneven. In the prior art, video transcoding is usually performed at the video upload or distribution stage, and a one-time transcoding is performed according to preset general parameters, without considering the actual situation during the playback process of the device and the characteristics of the device itself.

[0003] This transcoding method with fixed parameters causes some videos to be unable to play on certain Android devices, or problems such as stuttering, blurred image quality, etc. occur during playback. For example, some low-configuration devices may not be able to play high-bitrate and high-resolution videos smoothly; and some devices may not be able to decode and play due to not supporting a specific video coding format. Although some technologies attempt to perform transcoding according to device information, without combining the real-time feedback during the playback process, it is difficult to comprehensively optimize the video playback experience. Summary of the Invention

[0004] This application provides an Android video adaptive secondary transcoding method, system and medium to solve the problems that the transcoding method in the existing solution causes some videos to be unable to play on certain Android devices, or problems such as stuttering, blurred image quality, unable to decode and play, without combining the real-time feedback during the playback process, and it is difficult to comprehensively optimize the video playback experience.

[0005] In a first aspect, this application provides an Android video adaptive secondary transcoding method, and the method includes: Obtain the current actual playback frame rate in real time to determine whether stuttering occurs during the current playback; listen to the error callback information of the player in real time to determine whether a playback error occurs; obtain the current playback progress regularly to determine whether playback stagnation occurs; obtain the hardware parameters, software parameters and screen resolution of the playback device; when it is determined that a playback error occurs and the error is an incompatible encoding format, select the highest-priority format among the encoding formats supported by the device from the encoding list included in the software parameters as the final encoding format, and perform secondary transcoding according to the final encoding format; when stuttering occurs, a playback error occurs and the error is not an incompatible encoding format, or playback stagnation occurs, and when the CPU load in the hardware parameters is greater than a preset value, trigger a screen resolution and bitrate reduction program; perform secondary transcoding based on the reduced screen resolution and bitrate.

[0006] In an implementation manner of this application, obtaining the current actual playback frame rate in real time to determine whether stuttering occurs during the current playback specifically includes: In the player rendering thread, the actual playback frame rate is calculated by recording the timestamps of two consecutive frames. When the frame rate is lower than the preset frame threshold within a continuous preset time interval, it is determined that the current playback has a lag. Among them, the formula for calculating the actual playback frame rate is: frame rate = 1 / the interval time between two consecutive frames.

[0007] In an implementation manner of this application, the error callback information of the player is monitored in real time to determine whether a playback error occurs; the current playback progress is obtained regularly to determine whether there is a playback stagnation, specifically including: Monitor the error callback interface of the player in real time to capture the error callback information; among them, the error callback information includes: decoder error, encoding format incompatibility. Obtain the current playback progress regularly. When the progress increment is less than 1% of the total video duration within a continuous preset progress time period, it is determined that there is a playback stagnation.

[0008] In an implementation manner of this application, the hardware parameters at least include the CPU load and available memory, and the software parameters at least include the encoding list. Obtain the hardware parameters, software parameters and screen resolution of the playback device, specifically including: Use android.system.Os to obtain the CPU load; obtain the available memory through ActivityManager.MemoryInfo; Traverse MediaCodecList.getCodecInfoList() of the playback device to obtain the video encoding formats supported by the playback device and add them to the encoding list. Obtain the screen width, height and density through DisplayMetrics to obtain the screen resolution.

[0009] In an implementation manner of this application, trigger the screen resolution and bitrate reduction program, specifically including: Reduce the screen resolution to a preset ratio of the current screen resolution to obtain the target screen resolution; Through the formula:

[0010] Calculate to obtain the .

[0011] In an implementation manner of this application, the hardware parameters include the available memory of the playback device. The method further includes: When the available memory is less than the preset memory value, reduce the buffer during the transcoding process to the preset size.

[0012] Second aspect, the present application provides an Android video adaptive secondary transcoding system, which includes: A playback feedback collection module, configured to obtain the current actual playback frame rate in real time to determine whether there is any lag in the current playback; listen to the error callback information of the player in real time to determine whether there is any playback error; obtain the current playback progress at regular intervals to determine whether there is any playback stagnation; a device information acquisition module, configured to acquire the hardware parameters, software parameters, and screen resolution of the playback device; an adaptive secondary transcoding module, configured to, when it is determined that there is a playback error and the error is an incompatible encoding format, select the highest-priority format among the encoding formats supported by the device from the encoding list included in the software parameters as the final encoding format, and perform secondary transcoding according to the final encoding format; when there is lag, there is a playback error and the error is not an incompatible encoding format, or there is playback stagnation, and when the CPU load in the hardware parameters is greater than a preset value, trigger a screen resolution and bitrate reduction program; perform secondary transcoding based on the reduced screen resolution and bitrate.

[0013] In an implementation manner of the present application, the playback feedback collection module includes a frame rate monitoring unit, configured to calculate the actual playback frame rate in the renderer thread of the player by recording the timestamps of two consecutive frames, and determine that there is lag in the current playback when the frame rate is lower than a preset frame threshold within a continuous preset time interval; wherein, the formula for calculating the actual playback frame rate is: frame rate = 1 / the interval time between two consecutive frames.

[0014] In an implementation manner of the present application, the adaptive secondary transcoding module includes a secondary transcoding calculation unit, configured to reduce the screen resolution to a preset ratio of the current screen resolution to obtain the target screen resolution; Through the formula:

[0015] Calculate to obtain the .

[0016] Third aspect, the present application provides a non-volatile computer storage medium, on which computer instructions are stored, and the computer instructions, when executed, implement an Android video adaptive secondary transcoding method as described in any one of the above.

[0017] From the above technical solutions, it can be seen that the present application has the following advantages: Dual-dimension Decision-making Mechanism: By combining real-time playback feedback (such as lag and errors) with device characteristics (hardware performance and encoding support), an adaptive transcoding strategy is constructed to break through the limitations of traditional single-device information transcoding. By real-time monitoring the playback frame rate, error callbacks, and playback progress, and combining device hardware parameters (such as CPU load) and software parameters (such as the encoding format support list), dynamic secondary transcoding is achieved. Compared with fixed-parameter transcoding, it can solve problems such as lag on low-config devices and incompatibility with high bitrates, and adapt to Android devices with different performances.

[0018] Dynamic Parameter Adjustment Algorithm: Based on parameters such as device CPU / GPU load and screen resolution, the transcoding resolution and bitrate are dynamically calculated through quantization formulas to achieve refined transcoding control. Classify and handle playback errors: If it is due to encoding format incompatibility, automatically switch to the format with the highest priority supported by the device; if it is due to insufficient performance (such as high CPU load), trigger a reduction in resolution / bitrate. The targeted strategy significantly reduces the probability of unable to play or decoding failure.

[0019] For the first time, real-time playback feedback (such as lag and stagnation) is linked with device parameters to form a "monitoring - decision - transcoding" closed loop. By continuously optimizing transcoding parameters, the picture quality clarity and smoothness are systematically improved to ensure continuous improvement of transcoding effects. Brief Description of the Drawings

[0020] In order to more clearly illustrate the technical solutions of the present invention, the drawings required to be used in the description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0021] Figure 1 It is a flowchart of an Android video adaptive secondary transcoding method provided by an embodiment of the present application.

[0022] Figure 2 It is a schematic diagram of the internal structure of an Android video adaptive secondary transcoding system provided by an embodiment of the present application. Detailed Embodiments

[0023] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0024] Those skilled in the art should understand that the embodiments described below are only the preferred embodiments of the present disclosure, and do not mean that the present disclosure can only be implemented through these preferred embodiments. These preferred embodiments are only used to explain the technical principles of the present disclosure and are not used to limit the protection scope of the present disclosure. Based on the preferred embodiments provided by the present disclosure, all other embodiments obtained by those of ordinary skill in the art without creative efforts should still fall within the protection scope of the present disclosure.

[0025] It should also be noted that the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, commodity or device. Without further limitation, the element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, commodity or device including the element.

[0026] The technical solutions proposed in the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0027] The embodiment provides an Android video adaptive secondary transcoding method. As Figure 1 shown, the method provided by the embodiment of the present application mainly includes the following steps: Step 110: Obtain the current actual playback frame rate in real time to determine whether there is stuttering in the current playback; listen to the error callback information of the player in real time to determine whether there is a playback error; obtain the current playback progress at regular intervals to determine whether there is a playback stagnation.

[0028] In some embodiments, obtaining the current actual playback frame rate in real time to determine whether there is stuttering in the current playback specifically includes: in the player rendering thread, calculate the actual playback frame rate by recording the timestamps of two consecutive frames. When the frame rate is lower than the preset frame threshold within a continuous preset time interval, it is determined that there is stuttering in the current playback; wherein, the formula for calculating the actual playback frame rate is: frame rate = 1 / the interval time between two consecutive frames.

[0029] Specifically, set a preset frame threshold (such as 25fps). When the frame rate is lower than the threshold within 5 seconds (the preset frame threshold) continuously, it is determined as "stuttering" and a feedback record is triggered.

[0030] Listening to the error callback information of the player in real time to determine whether there is a playback error; obtaining the current playback progress at regular intervals to determine whether there is a playback stagnation specifically includes: Listen to the error callback interface of the player in real time and capture the error callback information; wherein, the error callback information includes: decoder error, encoding format incompatibility.

[0031] As an example, listen to the error callback interface of the player (such as MediaPlayer.OnErrorListener), capture exception codes such as decoder errors (such as ERROR_DECODE) and format unsupported errors (such as ERROR_UNSUPPORTED), and record the error type and occurrence time.

[0032] Regularly obtain the current playback progress. When the progress increment is less than 1% of the total video duration within a preset continuous progress time period, it is determined that playback stagnation has occurred.

[0033] As an example, regularly obtain the current playback progress. If the progress increment is less than 1% of the total video duration for 10 consecutive seconds, it is determined as "playback stagnation" and marked as an abnormal state.

[0034] Those skilled in the art can understand that in this step, the actual frame rate is dynamically calculated through the frame interval time. Combining the 5-second continuous monitoring mechanism with a threshold of 25fps can identify abnormal picture smoothness. For example, when the frame rate drops to 20fps due to network fluctuations, the system can immediately trigger an alarm and record the timestamp, helping developers quickly locate the stuck time period. Compared with the traditional subjective evaluation method, this quantitative method makes the optimization direction clearer.

[0035] In this step, decoding errors (ERROR_DECODE) and format exceptions (ERROR_UNSUPPORTED) are captured by listening to interfaces such as MediaPlayer.OnErrorListener, and a mapping relationship between the error code and the occurrence time is established. This mechanism enables the player, when encountering encoding compatibility issues, not only to automatically interrupt the abnormal stream to avoid crashing, but also to generate a diagnostic report containing the error type.

[0036] This step adopts the progress increment analysis method (triggered when the progress change within 10 seconds < 1% of the total duration), which effectively distinguishes between active user pauses and system abnormal stagnation. For example, when a CDN node fails and causes buffer failure, this technology can accurately identify and switch to an alternative source to avoid the "false death" state.

[0037] Step 120: Obtain the hardware parameters, software parameters, and screen resolution of the playback device.

[0038] It should be noted that the acquisition of hardware parameters can be specifically as follows: CPU information: Obtain the CPU model through android.os.Build, read the / proc / cpuinfo file to parse the number of cores and architecture; use android.system.Os to obtain the CPU load (such as the average load in the last 1 minute). GPU performance: Obtain the OpenGLES version supported by the GPU through System.getProperty("ro.opengles.version"), and evaluate the graphics processing ability in combination with the manufacturer-specific API (such as the qcom.sensors.gpu node of AdrenoGPU). Memory size: Obtain the available memory and total memory through ActivityManager.MemoryInfo to determine whether the device's memory resources are sufficient.

[0039] The acquisition of software parameters can be specifically as follows: System version: Read Build.VERSION.SDK_INT and Build.VERSION.RELEASE to determine the Android system compatibility. Supported encoding formats: Traverse MediaCodecList.getCodecInfoList() to obtain the video encoding formats supported by the device (such as H.264, H.265, etc.) and their corresponding profiles.

[0040] The screen resolution can be specifically as follows: Obtain the screen width, height, and density through DisplayMetrics, and calculate the optimal display resolution (such as matching the aspect ratio of the video display area).

[0041] Those skilled in the art can understand that through parsing the CPU model (such as Snapdragon 888), the number of cores, and the real-time load (the average load in 1 minute ≤ 1.5 is regarded as normal) in this step, the decoding thread allocation strategy can be dynamically adjusted. For example, when it is detected that the 4-core CPU load reaches 80%, it automatically downgrades to 720P playback to avoid stuttering. The detection of the GPU OpenGL ES version (such as the 3.2 version supports Vulkan rendering) combined with the manufacturer API call can intelligently select the graphics acceleration scheme.

[0042] The system version detection (SDK_INT ≥ 26 is determined as Android 8.0+) and encoding format traversal (such as the supportability check of H.265 Main Profile) involved in this step can pre-avoid format incompatibility problems.

[0043] Step 130: When it is determined that a playback error occurs and the error is encoding format incompatibility, select the format with the highest priority from the encoding list included in the software parameters that is supported by the device as the final encoding format, and perform secondary transcoding according to the final encoding format.

[0044] As an example, if the device does not support the current video encoding format (for example, the device only supports H.264 while the video is H.265), select the format with the highest priority from the encoding formats supported by the device from the device's supported encoding list (priority order: H.264 High Profile > H.264 Baseline Profile).

[0045] Those skilled in the art can understand that in this step, when detecting incompatibility of new encodings such as H.265 (verified through MediaCodecList), the system automatically downgrades to H.264 High Profile supported by the device (with a higher priority than Baseline Profile). In this step, by pre-generating multi-version transcoding plans (such as H.264 High / Baseline Profile, VP9, etc.), the user cannot perceive the compatibility switching process.

[0046] Step 140: When there is stuttering, a playback error occurs and the error is not an encoding format incompatibility, or when playback stalls, and when the CPU load in the hardware parameters is greater than the preset value, trigger the screen resolution and bitrate downscaling program; perform secondary transcoding based on the downscaled screen resolution and bitrate.

[0047] As an example, if stuttering is detected and the CPU load > 80%, trigger the resolution and bitrate downscaling strategy (for example, the resolution is reduced to 75% of the current resolution, and the bitrate is dynamically adjusted between 60% - 80% of the original bitrate).

[0048] In some embodiments, triggering the screen resolution and bitrate downscaling program specifically includes: Reduce the screen resolution to a preset ratio of the current screen resolution to obtain the target screen resolution; More specifically, according to the screen resolution and the original video resolution, perform proportional scaling (for example, if the screen resolution is 1080p and the original video resolution is 4K, then adjust to 1080p; if there is playback stuttering, further reduce to 720p); Through the formula:

[0049] Calculate the bitrate after downscaling .

[0050] In addition, the device performance coefficient is dynamically calculated based on the number of CPU cores and GPU performance (for example, the coefficient for low - configuration devices is 0.6, and for high - configuration devices is 1.0).

[0051] It should be noted that in this step, by real - time monitoring the CPU load threshold and the playback abnormal state, a hierarchical response mechanism is established. It includes: Triple determination conditions: Synchronously detect the encoding format compatibility, playback error types, and hardware load levels to ensure that adjustments are only triggered for scenarios that truly require degradation.

[0052] Parameter coupling algorithm: The resolution is scaled in a geometric progression (such as a 75% linear decrease), and the bitrate logarithmic curve is adjusted to form a mathematical mapping relationship to keep the picture quality parameters changing coordinately.

[0053] Dynamic transcoding architecture: Adopt a two-stage transcoding pipeline design. The original quality parameters are retained in the first-round transcoding, and when an exception occurs, the parameter-reducing secondary transcoding is started.

[0054] The hardware parameters include the available memory of the playback device. The method also includes: When the available memory is less than the preset memory value, reduce the buffer during the transcoding process to the preset size.

[0055] As an example, if the available memory < 512MB, limit the buffer size during the transcoding process to avoid memory overflow.

[0056] In addition, the transcoding engine selection involved in this application can be: Use an efficient open-source library (such as FFmpeg) or Android native MediaCodec for hardware-accelerated transcoding, and automatically switch the software / hardware decoding mode according to the device GPU support situation.

[0057] Transcoding process: ① Input parameters: Original video path, target encoding format, resolution, bitrate.

[0058] ② Execution steps: Analyze the parameters such as the encoding format, resolution, and bitrate of the original video; Call the transcoding engine API to initialize the encoder; Perform transcoding according to the target parameters, and monitor the transcoding progress and resource occupancy (CPU, memory) in real time; After transcoding is completed, generate a new video file, store it in the device cache directory, and record the transcoding parameters.

[0059] Playback verification mechanism: After transcoding is completed, automatically replace the original video stream for playback, and continuously monitor the frame rate, number of freezes, and error codes of the new video; If the playback effect is not improved (such as the freeze frequency drops < 30%), trigger a secondary decision to further adjust the transcoding parameters (such as reducing the resolution by one more level or changing the encoding format).

[0060] Based on the foregoing description, in this embodiment, by playing back feedback and device information in real time, the transcoding parameters are accurately adjusted to solve the compatibility problems of different Android devices (such as stuttering on low - configuration devices and unsupported encoding formats). Compared with traditional transcoding with fixed parameters, the stuttering rate can be reduced by 30% - 50%, the video loading speed can be increased by 20% - 30%, and the playback failure rate caused by unsupported formats can be reduced by more than 80%. In addition, this application dynamically allocates transcoding resources based on device performance, avoiding performance waste of high - bitrate videos on low - configuration devices while ensuring the picture quality experience of high - configuration devices.

[0061] In addition, this application Figure 2 provides an Android video adaptive secondary transcoding system for the embodiments of this application. As Figure 2 shown, the system provided by the embodiments of this application mainly includes: A playback feedback collection module 210, which is used to obtain the current actual playback frame rate in real time to determine whether stuttering occurs during the current playback; listen to the error callback information of the player in real time to determine whether a playback error occurs; and obtain the current playback progress regularly to determine whether playback stagnation occurs.

[0062] The playback feedback collection module 210 includes a frame rate monitoring unit, which is used to calculate the actual playback frame rate by recording the timestamps of two consecutive frames in the player rendering thread. When the frame rate is lower than the preset frame threshold within a continuous preset time interval, it is determined that stuttering occurs during the current playback; wherein, the formula for calculating the actual playback frame rate is: frame rate = 1 / the interval time between two consecutive frames.

[0063] Those skilled in the art can understand that the playback feedback collection module 210 dynamically calculates the actual frame rate through the frame interval time. With a threshold of 25fps and a 5 - second continuous monitoring mechanism, it can identify abnormal picture smoothness. For example, when the frame rate drops to 20fps due to network fluctuations, the system can immediately trigger an alarm and record the timestamp, helping developers quickly locate the stuttering period. Compared with the traditional subjective evaluation method, this quantitative method makes the optimization direction clearer.

[0064] The playback feedback collection module 210 captures decoding errors (ERROR_DECODE) and format exceptions (ERROR_UNSUPPORTED) by listening to interfaces such as MediaPlayer.OnErrorListener, and establishes a mapping relationship between the error code and the occurrence time. This mechanism enables the player to not only automatically interrupt the abnormal stream to avoid crashing when encountering encoding compatibility problems, but also generate a diagnostic report containing the error type.

[0065] The playback feedback collection module 210 uses the progress increment analysis method (triggered when the progress change within 10 seconds < 1% of the total duration), which can effectively distinguish between active pauses by users and abnormal system stagnation. For example, when a CDN node fails and causes buffering failure, this technology can accurately identify and switch to an alternative source to avoid the "false dead" state.

[0066] The device information acquisition module 220 is used to obtain the hardware parameters, software parameters, and screen resolution of the playback device.

[0067] Those skilled in the art can understand that the device information acquisition module 220 can dynamically adjust the decoding thread allocation strategy by parsing the CPU model (such as Snapdragon 888), the number of cores, and the real-time load (the average load within 1 minute ≤ 1.5 is considered normal). For example, when it is detected that the load of a 4-core CPU reaches 80%, it will automatically downgrade to 720P playback to avoid stuttering. The detection of the GPU OpenGL ES version (such as version 3.2 supports Vulkan rendering) combined with the call of the manufacturer's API can intelligently select the graphics acceleration scheme.

[0068] The system version detection (SDK_INT ≥ 26 is determined as Android 8.0+) and the encoding format traversal (such as the support check for H.265 Main Profile) involved in the device information acquisition module 220 can pre-avoid format incompatibility problems.

[0069] The adaptive secondary transcoding module 230 is used to, when it is determined that a playback error occurs and the error is encoding format incompatibility, select the format with the highest priority from the encoding list included in the software parameters that is supported by the device as the final encoding format, and perform secondary transcoding according to the final encoding format; when stuttering occurs, a playback error occurs and the error is not encoding format incompatibility, or playback stagnation occurs, and when the CPU load in the hardware parameters is greater than the preset value, trigger the screen resolution and bitrate reduction program; perform secondary transcoding based on the reduced screen resolution and bitrate.

[0070] The adaptive secondary transcoding module includes a secondary transcoding calculation unit, which is used to reduce the screen resolution to a preset ratio of the current screen resolution to obtain the target screen resolution; Through the formula:

[0071] Calculate to obtain the .

[0072] It should be noted that the adaptive secondary transcoding module 230 establishes a hierarchical response mechanism by real-time monitoring the CPU load threshold and the playback abnormal state. It includes: Triple determination conditions: Synchronously detect the encoding format compatibility, playback error types, and hardware load levels to ensure that adjustments are only triggered for scenarios that truly require downgrading.

[0073] Parameter coupling algorithm: The resolution is scaled geometrically (e.g., linearly decreasing by 75%) and the bitrate logarithmic curve is adjusted to form a mathematical mapping relationship, maintaining the coordinated change of video quality parameters.

[0074] Dynamic transcoding architecture: Adopt a two-stage transcoding pipeline design. The original quality parameters are retained in the first-round transcoding, and parameter reduction secondary transcoding is initiated in case of anomalies.

[0075] Based on the foregoing description, this embodiment involves: Two-dimensional decision-making mechanism: Combine real-time playback feedback (lag, errors) and device characteristics (hardware performance, encoding support) to construct an adaptive transcoding strategy, breaking through the limitations of traditional single-device information transcoding.

[0076] Dynamic parameter adjustment algorithm: Based on parameters such as the device's CPU / GPU load and screen resolution, dynamically calculate the transcoding resolution and bitrate through a quantization formula to achieve fine-grained transcoding control.

[0077] Closed-loop verification process: Automatically verify the playback effect after transcoding to form a closed-loop optimization of "monitoring - decision-making - transcoding - verification" to ensure continuous improvement of the transcoding effect.

[0078] In addition, the embodiment of the present application also provides a non-volatile computer storage medium, on which executable instructions are stored. When the executable instructions are executed, an Android video adaptive secondary transcoding method as described above is implemented.

[0079] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An Android video adaptive secondary transcoding method, characterized in that The method includes: Obtaining the current actual playback frame rate in real time to determine whether there is any stuttering in the current playback; listening to the error callback information of the player in real time to determine whether there is any playback error; obtaining the current playback progress at regular intervals to determine whether there is any playback stagnation; Obtaining the hardware parameters, software parameters, and screen resolution of the playback device; When it is determined that there is a playback error and the error is an incompatible encoding format, select the format with the highest priority among the encoding formats supported by the device from the encoding list included in the software parameters as the final encoding format, and perform secondary transcoding according to the final encoding format; When there is stuttering, there is a playback error and the error is not an incompatible encoding format, or there is playback stagnation, and when the CPU load in the hardware parameters is greater than the preset value, trigger the screen resolution and bitrate reduction program; perform secondary transcoding based on the reduced screen resolution and bitrate.

2. The Android video adaptive secondary transcoding method according to claim 1, wherein, Obtaining the current actual playback frame rate in real time to determine whether there is any stuttering in the current playback, specifically including: In the player rendering thread, calculate the actual playback frame rate by recording the timestamps of two consecutive frames. When the frame rate is lower than the preset frame threshold within a continuous preset time interval, it is determined that there is stuttering in the current playback; Among them, the formula for calculating the actual playback frame rate is: frame rate = 1 / the interval time between two consecutive frames.

3. The Android video adaptive secondary transcoding method according to claim 1, wherein Listening to the error callback information of the player in real time to determine whether there is any playback error; Obtaining the current playback progress at regular intervals to determine whether there is any playback stagnation, specifically including: Listening to the error callback interface of the player in real time to capture the error callback information; among them, the error callback information includes: decoder error, incompatible encoding format; Obtaining the current playback progress at regular intervals. When the progress increment is less than 1% of the total video duration within a continuous preset progress time period, it is determined that there is playback stagnation.

4. The Android video adaptive secondary transcoding method according to claim 1, characterized in that, The hardware parameters at least include the CPU load and available memory, and the software parameters at least include the encoding list; Obtaining the hardware parameters, software parameters, and screen resolution of the playback device, specifically including: Using android.system.Os to obtain the CPU load; obtaining the available memory through ActivityManager.MemoryInfo; Traversing MediaCodecList.getCodecInfoList() of the playback device to obtain the video encoding formats supported by the playback device and add them to the encoding list; Obtaining the screen width, height, and density through DisplayMetrics to obtain the screen resolution.

5. The Android video adaptive secondary transcoding method according to claim 1, wherein Triggering the screen resolution and bitrate reduction program, specifically including: Reducing the screen resolution to a preset ratio of the current screen resolution to obtain the target screen resolution; Through the formula: After calculating to obtain the reduced bit rate .

6. The Android video adaptive secondary transcoding method according to claim 1, wherein, The hardware parameters include the available memory of the playback device, The method further includes: When the available memory is less than the preset memory value, reduce the buffer during the transcoding process to the preset size.

7. An Android video adaptive secondary transcoding system, characterized in that, The system includes: A playback feedback collection module for obtaining the current actual playback frame rate in real time to determine whether there is any stuttering in the current playback; listening to the error callback information of the player in real time to determine whether there is any playback error; obtaining the current playback progress at regular intervals to determine whether there is any playback stagnation; A device information acquisition module, configured to acquire the hardware parameters, software parameters, and screen resolution of a playback device; An adaptive secondary transcoding module, configured to, when it is determined that a playback error occurs and the error is an incompatible encoding format, select the highest-priority format from the encoding formats supported by the device from the encoding list included in the software parameters as the final encoding format, and perform secondary transcoding according to the final encoding format; when there is a freeze, a playback error occurs and the error is not an incompatible encoding format, or a playback stall occurs, and when the CPU load in the hardware parameters is greater than a preset value, trigger a screen resolution and bitrate reduction program; perform secondary transcoding based on the reduced screen resolution and bitrate.

8. The Android video adaptive secondary transcoding system according to claim 7, wherein The playback feedback collection module includes a frame rate monitoring unit, configured to calculate the actual playback frame rate by recording the timestamps of two consecutive frames in the player rendering thread, and determine that a current playback freeze occurs when the frame rate is lower than a preset frame threshold within a continuous preset time interval; wherein, the formula for calculating the actual playback frame rate is: frame rate = 1 / the interval time between two consecutive frames.

9. The Android video adaptive secondary transcoding system according to claim 7, characterized in that, The adaptive secondary transcoding module includes a secondary transcoding calculation unit, configured to reduce the screen resolution to a preset ratio of the current screen resolution to obtain a target screen resolution; through the formula: After calculating to obtain the reduced bit rate .

10. A non-volatile computer storage medium, characterized in that, Stored thereon are computer instructions, and when the computer instructions are executed, they implement an Android video adaptive secondary transcoding method according to any one of claims 1-6.

Images