An encryption method and system based on HLS protocol

Abstract

The present invention provides an encryption method and system based on the HLS protocol, the system includes: an embedded device end, which collects audio and video data, performs encryption processing on only the first n bytes of the video I frame, and encapsulates and generates a TS file to reduce CPU computing pressure; a server end, which receives the encrypted TS file, stores and generates an m3u8 index file, which has embedded encryption details, includes an encryption type identifier and encrypted data length, and extends the standard HLS with a private protocol; a mobile terminal playback system, which is designed with customized decryption logic, can parse enhanced m3u8 files, decrypt the specified bytes of the I frame in the downloaded TS file according to instructions, and then performs audio and video decoding and playback, optimizing data processing efficiency and user experience. The present invention achieves data security while optimizing system resource allocation by locally encrypting the TS file and extending the HLS protocol, is particularly suitable for embedded device environments with limited hardware capabilities, and promotes the efficient implementation of cloud storage solutions in the security field.

Description

Technical Field

[0001] The present invention relates to the technical field of HLS protocol encrypted playback, and in particular to an encryption method and system based on the HLS protocol. Background Art

[0002] In current security applications, uploading audio and video data collected by embedded devices to the cloud and enabling offline access on mobile devices through the HLS protocol is a key technical solution to ensure data accessibility and system flexibility. The HLS protocol has become the preferred choice for streaming media transmission due to its good compatibility and adaptability. However, while implementing this process, data security becomes an issue that cannot be ignored, especially for sensitive security surveillance videos, where encryption processing is particularly important.

[0003] The standard HLS protocol allows for full encryption of TS files, ensuring secure content transmission. However, when this method is implemented on certain embedded devices with limited hardware resources, it significantly increases the CPU burden, potentially causing unstable device operation and affecting normal functionality. This is because full encryption requires significant computing power to process the encryption algorithm, and many embedded devices, especially those designed for low-power, low-cost applications, often lack such processing capabilities.

[0004] The common practice of encrypting TS files in existing technologies fails to fully consider the above-mentioned hardware limitations, especially the balance between encryption strength and device performance. Although there are mature HLS playback solutions on the market, most of them follow standard protocols and cannot be directly applied to custom content extended by encryption algorithms. This limits the application scope of encryption technology in resource-limited environments.

[0005] In addition, the encryption schemes in the existing technology lack flexibility and do not have optimized designs for encryption granularity in different scenarios. As a result, while ensuring data security, it is difficult to avoid excessive consumption of system resources, especially having a significant impact on the performance of embedded devices.

[0006] Therefore, the main shortcomings of existing HLS encryption methods in practical applications include:

[0007] 1. Hardware compatibility issues: Full encryption places an excessive burden on the CPU of low-performance embedded devices, affecting system stability.

[0008] 2. Player compatibility limitations: Standard HLS players do not support custom encryption extensions, which limits the universal playback capabilities of encrypted content.

[0009] 3. Trade-off between encryption efficiency and security: There is a lack of effective encryption strategies to balance data security and device performance requirements, especially in resource-constrained scenarios.

[0010] In summary, current technologies fail to effectively resolve the contradiction between hardware capability limitations and content security requirements when implementing HLS protocol encrypted playback. There is an urgent need for an innovative solution that can both ensure data encryption security and reduce the computing burden of embedded devices. Summary of the Invention

[0011] In response to the problems existing in the prior art, the present invention provides an encryption method and system based on the HLS protocol.

[0012] To achieve the above object, the specific solutions of the present invention are as follows:

[0013] The present invention provides an encrypted playback system based on the HLS protocol, the system comprising:

[0014] The embedded device is equipped with an encryption module for collecting audio and video data. It only encrypts the first n bytes of the video I frame and encapsulates it to generate a TS file, reducing the CPU computing pressure.

[0015] Where n: represents the length of the encrypted data, n is greater than or equal to 1 and less than or equal to the size of the file;

[0016] On the server side, the encrypted TS file is received, stored, and generated into an m3u8 index file. This file embeds encryption details, including the encryption type identifier (encryptType) and the encrypted data length (encryptDataLen), and extends the standard HLS with a private protocol.

[0017] The mobile playback system is designed with customized decryption logic that can parse enhanced m3u8 files, decrypt the specified bytes of the I-frame in the downloaded TS file according to the instructions, and then decode and play the audio and video, optimizing data processing efficiency and user experience.

[0018] Furthermore, the encryption module adopts AES-128 bit encryption algorithm to ensure the security of video data.

[0019] Furthermore, the system also includes a load balancing server for distributing user requests to different streaming media servers to improve the overall service capability and stability of the system.

[0020] Furthermore, the mobile playback system integrates hardware accelerated decoding function, effectively utilizing device GPU resources, reducing battery consumption and improving decoding efficiency.

[0021] Furthermore, the system also includes a user identity authentication module to verify user access rights to ensure that only authorized users can access the encrypted audio and video content.

[0022] The present invention also provides an encrypted playback method based on the HLS protocol, based on the above system, characterized in that the method includes the following steps:

[0023] S1, on the embedded device side, collects the original audio and video data, selectively performs encryption algorithm processing on only the first n bytes of the I frame, and encapsulates it to generate an encrypted TS file;

[0024] S2, upload the encrypted TS file to the server, and pass the encryption algorithm type and encrypted data length information to the server;

[0025] S3, after receiving the information, the server generates an m3u8 index file with embedded encryption parameters, using the private extension fields encryption type (encryptType) and encrypted data length (encryptDataLen) to describe the encryption details;

[0026] S4, the mobile terminal requests and parses the m3u8 file, and decrypts the I frame header encrypted data in the received TS segment according to the encryption parameters provided in the file;

[0027] In S5, the decrypted TS file is further decoded into audio and video streams by the mobile terminal, achieving a secure and efficient streaming media playback experience while maintaining low resource consumption.

[0028] Furthermore, step S1 further includes performing intelligent analysis on the I frame before encryption, and encrypting only the portion containing key visual information to optimize the encryption processing speed and playback quality.

[0029] Furthermore, in step S3, the encryption parameters also include timestamp verification information, and the mobile terminal performs time verification before decryption to prevent illegal time offset attacks and enhance content protection.

[0030] Furthermore, in step S4, the mobile terminal decoding process supports dynamic bit rate adjustment, automatically selecting the most suitable video stream quality according to the network conditions to ensure a smooth playback experience.

[0031] Furthermore, step S5 also includes encapsulating the audio and video streams with digital rights management (DRM) after decryption, to ensure that the content is still protected by copyright after decryption and playback, and to prevent unauthorized copying and distribution.

[0032] The technical solution of the present invention has the following beneficial effects:

[0033] 1. Optimize encryption strategies to adapt to low-performance hardware: This solution reduces the amount of data required for encryption operations by encrypting only the first n bytes of the I frame in the TS file, effectively alleviating the high CPU load problem of embedded devices and ensuring that the device can maintain the normal operation of other core functions while performing encryption operations.

[0034] 2. Balancing security and performance: Although only partially encrypted, basic content security is still guaranteed because all video decoding relies on I-frames. This approach significantly improves overall system performance without sacrificing too much security.

[0035] 3. Enhanced protocol compatibility and flexibility: By introducing private extension fields (encryptType and encryptDataLen) in the M3U8 file, customized encryption information is added to the standard HLS protocol, enabling players that support this private protocol to correctly parse and process encrypted data, ensuring correct playback of the data.

[0036] 4. Improve mobile playback experience: The mobile terminal only needs to decrypt part of the data, which reduces data processing time and speeds up the decryption and decoding process, thereby improving the loading and playback speed of audio and video content and enhancing the user experience.

[0037] 5. Promote efficient use of resources: Reduced encryption and decryption requirements mean less power consumption and network bandwidth usage, which is especially important for mobile devices as it is directly related to battery life and traffic costs.

[0038] 6. Technological innovation and application expansion: The encryption method proposed in this invention is not only a technological innovation, but also provides new ideas for the application of the HLS protocol in resource-constrained environments, expanding its scope of application in security and other fields that are sensitive to hardware performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 is a system block diagram of the present invention;

[0040] Figure 2 It is the overall flow chart of the present invention. DETAILED DESCRIPTION

[0041] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It will be understood that the specific embodiments described herein are merely intended to explain the present invention rather than to limit the present invention. It should also be noted that, for ease of description, the accompanying drawings only show portions related to the present invention rather than all of the present invention.

[0042] Combine Figure 1-Figure 2 As shown, the present invention provides an encrypted playback system based on the HLS protocol, the system comprising:

[0043] The embedded device is equipped with an encryption module for collecting audio and video data. It only encrypts the first n bytes of the video I frame and encapsulates it to generate a TS file, reducing the CPU computing pressure.

[0044] Where n: represents the encrypted data length, n is greater than or equal to 1 and less than or equal to the file size. For example, if the file size is 50 bytes, the encrypted byte length is set to the first 10 bytes or the first 12 bytes, that is, the encrypted byte length n, which ranges from 1 to 50 bytes.

[0045] On the server side, the encrypted TS file is received, stored, and generated into an m3u8 index file. This file embeds encryption details, including the encryption type identifier (encryptType) and the encrypted data length (encryptDataLen), and extends the standard HLS with a private protocol.

[0046] The mobile playback system is designed with customized decryption logic that can parse enhanced m3u8 files, decrypt the specified bytes of the I-frame in the downloaded TS file according to the instructions, and then decode and play the audio and video, optimizing data processing efficiency and user experience.

[0047] The encryption module uses AES-128 bit encryption algorithm to ensure the security of video data.

[0048] The system also includes a load balancing server for distributing user requests to different streaming media servers, thereby improving the overall service capabilities and stability of the system.

[0049] The mobile playback system integrates hardware accelerated decoding function, effectively utilizes device GPU resources, reduces battery consumption and improves decoding efficiency.

[0050] The system also includes a user authentication module to verify user access rights and ensure that only authorized users can access encrypted audio and video content.

[0051] The present invention also provides an encrypted playback method applied to the HLS protocol. Based on the above system, the method includes the following steps:

[0052] S1, on the embedded device side, collects the original audio and video data, selectively performs encryption algorithm processing on only the first n bytes of the I frame, and encapsulates it to generate an encrypted TS file;

[0053] S2, upload the encrypted TS file to the server, and pass the encryption algorithm type and encrypted data length information to the server;

[0054] S3, after receiving the information, the server generates an m3u8 index file with embedded encryption parameters, using the private extension fields encryption type (encryptType) and encrypted data length (encryptDataLen) to describe the encryption details;

[0055] S4, the mobile terminal requests and parses the m3u8 file, and decrypts the I frame header encrypted data in the received TS segment according to the encryption parameters provided in the file;

[0056] In S5, the decrypted TS file is further decoded into audio and video streams by the mobile terminal, achieving a secure and efficient streaming media playback experience while maintaining low resource consumption.

[0057] Step S1 further includes performing intelligent analysis on the I frame before encryption, and encrypting only the portion containing key visual information to optimize encryption processing speed and playback quality.

[0058] In video processing and encryption, "critical visual information" generally refers to information that plays a decisive role in understanding the video content or significantly impacts the viewing experience. If this information is altered or lost, viewers may notice significant visual differences or difficulty understanding the content. Specifically, it may include the following aspects:

[0059] Contour information: The edges and contours of objects are crucial for recognizing their shape. The human eye is very sensitive to changes in contours, so contour information is often considered key in video frames.

[0060] Motion information: Motion vectors and areas of dramatic change (such as moving objects) in dynamic scenes often carry the main action information of the video and are very important for understanding the dynamic content of the video.

[0061] Facial features: In videos containing people, the face, especially the characteristic areas such as eyes and mouth, are extremely critical for conveying emotions and identifying identities.

[0062] Text and graphics: Textual information (such as titles and subtitles) and specific graphics (such as logos and charts) in a video are directly related to the information conveyed and are generally considered key visual elements.

[0063] High-contrast areas: Areas with high contrast are more likely to attract the audience's attention and are often the visual focus, so they may require special consideration during encryption.

[0064] During the encryption process, only this critical visual information is encrypted, while other non-critical components are ignored or processed using weaker encryption methods. This balances security and computing resource requirements. This strategy aims to ensure that even with limited encryption, the core information of the video content is still protected, while reducing the system resource consumption of encryption operations and maintaining smooth playback. However, this approach must be implemented with caution to avoid potential security vulnerabilities or visual distortion caused by uneven encryption.

[0065] In step S3, the encryption parameters also include timestamp verification information. The mobile terminal performs time verification before decryption to prevent illegal time offset attacks and enhance content protection.

[0066] In step S4, the mobile terminal decoding process supports dynamic bit rate adjustment, automatically selecting the most suitable video stream quality according to the network conditions to ensure a smooth playback experience.

[0067] Step S5 also includes encapsulating the audio and video streams with digital rights management (DRM) after decryption, ensuring that the content is still protected by copyright after decryption and playback, and preventing unauthorized copying and distribution.

[0068] Specific embodiment: In the field of security, there is a usage scenario where the audio and video data collected by the embedded device end needs to be uploaded to the cloud for storage. When the user needs to use it, the audio and video package files are downloaded on the mobile end for playback. In this way, the historical audio and video data of the device can be accessed even when the device is offline. The overall solution adopts the HLS protocol. For security reasons, the TS file needs to be encrypted. The standard HLS supports full encryption of TS, but considering that the hardware capabilities of some embedded devices are relatively poor, if the full encryption of TS data is used, the CPU load of the device will be too high, which will lead to abnormal function of the device end. In this scenario, in order to take into account both security and Considering the device performance, a compromise solution was adopted. After the embedded device generates the ts file, it only encrypts the first n bytes of the I frame. Since the video frame decoding needs to refer to the I frame, the encryption purpose is achieved. At the same time, only part of the data is partially encrypted, which also saves some of the embedded device's CPU computing power. When uploading the ts file, the encryption algorithm used and the length of the encrypted I frame byte data are told to the server. When the server generates the m3u8 file, it fills the encryption algorithm and the encrypted byte length into the file according to the private protocol. When the mobile terminal parses the m3u8 file and parses the encrypted information, it decrypts the I frame of the ts file according to the agreement, and then decodes it after decryption.

[0069] Introduction to key terms:

[0070] HLS protocol: By segmenting audio and video content into small segments and transmitting them using the HTTP protocol, it achieves efficient streaming media transmission and playback, suitable for various real-time and on-demand application scenarios;

[0071] TS file: TS file is a multimedia container format used to transmit audio, video, and other media data in the HLS protocol. It is an extension of the MPEG-2 transport stream standard and is often used for streaming media transmission on the network.

[0072] M3U8 file: An M3U8 file is a text-based format, usually with the file extension .m3u8. It uses plain text to describe the addresses, durations, and other related information of a series of media segments so that streaming media players can dynamically retrieve and play these segments.

[0073] The present invention relates to HLS protocol encrypted playback, and the user ends include embedded device ends, server ends, and mobile ends (Android platform, iOS platform, and Hongmeng platform).

[0074] This technology extends the existing standard HLS protocol. The extended protocol is not supported by the standard protocol, and players on the market that support the standard HLS protocol will not be able to play the video resource. The protocol extension requires the use of a private customized player to play media resources.

[0075] HLS (HTTP Live Streaming) is a streaming media transmission protocol developed by Apple. It is used to implement real-time streaming of audio and video on the Internet through the HTTP protocol.

[0076] HLS divides audio and video content into a series of small segments (TS files), and then transmits the TS files to the HLS server. The HLS server will generate one or more playlist files (usually with the .m3u8 extension) containing media segment information. The client obtains the address and information of the media segment through these playlist files.

[0077] The HLS protocol supports encryption and digital rights management (DRM), which can protect the security of audio and video content and prevent unauthorized access and piracy.

[0078] Due to the limitation of hardware capabilities, some embedded systems need to encrypt TS files for security reasons when using HLS to implement cloud storage solutions. However, due to insufficient hardware capabilities, it is not possible to encrypt all fields of TS files. This solution can ensure that the data is encrypted without affecting the normal use of the device.

[0079] The technology proposed in this invention expands upon the existing standard HLS protocol. The solution is mainly divided into the following steps:

[0080] Step 1: The embedded device obtains the link to the third-party cloud storage where the TS file is uploaded and the encryption key information from the HLS server;

[0081] Step 2: The embedded device encodes the collected audio and video raw data, encrypts the first n bytes of the encoded I frame, does not encrypt the video frame data and audio frame data of non-I frames, and encapsulates the encrypted data into a TS format file.

[0082] An I-frame (Intra Frame) is a key frame, also known as an intra-coded frame. It is a very important frame type in video compression coding.

[0083] Step 3: Upload the TS file to the third-party cloud storage server. After the upload is successful, report the Http link, encryption method, and encrypted data length for accessing the TS file resource to the HLS server.

[0084] Step 4: The HLS server stores the TS link and related auxiliary information.

[0085] Step 5: The mobile terminal requests the m3u8 file content. After receiving the request, the HLS server generates an m3u8 file with the TS link within the time range that the mobile terminal needs to play. The encryption information part of the file is filled according to the extended private protocol. The following is the content of the sample m3u8 file. Compared with the standard HLS protocol, this solution extends the fields encryptType and encryptDataLen to indicate the encryption type and encrypted data length, respectively:

[0086] #EXTM3U

[0087] #EXT-X-VERSION:3

[0088] #EXT-X-TARGETDURATION:4

[0089] #EXT-X-MEDIA-SEQUENCE:1

[0090] #EXT-X-KEY:METHOD=AES-128,URI="https: / / www.encrypt.info / ",IV=0x00000000000000000000000000000000000000000000000000000000000000,encryptType=IFrame,encryptDataLen=256

[0091] #EXTINF:4.000,

[0092] https: / / cn-bj4-prod.obs.cn-north-4.myhuaweicloud.com:443 / ts1

[0093] #EXTINF:4.000,

[0094] https: / / cn-bj4-prod.obs.cn-north-4.myhuaweicloud.com:443 / ts2

[0095] #EXT-X-ENDLIST

[0096] This text is the content of an M3U8 file. This is an index file format used to describe multimedia segments (such as video and audio). In this case, it contains information about how to encrypt and play the media segments.

[0097] Specifically:

[0098] #EXTM3U is a standard M3U8 file start marker.

[0099] #EXT-X-VERSION defines the version number of the M3U8 file protocol.

[0100] #EXT-X-TARGETDURATION specifies the maximum duration of each media segment.

[0101] #EXT-X-MEDIA-SEQUENCE provides the sequence number of the first media segment.

[0102] #EXT-X-KEY describes the key information used to encrypt the media segment, including the encryption method (AES-128), the URI (pointing to the location of the key file), and some other parameters.

[0103] The following lines provide the actual URLs for the media segments, of which there are two: ts1 and ts2.

[0104] Finally, the #EXT-X-ENDLIST tag indicates the end of the list.

[0105] Together, this information forms an M3U8 playlist that clients can use to download and play encrypted media segments.

[0106] Step 6: The mobile terminal parses the m3u8 content, obtains the encrypted information, and then downloads the TS files in sequence.

[0107] Step 7: Read the downloaded TS file frame by frame. When the read frame is a video frame and an I frame, decrypt the encrypted data in the header according to the decoding algorithm and the encrypted byte length filled in the m3u8 file. After the decryption is successful, replace the encrypted data in the header with the decrypted data to obtain a complete I frame data.

[0108] Step 8: Submit the decrypted audio and video frames to the decoder for decoding. After decoding, yuv and pcm data are obtained.

[0109] YUV and PCM are two different data representations, which are used to store video pixel information and audio sample data respectively.

[0110] YUV is a color space representation method widely used in the field of digital video, especially in video encoding, decoding and transmission. It divides the color information of an image into two parts: brightness (Y) and chrominance (UV):

[0111] Y (Luma): represents the brightness information of the image, reflecting the brightness and darkness of the image.

[0112] U (Chroma Blue) and V (Chroma Red): represent the chromaticity information of blue and red respectively, describing the color offset rather than the actual color value.

[0113] YUV data usually has multiple sub-formats, such as YUV 4:2:0, 4:2:2, 4:4:4, etc. These numbers represent the sampling ratio of the three components Y, U, and V, affecting the data volume and quality of the video.

[0114] PCM (Pulse Code Modulation) is a fundamental method for converting analog signals into digital signals and is widely used in the storage and transmission of audio data. In the audio field, PCM data directly represents the raw numerical value of audio samples. Each sample represents the audio amplitude at a specific point in time:

[0115] Sample value: Each value in the PCM data corresponds to the amplitude of the sound waveform at a certain point in time. These samples can be connected to reconstruct the original analog audio signal.

[0116] Bit depth: defines the accuracy of each sample. Common bit depths include 8 bits, 16 bits, 24 bits, etc. The more bits, the wider the dynamic range of sound that can be expressed and the better the sound quality.

[0117] Sampling rate: Indicates the number of samples collected per second, usually in kHz (kilohertz). For example, the sampling rate of CD quality sound is 44.1kHz.

[0118] In summary, YUV mainly processes pixel information of the video, focusing on how to efficiently represent and transmit the color and brightness information of the image; while PCM focuses on the digital representation of audio data, recording the amplitude changes of the sound signal through sample values. The two together constitute an important component of multimedia data.

[0119] Step 9: Use OpenGL to render the YUV data on the corresponding platform, and use the audio rendering API provided by the corresponding platform system to render the audio.

[0120] Step 10: When the TS in the m3u8 file is consumed, it means that the media resource playback is completed;

[0121] The present invention greatly reduces the CPU computing power occupied by embedded devices with low hardware configuration when using the HLS protocol for audio and video data communication and also uses an encryption mode to ensure data communication security, so that the embedded devices have more CPU computing power to complete other functions; in addition, the amount of data decrypted by the mobile terminal is also reduced, which theoretically reduces the time consumption of data decryption and speeds up the rendering of audio and video data.

[0122] The present invention has the following innovative features:

[0123] 1. Customized and extended HLS encryption method: Add new private fields in the m3u8 file: encryptType and encryptDataLen, which respectively indicate the encryption type (I-frame encryption) and the encrypted data length.

[0124] 2. Partial encryption and decryption of TS files: Only some bytes of the I-frame header in the TS file are encrypted to reduce the CPU computing power occupied during encryption and decryption.

[0125] Working principle:

[0126] This paper proposes an encryption method and system for the HLS protocol, aiming to address the difficulty of implementing full TS file encryption in embedded devices in the security field due to hardware limitations, while ensuring data transmission security. This solution balances encryption security and device performance, performing the following core operations:

[0127] Encryption strategy customization: Only the first n bytes of the I-frame (keyframe) in the video data are encrypted, because all video frame decoding requires reference to the I-frame. This strategy not only achieves the encryption purpose, but also reduces the amount of encrypted data and reduces the demand on the embedded device CPU.

[0128] Information transmission mechanism: After generating and encrypting some I-frame data, the embedded device uploads the encryption algorithm and encrypted byte length along with the TS file to the server and informs the server. When the server generates the M3U8 index file, it embeds these encryption details into the file using a proprietary protocol.

[0129] M3U8 file extension: Expands the M3U8 file format, adds the encryptType and encryptDataLen fields, and clearly indicates the encryption type is I-frame encryption and the specific encrypted data length, so that compatible players can accurately perform decryption operations.

[0130] Decryption and playback on a mobile device: After receiving the M3U8 file, the mobile device parses the encryption information, downloads the TS file, and decrypts only the specified bytes of the I-frame according to the instructions. The decrypted video frames (including I-frames and other unencrypted frames) are fed into the decoder and converted into YUV video data and PCM audio data, respectively.

[0131] Audio and video rendering: Finally, use OpenGL to render the YUV data into a video, and use the system audio API to process the PCM data to achieve audio and video playback.

[0132] This method effectively reduces the computing burden on embedded devices, improves overall system efficiency, and ensures data security. However, since it uses the extended HLS protocol, specific player support is required for compatible playback. This technology provides a practical and efficient solution for low-performance hardware devices using the HLS protocol for encrypted transmission.

[0133] The above description is only a preferred embodiment of the present invention and does not limit the scope of the invention. All equivalent structural transformations made by using the contents of the present invention description and drawings under the inventive concept of the present invention, or direct / indirect application in other related technical fields are included in the protection scope of the present invention.

Claims

1. An encrypted playback system based on the HLS protocol, characterized in that: The system includes: The embedded device is equipped with an encryption module for collecting audio and video data. It only encrypts the first n bytes of the video I frame and encapsulates it to generate a TS file, reducing the CPU computing pressure. Where n: represents the length of the encrypted data, n is greater than or equal to 1 and less than or equal to the size of the file; On the server side, the encrypted TS file is received, stored, and generated into an m3u8 index file. This file embeds encryption details, including the encryption type identifier and the encrypted data length, and extends the standard HLS with a private protocol. The mobile playback system is designed with customized decryption logic that can parse enhanced m3u8 files, decrypt the specified bytes of the I-frames in the downloaded TS files according to the instructions, and then decode and play the audio and video, optimizing data processing efficiency and user experience. The encryption module uses AES-128 bit encryption algorithm to ensure the security of video data; The system also includes a load balancing server for distributing user requests to different streaming servers, improving the overall service capabilities and stability of the system; The mobile playback system integrates hardware accelerated decoding function, effectively utilizing the device GPU resources, reducing battery consumption and improving decoding efficiency; It also includes a user authentication module to verify user access rights and ensure that only authorized users can access encrypted audio and video content; Based on the above system, implement the following steps: S1, on the embedded device side, collects the original audio and video data, selectively performs encryption algorithm processing on only the first n bytes of the I frame, and encapsulates it to generate an encrypted TS file; S2, upload the encrypted TS file to the server, and pass the encryption algorithm type and encrypted data length information to the server; S3, after receiving the information, the server generates an m3u8 index file with embedded encryption parameters, and uses the private extension fields encryption type and encrypted data length to describe the encryption details; S4, the mobile terminal requests and parses the m3u8 file, and decrypts the I frame header encrypted data in the received TS segment according to the encryption parameters provided in the file; In S5, the decrypted TS file is further decoded into audio and video streams by the mobile terminal, achieving a secure and efficient streaming media playback experience while maintaining low resource consumption; Step S1 further includes performing intelligent analysis on the I-frame before encryption, and encrypting only the portion containing key visual information to optimize encryption processing speed and playback quality; In step S3, the encryption parameters also include timestamp verification information. The mobile terminal performs time verification before decryption to prevent illegal time offset attacks and enhance content protection. In step S4, the mobile terminal decoding process supports dynamic bit rate adjustment, automatically selecting the most suitable video stream quality according to the network conditions to ensure a smooth playback experience; Step S5 also includes performing digital rights management packaging on the audio and video streams after decryption to ensure that the content is still protected by copyright after decryption and playback, preventing unauthorized copying and distribution.

Images