Method for decrypting and playing encrypted video based on iOS local server and storage

Abstract

The invention discloses a method for decrypting and playing an encrypted video based on an iOS local server and storage, which is realized by the following core steps of: 1, establishing an iOS local HTTPServer by adopting a three-party library CocoaHTTPServer, and configuring a 10-second period timer to monitor the state of the server and realize automatic reconnection; 2, constructing a local database based on FMDB and MJExtension, storing information such as video id, downloading interval, file path and the like, and designing differentiated storage logic for TS type and P4 type; 3, a request Manager module is constructed, and mapping of an original encrypted video address and a local playing address is achieved; 4, when the local server returns data to the player, decryption is carried out in a bitwise XOR mode, and it is ensured that the local cache video is always encrypted; and 5, packaging the functions into a videoKit.a static library of the iOS (Internet Operating System). According to the method, the encrypted video is downloaded, decrypted and played at the same time, and the method has the advantages of being high in safety, small in delay and high in universality, and is suitable for various application scenes needing to be played by the encrypted video at the iOS end.

Description

Technical Field

[0001] This invention relates to the field of mobile application product development technology, specifically a method for decrypting and playing encrypted videos based on iOS local servers and storage. Background Technology

[0002] In recent years, the misuse of network packet capture techniques (such as web crawlers and Charles tools) has led to the risk of hotlinking during video stream transmission. Therefore, servers typically encrypt video streams. Existing solutions for front-end decryption and playback suffer from two main problems: Download the full video and then decrypt it for playback: This requires waiting for the video to download completely, which takes a long time and results in a poor user experience. Request, decrypt, and play simultaneously: Over-reliance on the request and response interception capabilities provided by the player (such as AVPlayer's AVAssetResourceLoaderDelegate) limits compatibility and makes it unsuitable for various playback scenarios.

[0003] To address the aforementioned issues, this invention proposes a decryption and playback scheme based on iOS local servers, local storage, and differentiated video format processing, enabling efficient and secure playback of encrypted videos. Summary of the Invention

[0004] The purpose of this invention is to provide a method for decrypting and playing encrypted videos based on iOS local servers and storage, aiming to solve the following problems: 1. By overcoming player dependency limitations, encrypted videos can be downloaded, decrypted, and played simultaneously through collaboration between a local server and a database; 2. Ensure video security by encrypting the video stream during network transmission and local caching to prevent hotlinking or plagiarism; 3. Enhance versatility by encapsulating core functions into an SDK that supports calls from multiple iOS scenarios and third-party platforms (such as uniapp).

[0005] This invention provides a method for decrypting and playing encrypted videos based on iOS local servers and storage. The technical solution of this invention is implemented through a three-layer architecture of "third-party dependency - client core steps - SDK encapsulation", as detailed below: (a) Dependence on third-party capabilities Local server dependency: The third-party library CocoaHTTPServer is used to build a local HTTPServer for iOS, which is used to access the local storage content of the terminal and establish a communication link between the server and the client. Local storage dependency: Based on the combination of the third-party library FMDB (SQLite database management) and MJExtension (data model conversion), a local database (DataStorage) is built to realize the storage and management of video-related information.

[0006] (II) Core Implementation Steps for the Client 1. Setting up a local HTTP Server Set up a local server using CocoaHTTPServer and configure the corresponding file directory; set a timer with a 10-second cycle to monitor the server's running status in real time. If the server unexpectedly shuts down, trigger a reconnection operation and expose the reconnection interface to the client to ensure the server remains available.

[0007] 2. Local storage construction Based on "A Method for Fast Storage of Local Client Data in iOS", an SQLite database was created in the iOS sandbox, and table fields and data models were designed, as follows: Table fields include: video ID (uniquely identified by the original playback address), video name, program download bytes array (storing the range startBytes-endBytes), relative path of video file, storage time, file size, file type, index file address, and whether the download is complete. Data Model and Operations: Create data models corresponding to table fields to implement methods for adding, deleting, modifying, and querying data; Differentiated storage logic: TS type (HLS video stream, consisting of a .m3u8 index file and multiple .ts files): The first data acquired is stored in .m3u8 format and the index file address is recorded. Subsequent data is stored in .ts files. The files and ranges are associated through dictionary key-value pairs "length": "startBytes-endBytes" and "path": "file path.ts". P4 type (single file format, such as .mp4): On the first request, the file size is obtained and the corresponding data stream is created. After each download, the old data in the corresponding range is replaced with the new data. The downloaded "startBytes-endBytes" is stored in the bytes array as a string.

[0008] 3. RequestManager Construction and Scheduling The `requestManager` module is built to handle the mapping between the original encrypted video address and the local playback address, cache determination, data download, and response. The specific process is as follows: Start the local server and establish a long-lived connection between the server and the client using GCDAsyncSocket; Cache check: Compare with the video ID in the local database. If not cached, create a data model to store basic information, obtain the original video track information (resolution, frame rate, encoding method) through the tracks method of the AVAsset class, distinguish the video type (TS / P4), generate a local playback address and return it; if cached, directly return the stored local playback address. Uncached video processing: Download data by combining the original request address (including request header information) corresponding to the local address, and process the player's range request (start-end position of request data): TS type: Converts a range request into a request for the corresponding .ts file; P4 type: Replaces the data of the downloaded range and updates the range record in the bytes array; After the data download is complete, it is written to the local server file directory, the tag of the data segment in the database is updated, and the download result of the complete range is sent to the player through the local server. Cached video processing: Check if the local cache contains data for the current range. TS type: Check if a corresponding .ts file exists; P4 type: Check if the bytes array has a matching "startBytes-endBytes" record; If the data exists, the local server directly returns the corresponding data; if it does not exist, the data is obtained by requesting the original address through the requestManager, and the download and response logic in step 3 is repeated.

[0009] 4. Decryption Scheme Implementation Decryption method: Use bitwise XOR or XOR with a specific value to ensure that the data length remains unchanged after decryption, which is suitable for storing and reading P4 type files; Decryption timing: Decryption is performed when the local server sends data back to the player, ensuring that the locally cached video is always in an encrypted state and avoiding resource leakage.

[0010] (III) SDK Packaging The core functionalities described above are encapsulated into an iOS static library SDK. The specific steps are as follows: Create an iOS static library project that exposes only the entry file videoKit.h, containing the core method -(NSString*)getPlayUrlWithUrl:(NSString*)url (the input parameter is the original video address, and the output parameter is the local playback address). Implement this method in videoKit.m, integrating local server setup, local storage management, requestManager scheduling and decryption logic, and adding server disconnection reconnection and reconnection detection functions after background return; Package the static library into a videoKit.a file, import the file when using it, call the entry method to get the local playback address and pass it to the player, and you can achieve downloading, decryption and playback at the same time.

[0011] In summary, due to the adoption of the above-mentioned technologies, the beneficial effects of this invention are: 1. Enhanced security: The video stream is encrypted during network transmission and local caching, and is only decrypted when the server sends it back to the player, completely avoiding the risks of hotlinking and plagiarism.

[0012] 2. Lower latency: cached videos can be opened and played instantly, while local writing and decryption operations for uncached videos have minimal impact on performance and do not affect playback smoothness.

[0013] 3. It has greater versatility, eliminates the dependence on specific players, and the encapsulated SDK can be directly provided to third-party platforms (such as uniapp). Functionality can be achieved simply by calling the entry method, simplifying operation and ensuring code security. Attached Figure Description

[0014] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention, making other features, objects, and advantages of the invention more apparent. The illustrative embodiments of the invention illustrated in the drawings and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to represent selected embodiments of the invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] In the description of this invention, it should be understood that the terms indicating orientation or positional relationship are based on the orientation or positional relationship shown in the drawings and are only for the convenience of describing the invention and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention.

[0017] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific context of the specification.

[0018] This invention provides a method for decrypting and playing encrypted videos based on iOS local servers and storage. Example 1: First-time download, decryption, and playback of P4 type (MP4 format) encrypted video.

[0019] I. Implementation Scenarios When an iOS user integrates the SDK (videoKit.a) of this invention into a video application, and requests to play a certain encrypted MP4 video (of type P4, with the original encrypted video address "http: / / video-source / encrypted / video1.mp4") for the first time, the local server and local storage need to work together to download, decrypt, and play the video simultaneously, while the local cache remains encrypted at all times.

[0020] II. Prerequisites The iOS terminal system version supports the AVFoundation framework and the third-party libraries on which this invention depends. The application has imported the static library videoKit.a and included the entry file videoKit.h. The third-party libraries CocoaHTTPServer (used to build a local HTTPServer), FMDB, and MJExtension (used to build a local database) have been integrated into the SDK and are functioning normally. The original video server can respond normally to range requests for encrypted MP4 videos (supports downloading data with specified start and end positions).

[0021] III. Detailed Implementation Steps When a user triggers a playback operation, the SDK calls the entry method exposed by the application and inputs the original encrypted address of the video. The SDK then starts the core process, generates a local playback address (such as "http: / / 127.0.0.1:8888 / local_video1.mp4") through the requestManager module, and returns the address to the application.

[0022] The local HTTPServer initialization and status monitoring SDK uses CocoaHTTPServer to build a local HTTPServer for iOS, setting the server's file directory to the path "Documents / VideoLocalCache" within the iOS sandbox. It also starts a timer with a period of 10 seconds to monitor the server's running status in real time. If the server is detected to have shut down unexpectedly, it will automatically perform a reconnection operation. The SDK also exposes a reconnection method to the application, allowing the application to actively trigger a reconnection.

[0023] The local database construction and cache determination are based on FMDB and MJExtension. The SDK creates a local SQLite database within the sandbox. The table fields in the database include video ID (uniquely identified by the original encrypted video address), video name, program download bytes array (used to store the startBytes-endBytes range of data), relative path of the video file, storage time, file size, file type, and whether the download is complete. Simultaneously, a data object model matching the table fields and CRUD methods are created. The requestManager module compares the video ID in the database and finds no cached record corresponding to the original encrypted address, determining that the video is not cached locally and executing subsequent type identification and data processing procedures.

[0024] The video type identification (P4 type) module creates an AVAsset object and obtains the track information of the original encrypted video (such as resolution, frame rate, and encoding method) through the tracks method of AVAsset. Combined with the file format characteristics, it determines that the video is of type P4 (single file MP4 format). Then, it creates a data object corresponding to the video, stores basic information such as video ID, original encrypted address, and local playback address in the local database, and initializes the program download bytes array (initially empty).

[0025] The video data download and local storage requestManager module combines the original request address corresponding to the local playback address (generated by combining the original encrypted address and request header information) to send a range request to the original video server (e.g., request "bytes=0-1048575", i.e., 1MB of data). During the first download, the total file size of the MP4 video is obtained through the original request, and a data stream matching the total size is created locally. After the server returns the encrypted data of the corresponding range, the content of the corresponding range in the local data stream is replaced with the newly downloaded data, and the downloaded "0-1048575" is stored as a string in the program download bytes array. Subsequently, the updated data stream is written to the file directory of the local HTTPServer ("Documents / VideoLocalCache / local_video1.mp4"), and the fields of "file size", "downloaded range", and "download complete" (marked as "incomplete") of the data object in the local database are updated.

[0026] The local HTTPServer receives a local playback request initiated by the in-application player (requesting data "bytes=0-1048575" corresponding to the local playback address). Before sending the data back to the player, the SDK performs a decryption operation on this encrypted data segment—using a bitwise XOR method (i.e., sourceDataPoint[i]=sourceDataPoint[i]^1) to ensure that the length of the decrypted data is consistent with the original encrypted data. After decryption, the local HTTPServer sends the decrypted data back to the player through GCDAsyncSocket (a long connection has been established between the server and the client). The player receives the data and starts playback.

[0027] The subsequent data download and playback collaborative player continuously sends subsequent range requests (such as "bytes=1048576-2097151") to the local HTTPServer; the requestManager module repeats the process of steps 5-6: initiating network requests to download the encrypted data of the corresponding range, updating the local data stream and database records, and decrypting the data when the server sends it back; until all video data segments are downloaded, the local database marks the "whether the download is complete" of the data object as "completed", realizing the simultaneous download, decryption and playback of encrypted video throughout the entire process.

[0028] Example 2: First-time download, decryption, and playback of TS-type (HLS format) encrypted video.

[0029] I. Implementation Scenarios When an iOS user uses an educational application that integrates the SDK of this invention to request playback of an encrypted HLS format video (a TS type video consisting of one .m3u8 index file and 15 .ts segment files, with the original encrypted video address being "http: / / video-source / encrypted / lesson.m3u8") for the first time, differentiated storage logic is needed to achieve coordinated segment downloading, encrypted caching, and decryption playback.

[0030] II. Prerequisites Under the same iOS terminal environment and SDK integration conditions as in Example 1, the third-party library functions normally; The original video server supports the HLS protocol and can respond to encrypted data requests for .m3u8 index files and .ts segment files.

[0031] III. Detailed Implementation Steps The SDK calls the local playback address acquisition method. When the educational application calls the SDK entry method, it inputs the original encrypted address (.m3u8 address) of the HLS video. The SDK internally generates the local playback address (such as "http: / / 127.0.0.1:8888 / local_lesson.m3u8") through the requestManager module and returns it to the application.

[0032] The initialization of the local server and database is the same as steps 2-3 in Example 1: Build a local HTTPServer using CocoaHTTPServer and enable 10-second periodic status monitoring; create a local database and data model based on FMDB and MJExtension; the requestManager module compares the video ID (original .m3u8 address) in the database, determines that the video is not cached, and proceeds to the next step.

[0033] The video type identification (TS type) module creates an AVAsset object, obtains the original video track information through the tracks method, and determines that the video is of TS type (HLS video stream, consisting of .m3u8 index file and .ts segment file) by combining the ".m3u8" suffix of the original address and the characteristics of the HLS protocol. Then, it creates a corresponding data object, stores the video ID, the original encrypted address, and the local playback address in the database, and initializes the "index file address" field (used for storing the .m3u8 file path later).

[0034] The .m3u8 index file download and storage module sends a request for the .m3u8 index file to the original video server. After obtaining the encrypted .m3u8 data, it stores it in the file directory of the local HTTPServer. At the same time, it updates the "index file address" of the data object in the local database to the above storage path and records the file size and storage time.

[0035] The application's player parses the local .m3u8 index file to obtain the request information for the .ts segment file, and initiates a range request for the first .ts segment to the local playback address. The requestManager module transforms this range request into a request to the original video server "http: / / video-source / encrypted / lesson_01.ts" to obtain the encrypted data of the .ts segment. The encrypted .ts data is stored in the local HTTPServer file directory ("Documents / VideoLocalCache / local_lesson_01.ts"), and in the program download bytes array, the .ts file is associated with the corresponding byte range (assuming the segment size is 512KB and the range is 0-524287) through dictionary key-value pairs ("length": "0-524287", "path": "Documents / VideoLocalCache / local_lesson_01.ts"). The bytes array of the data object in the local database and the "download complete" status (marked as "incomplete") are updated.

[0036] After receiving a request for "local_lesson_01.ts" from the player, the local HTTPServer performs bitwise XOR decryption on the encrypted data of the .ts segment before sending the data back. After decryption, the data is sent back to the player via GCDAsyncSocket, and the player plays the .ts segment. Subsequent .ts segments (from "local_lesson_02.ts" to "local_lesson_15.ts") repeat steps 5-6 until all segments are downloaded. The local database then marks "download complete" as "completed", thus enabling simultaneous downloading, decryption, and playback of HLS encrypted video.

[0037] Example 3: Secondary fast playback of cached encrypted video

[0038] I. Implementation Scenarios In Example 1, iOS users have already completed the full caching of the encrypted MP4 video (P4 type). When they click to play the video again through the video application, it is necessary to achieve "instant decryption and playback without re-downloading" to demonstrate the low latency advantage of this invention.

[0039] II. Prerequisites The MP4 video has been fully downloaded using Example 1. The "Download Complete" status of the video data object in the local database is marked as "Completed". The program download bytes array stores all downloaded ranges (e.g., "0-99999999", corresponding to 100MB of video). The local HTTPServer maintains normal operation through timer monitoring, or has automatically reconnected and recovered after an unexpected shutdown.

[0040] III. Detailed Implementation Steps SDK Call and Cache Validity Judgment: The video application calls the SDK entry method again, inputting the original encrypted address of the video; the requestManager module queries the local database, matches the stored data object with the video ID (original encrypted address), further checks the program download bytes array and the "download complete" field, confirms that the local cache is complete and the full download is complete, determines that there is no need to initiate a network request, and directly returns the stored local playback address.

[0041] The player requests and reads local data. The in-app player sends the first range request (e.g., "bytes=0-1048575") to the returned local playback address. The requestManager module checks the program download bytes array in the local database to confirm the existence of a record in the range "0-1048575" and that "local_video1.mp4" in the local HTTPServer file directory is complete. The local HTTPServer directly reads the encrypted data corresponding to this range without sending a download request to the original video server.

[0042] For decryption and fast playback, the local HTTPServer performs bitwise XOR decryption on the read encrypted data and immediately sends it back to the player, which then starts playing instantly. All subsequent range requests initiated by the player are directly read, decrypted, and sent back by the local HTTPServer, with no network request delay throughout the process, achieving "instant playback" of cached encrypted videos.

Claims

1. A method for decrypting and playing encrypted videos based on iOS local server and storage, characterized in that: Includes the following steps: S1: Set up a local HTTPServer on the iOS terminal, set the file directory corresponding to the local HTTPServer, and configure a monitoring mechanism to detect the running status of the local HTTPServer in real time. When the local HTTPServer is unexpectedly shut down, automatically perform a reconnection operation. S2: Build a local database within the sandbox of the iOS terminal. The local database contains at least one table. The fields of the table at least cover the video ID, video name, program download bytes array, relative path where the video file is stored, storage time, file size, file type, index file address, and whether the download is complete. At the same time, create a data object model that matches the fields of the table and implement the CRUD methods for the data object model. The program download bytes array is used to store the startBytes-endBytes range information of the video data. S3: Construct the requestManager module, which is used to map the original encrypted video address to the local playback address and to schedule data. S4: During the process of the local HTTPServer sending video data back to the player, the video data is decrypted. S5: Encapsulate the functions described in steps 1 to 4 into a static library. The static library exposes at least one entry method. By calling the entry method, the original encrypted video address is input, the corresponding local playback address is output, and the local playback address is passed to the player, so as to realize the simultaneous downloading, decryption, and playback of the encrypted video.

2. The method for decrypting and playing encrypted videos based on an iOS local server and storage according to claim 1, characterized in that, In S1, the local HTTPServer is built using the third-party library CocoaHTTPServer; the monitoring mechanism is a timer with a detection period of 10 seconds; the local HTTPServer also exposes a reconnection method to the client, allowing the client to actively trigger the reconnection operation.

3. The method for decrypting and playing encrypted videos based on an iOS local server and storage according to claim 1, characterized in that, In S2, the local database is constructed by combining the third-party library FMDB with MJExtension; the video ID uses the original encrypted video address as a unique identifier.

4. The method for decrypting and playing encrypted videos based on an iOS local server and storage according to claim 1, characterized in that, S3 also includes: S31: Start the local HTTPServer and establish a connection between the local HTTPServer and the client; S32: The requestManager module compares the video ID in the local database to determine whether the video data corresponding to the original encrypted video address is cached locally. If not cached, it obtains the video track information corresponding to the original encrypted video address through the tracks method of the AVAsset class, distinguishes the video type based on the video track information, generates a local playback address, creates a data object corresponding to the original encrypted video address and stores it in the local database, and then returns the local playback address. If cached, it directly returns the local playback address stored in the local database. S33: If the video data is not cached locally, the requestManager module downloads the video data from the network based on the original request address corresponding to the local playback address, processes the range request initiated by the player, the range request is used to specify the start and end positions of the requested video data, writes the downloaded video data to the file directory of the local HTTPServer, and updates the tag information of the corresponding data object in the local database; if the video data is cached locally, the requestManager module checks whether the local cached data contains the content of the startBytes-endBytes range corresponding to the range request. If it does, the local HTTPServer directly obtains the video data corresponding to that range; if it does not, it performs the operation of downloading the video data from the network.

5. The method for decrypting and playing encrypted videos based on an iOS local server and storage according to claim 4, characterized in that, In S32, the video type includes TS type and P4 type; wherein, the TS type is an HLS video stream, which consists of multiple .ts files and .m3u8 index files; the P4 type is a single-file format video, including .mp4 format.

6. The method for decrypting and playing encrypted videos based on an iOS local server and storage according to claim 4, characterized in that, In S33, when processing the range request, if the video type is TS, the range request is converted into a request for the corresponding .ts file. The first downloaded video data is stored in .m3u8 format, and the address of the .m3u8 index file is recorded in the index file address field of the local database. Subsequent downloaded video data is stored in .ts files. The .ts file is associated with the corresponding startBytes-endBytes range through a dictionary key-value pair "length":"startBytes-endBytes""path":"ts file storage path", and this association information is stored in the program download byte. The s array; if the video type is P4, a data stream is created based on the size of the acquired video file during the first download. After each download, the data in the data stream corresponding to the current range request is replaced with the newly downloaded data. The downloaded startBytes-endBytes range is stored as a string in the program download bytes array. The tag information of the corresponding data object in the local database is updated, specifically, the startBytes-endBytes range corresponding to the downloaded video data has been downloaded. The original request address is generated by combining the original encrypted video address corresponding to the local playback address with the request header information.

7. The method for decrypting and playing encrypted videos based on an iOS local server and storage according to claim 1, characterized in that, In S4, the decryption operation adopts a bitwise XOR method, specifically sourceDataPoint[i]=sourceDataPoint[i]^1, where sourceDataPoint is the video data to be decrypted.

8. The method for decrypting and playing encrypted videos based on an iOS local server and storage according to claim 1, characterized in that, In S5, the static library is an iOS static library, and the file name of the static library is videoKit.a; the entry method is -(NSString*)getPlayUrlWithUrl:(NSString*)url, the input parameter of the entry method is the original encrypted video address, and the output parameter is the local playback address; the static library also implements the disconnection reconnection operation of the local HTTPServer and the reconnection detection operation after the iOS terminal returns from the background.

9. A method for decrypting and playing encrypted videos based on an iOS local server and storage, as described in claim 4, characterized in that, In S31, a long-lived connection is established between the local HTTPServer and the client via GCDAsyncSocket.

Images