Image transmission method of non-compression packaged video and related equipment

Abstract

The invention discloses an image transmission method of a non-compression packaging video and related equipment, and relates to the technical field of data transmission, the method comprises the following steps: acquiring a non-compression packaging original video file, video data in the original video file being in a non-4K alignment state; obtaining a storage address of each frame of image data in the original video file; based on the storage address of each frame of image data, the number of filling bytes to be inserted before the corresponding frame of image data is calculated, the corresponding number of filling bytes obtained through calculation are inserted, a target video file is generated, and video data in the target video file are in a 4K alignment state; and re-packaging the target video file into an uncompressed packaged video file, storing the uncompressed packaged video file, and then performing cache-free reading. According to the method and the device, the video data in the non-compression packaged video file can be efficiently read to the memory in a cache-free reading mode, and the video data is output to the display equipment.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology, and in particular to an image transmission method and related equipment for uncompressed video. Background Technology

[0002] As the 8K ultra-high-definition television industry chain matures, encompassing all aspects from content production, encoding / decoding, transmission, display to storage, the transmission of 8K ultra-high-definition video has become a crucial technological link. During the production and packaging stages, commonly used tools such as ffmpeg and DaVinci Resolve can package video data into common container formats such as AVI and MOV. However, the uncompressed video directly packaged in this way typically has non-4K aligned video data. When attempting to read and transmit such unprocessed video, traditional reading methods struggle to meet the extremely high data throughput required by high frame rates (e.g., 60 frames per second) at 8K resolution, with reading speeds failing to reach the approximately 6GB / s target, thus creating a transmission bottleneck.

[0003] Currently, traditional software-based methods exist for reading and transmitting uncompressed video. These methods typically rely on general file input / output interfaces, reading video data frame by frame or block by block from the storage device into the system cache, then copying it to the target memory area via the central processing unit, and finally submitting it to the display device for rendering. This method is generally applicable to video files of various container formats, but its data path is not optimized for maximum throughput.

[0004] The aforementioned traditional reading methods have significant drawbacks. Because unprocessed, uncompressed video data is not 4K aligned, and the starting addresses of data blocks on the storage medium are random, the system cannot utilize efficient data transfer mechanisms such as direct memory access in the underlying hardware. Read operations often involve multiple unaligned memory accesses, additional data copying, and higher CPU overhead, all of which severely limit data transfer rates. Therefore, for the extremely large amounts of 8K uncompressed video data, traditional methods cannot achieve stable, real-time, and fast reading and output, failing to meet the high-efficiency transmission requirements of the ultra-high-definition industry.

[0005] To address the speed bottleneck of traditional methods when reading uncompressed video files that are not aligned to 4K, an innovative processing and transmission scheme is urgently needed. This scheme requires the ability to preprocess the raw video files to meet the hardware requirements for efficient transmission, thereby opening up the critical path for high-speed transmission of 8K ultra-high-definition video. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to address the shortcomings of the prior art, specifically by providing a method and related equipment for image transmission of uncompressed video, as detailed below: 1) In a first aspect, the present invention provides an image transmission method for uncompressed video, the specific technical solution of which is as follows: Obtain the uncompressed raw video file, where the video data in the raw video file is not in a 4K aligned state; Obtain the storage address of each frame of image data in the original video file; Based on the storage address of each frame of image data, calculate the number of padding bytes to be inserted before the corresponding frame of image data; Before each frame of image data in the original video file, the calculated number of padding bytes are inserted to generate the target video file, wherein the video data in the target video file is in 4K alignment. Repackage the target video file into an uncompressed video file and store it. Read video data from the stored uncompressed video file into memory without buffering. Output the video data that has been read into memory to the display device.

[0007] The beneficial effects of the uncompressed video image transmission method provided by this invention are as follows: First, the uncompressed raw video file, which is not 4K aligned, is acquired, and the storage address of each frame of image data is obtained through parsing. Based on these addresses, precise padding bytes are calculated and inserted to generate a target video file with 4K aligned video data. This crucial step allows the repackaged and stored uncompressed video file to fully utilize the characteristics of direct memory access for high-speed reading. In subsequent transmission stages, video data from the uncompressed video file can be read into memory without buffering and output to the display device efficiently. The entire process ensures that 8K ultra-high-definition video data can stably meet the high-bandwidth transmission speed requirements, realizing a complete high-speed transmission link from file preprocessing to final display.

[0008] Based on the above scheme, the image transmission method for uncompressed encapsulated video of the present invention can be further improved as follows.

[0009] Furthermore, based on the storage address of each frame of image data, the number of padding bytes to be inserted before the corresponding frame of image data is calculated, including: Set the cumulative padding bytes And initialize it to 0; For each frame of image data in the original video file, perform the following steps: Get the storage address of the current frame ; According to the formula The number of padding bytes to be inserted before the current frame's image data is calculated. ,in, This represents the modulo operation; it is used to calculate the number of padding bytes in the current frame. Then, the cumulative number of filled bytes will be... Updated to and The sum of.

[0010] The beneficial effects of adopting the above-mentioned further scheme are: by dynamically calculating the number of padding bytes, it ensures that each frame of image data in the target video file achieves a strict 4K alignment. The formula calculates the number of padding bytes required for each frame in a systematic way, and the real-time update of the cumulative padding bytes ensures that the frame address after the insertion operation continuously meets the alignment condition. This calculation process eliminates the address deviation that may be introduced by manual estimation or fixed padding, providing an accurate address basis for subsequent high-speed reading using direct memory access, and is a key preprocessing step for achieving efficient transmission of uncompressed encapsulated video.

[0011] Furthermore, the video data in the stored uncompressed video file is read into memory without buffering, including: Taking advantage of the fact that the video data in the uncompressed video file is in a 4K aligned state, the video data blocks in the uncompressed video file are directly read into memory through direct memory access.

[0012] The advantages of adopting the above-mentioned further solution are: fully utilizing the characteristic that video data in uncompressed video files is in a 4K aligned state, and achieving high-speed data transmission through direct memory access. The direct memory access mechanism allows video data blocks to bypass central processing unit intervention and be directly read from storage devices into memory, significantly reducing the number of data copies and system overhead. This direct reading in a cyclic manner can continuously meet the stringent bandwidth requirements of high frame rate video, providing an efficient data supply guarantee for the subsequent stable output of video streams to display devices.

[0013] Furthermore, obtain the storage address of each frame of image data in the original video file, including: Parse the encapsulation structure of the original video file to obtain the storage address of each frame of image data in the original video file.

[0014] The beneficial effects of adopting the above-mentioned further approach are: by parsing the encapsulation structure of the original video file, the storage address of each frame of image data can be accurately obtained. This step provides an accurate address information basis for subsequent calculation of the number of padding bytes, ensuring that the structure of the video data can be recognized and processed by the system. Accurate storage address acquisition guarantees the reliability of subsequent padding operations, enabling the entire processing flow to strictly adhere to the actual organizational form of the video file, thereby establishing the necessary prerequisites for generating a 4K aligned target video file.

[0015] 2) In a second aspect, the present invention also provides an image transmission system for uncompressed video, the specific technical solution of which is as follows: It includes a raw video file acquisition module, a storage address acquisition module, a padding byte count calculation module, a padding byte insertion module, a packaged storage module, an unbuffered reading module, and an output module; The original video file acquisition module is used to: acquire uncompressed original video files, wherein the video data in the original video files is in a non-4K aligned state; The storage address acquisition module is used to: obtain the storage address of each frame of image data in the original video file; The padding byte count calculation module is used to: calculate the number of padding bytes to be inserted before the corresponding frame of image data based on the storage address of each frame of image data; The padding byte insertion module is used to insert the calculated number of padding bytes before each frame of image data in the original video file to generate the target video file, wherein the video data in the target video file is in 4K alignment. The encapsulation and storage module is used to: re-encapsulate the target video file into an uncompressed encapsulated video file and store it; The unbuffered reading module is used to read video data from the stored uncompressed video file into memory without buffering. The output module is used to output the video data that has been read into memory to the display device.

[0016] Based on the above solution, the image transmission system for uncompressed encapsulated video of the present invention can be further improved as follows.

[0017] Furthermore, the padding byte count calculation module is specifically used for: Set the cumulative padding bytes And initialize it to 0; For each frame of image data in the original video file, perform the following steps: Get the storage address of the current frame ; According to the formula The number of padding bytes to be inserted before the current frame's image data is calculated. ,in, This represents the modulo operation; it is used to calculate the number of padding bytes in the current frame. Then, the cumulative number of filled bytes will be... Updated to and The sum of.

[0018] Furthermore, the cacheless read module is specifically used for: Taking advantage of the fact that the video data in the uncompressed video file is in a 4K aligned state, the video data blocks in the uncompressed video file are directly read into memory through direct memory access.

[0019] Furthermore, the storage address acquisition module is used to: parse the encapsulation structure of the original video file and obtain the storage address of each frame of image data in the original video file.

[0020] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor, so as to enable the electronic device to implement any of the above-mentioned uncompressed video image transmission methods.

[0021] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described uncompressed video image transmission methods.

[0022] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is a flowchart illustrating an image transmission method for uncompressed encapsulated video according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of an image transmission system for uncompressed video according to an embodiment of the present invention. Detailed Implementation

[0024] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0025] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0026] like Figure 1 As shown, an embodiment of the present invention provides a method for transmitting uncompressed encapsulated video images, comprising the following steps: S1. Obtain the uncompressed raw video file, where the video data in the raw video file is not 4K aligned. The specific implementation process is as follows: S10. Initialize the file access module to open the uncompressed raw video file from the storage medium or network source. Use standard file input / output functions, such as calling the file open function in a programming language, to obtain the file handle in binary read mode. Verify that the file path is valid and the file is accessible, and ensure that the file handle is not empty for subsequent read operations. If the file comes from a network stream, establish a network connection and buffer the data to simulate file read behavior.

[0027] S11. Read the initial data blocks of the raw video file and parse the container format identifier. Uncompressed raw video files typically have standard container formats such as AVI or MOV. Identify the container format's magic number or identifier by reading a fixed number of bytes at the beginning of the file, such as the first 512 bytes. For example, an AVI file begins with a "RIFF" header followed by an "AVI" identifier. Parse these identifiers to confirm the file is in an uncompressed container format and extract the file structure information.

[0028] S12. Based on the container format specification, deeply analyze the encapsulation structure of the original video file to locate the metadata area of ​​the video data stream. Container formats contain multiple data blocks or lists, such as the "hdrl" and "movi" lists in an AVI file. Using a block-by-block parsing method, read the file header information to find the video data stream descriptor. The video data stream descriptor contains metadata such as the storage format of video frames, frame rate, and frame index. By parsing this metadata, determine the layout of the video data within the file.

[0029] S13. Extract the starting offset of the video data region from the metadata. Assume the file starting address is 0, and the address of the first byte of the video data region is... . This is the byte offset from the beginning of the file to the start of the video data, calculated using a pointer or index field in the encapsulation structure. For example, in an AVI file, the starting position of the "movi" list gives the address of the video data block. Calculation The value is stored as an integer.

[0030] S14. Check if the starting address of the video data area is 4K aligned. Calculate the alignment status using modulo operation. The formula is as follows: in, This is the starting address of the video data region. `mod` indicates modulo operation, and 4096 is the baseline value for 4KB alignment. It is the remainder obtained after taking the modulo. If If the value is not equal to 0, the video data is in a non-4K aligned state. In the implementation, [the following will be used]. If the value is not zero when compared with 0, the flag variable is set to false, indicating an unaligned state.

[0031] S15. Verify whether the non-4K alignment of the video data region persists throughout the entire video sequence. Since video data is stored continuously in frames, if the starting address is misaligned, the addresses of subsequent frames may also be misaligned. This is confirmed by sampling and checking the addresses of subsequent frames. Let the storage address of the first frame image data be... It equals Use the frame index or offset table in the encapsulation structure to obtain the address of subsequent frames, such as the address of the nth frame. Calculate the modulo value of each sample frame address: If all sampled frames If none of the values ​​are 0, then the video data in the entire original video file is confirmed to be non-4K aligned. In the implementation, multiple frames can be randomly selected for verification to ensure the reliability of the conclusion.

[0032] S16. Record the non-4K alignment state and prepare for subsequent processing. Store the alignment state information in a data structure, such as using a Boolean variable. Set to true. Simultaneously, save the handle to the original video file and the parsed metadata for direct use in subsequent steps. Output log information indicating that the video data is not 4K aligned, completing the process of obtaining the uncompressed raw video file.

[0033] Through the above steps, the uncompressed raw video file was obtained, and it was confirmed that the video data within it was not 4K aligned. The entire process is based on file parsing and address calculation, ensuring clear logic and technical feasibility, laying the foundation for subsequent padding byte insertion and 4K alignment processing.

[0034] The original video file is an uncompressed video file, meaning the video data has not been compressed or encoded, but is encapsulated in a container format. Container formats such as AVI or MOV are used to store video streams, audio streams, and metadata. The original video file retains the original pixel information of the video without quality loss, but the file size is large. Uncompressed encapsulation ensures that the video data remains intact during storage and transmission, facilitating subsequent processing.

[0035] The video data in the original video file is the actual sequence of images stored within it, with each frame containing pixel values. Video data is stored in units of frames, and the storage location of each frame can be located using an index within the encapsulation structure. The fact that the video data is not 4K aligned means that the storage address of each frame is not a multiple of 4096 bytes, which can lead to inefficiencies during direct memory access.

[0036] In this context, 4K alignment refers to data in memory or storage where the address is a multiple of 4096 bytes. 4K alignment optimizes data block transfers because many storage systems and memory management units operate in 4KB units. When data is 4K aligned, direct memory access can be performed more efficiently, reducing additional memory copies and address calculations. Conversely, non-4K alignment, where the address is not a multiple of 4096, can lead to performance degradation.

[0037] S2. Obtain the storage address of each frame of image data in the original video file. Specifically, parse the encapsulation structure of the original video file to obtain the storage address of each frame of image data in the original video file. The specific implementation process is as follows: S20. Open and read the header information of the raw video file. Use the binary file reading function provided by the programming language, such as through a file input stream, to open the specified raw video file. Read the fixed-length data at the beginning of the file, such as the first 1024 bytes, into a buffer. This data contains top-level information about the encapsulation structure, used to identify the specific format of the file. For example, for a raw video file in AVI format, the first 12 bytes of the file constitute a RIFF block, and its first 4 bytes are the "RIFF" identifier.

[0038] S21. Based on the read header identifier, determine the specific container format of the original video file and load the corresponding format parsing rules. Different container formats have different structure definitions. For example, after recognizing the "RIFF" identifier, the next 4 bytes can be read, which represents the total file size minus 8 bytes. Then, read the next 4 bytes. If it is the "AVI" identifier, it confirms that this is an AVI format original video file. At this point, the program will define the block identifiers to be searched in the subsequent parsing process according to the AVI format specification, such as the "hdrl" list, the "strl" list, and the "movi" list.

[0039] S22. Systematically traverse the encapsulation structure of the original video file to locate the "strh" and "strf" blocks storing video stream information. The program starts reading data blocks without buffering, immediately following the "AVI" identifier. Each data block is defined by a 4-byte identifier and a 4-byte block size value L. The block size L represents the number of bytes occupied by the data portion of that block. The program navigates by comparing the read identifiers. When the "hdrl" list identifier is read, the program enters this list. Within the "hdrl" list, it continues searching for the "strl" list identifier. The "strl" list contains the header information of the video stream, where the "strh" block describes the video stream type, codec, and frame rate, and the "strf" block describes the format information of the video frames, such as width, height, and bit depth. This information is parsed to confirm the existence and basic attributes of the video stream.

[0040] S23. Locate the main data area storing the actual video data within the encapsulation structure, typically the "movi" list. After parsing the stream header, the program continues scanning the file's data blocks. It skips other irrelevant blocks or lists until it finds the list block identified as "movi". This "movi" list contains interleaved or contiguous video frame data and possible audio data. Record the absolute file offset of the start of the "movi" list data area, denoted as . This address is one of the reference points for calculating the data storage address for each frame of the image.

[0041] S24. Locate and parse the index block, i.e., the "idx1" block, within the container structure. To efficiently obtain the storage address of each frame's image data, many container formats provide an index block at the end of the file or after the "movi" list. In AVI format, this is usually the "idx1" block. The program continues scanning the file, searching for the block identified as "idx1". Once found, the size of that block is read. The data portion of the index block consists of a series of consecutive index entries, each with a fixed length, such as 16 bytes. Each entry describes information about a frame of data (or an audio block), typically including an identifier, a flag value, the offset of the frame in the file, and the size of the frame.

[0042] S25. Traverse each entry in the index block, select the video frame entries, and calculate their absolute storage addresses. The offset in the index entry is usually relative to the start address of the "movi" list data area. The offset. Let the relative offset of the record in the index entry be... Then the absolute storage address of the image data of that frame in the original video file. Calculated using the following formula: in, It is the starting address of the "movi" list data area. This is the offset value read from the index entry. The program needs to check the identifier of each index entry; for example, the identifier for a video frame might be "00db" or "00dc" to distinguish between video frames and audio blocks. The above address calculation is performed only on video frame entries. The calculated absolute storage address for each frame is then used. Frames are stored sequentially in an array or list. For the i-th frame, its storage address is denoted as... .

[0043] S26. Verification and Backup Scheme. If the original video file's encapsulation structure does not contain a standard index block, a backup parsing method is required. The backup method involves starting directly from the "movi" list data area and sequentially scanning and segmenting the data according to the fixed size of the video frames or dynamically calculated sizes based on the frame format described in the "strf" block. The starting address of each frame is inferred by identifying a specific identifier at the beginning of each frame's data or by using size calculations. Regardless of whether the standard index or the backup method is used, the final output is an ordered list containing the precise storage addresses of each frame's image data in the original video file. ,in N is the total number of frames in the video file. This process completes the parsing of the original video file's encapsulation structure and the acquisition of its storage address.

[0044] The container structure of a raw video file refers to the container format used to organize and store multimedia data. Uncompressed raw video files, such as those in AVI or MOV formats, typically have a container structure consisting of a series of nested data blocks or lists. These structures include a file header, stream header, video frame index, and the actual media data blocks. The purpose of the container structure is to describe the arrangement, encoding format, timestamps, and storage location of the video stream, audio stream, and metadata, enabling the player or processing program to correctly locate and read each frame of image data. Parsing this container structure involves interpreting the information in these data blocks layer by layer according to the format specifications to find the precise area where the video data is located and the boundaries of each frame.

[0045] The storage address refers to the byte offset of the first byte of each frame's image data relative to the beginning of the file in the original video file. It is a non-negative integer value used to uniquely identify the location of a frame in the file. Using the storage address, the program can directly use file location functions to jump to the specified location, read the corresponding number of bytes, and thus obtain the complete frame's image data. Obtaining the storage address of each frame's image data is fundamental for subsequent 4K alignment padding and efficient memory access.

[0046] S3. Based on the storage address of each frame of image data, calculate the number of padding bytes to be inserted before the corresponding frame of image data. Specifically: Set the cumulative padding bytes And initialize it to 0; For each frame of image data in the original video file, perform the following steps: Get the storage address of the current frame ; According to the formula The number of padding bytes to be inserted before the current frame's image data is calculated. ,in, This represents the modulo operation; it is used to calculate the number of padding bytes in the current frame. Then, the cumulative number of filled bytes will be... Updated to and The sum of.

[0047] The specific implementation process of S3 is as follows: S30. Initialize the cumulative padding bytes and frame data list. Before starting the calculation, the program needs to obtain an ordered list from memory or configuration. This list contains the storage addresses of each frame of image data parsed from the original video file's encapsulation structure. Assuming the video file has a total of N frames, this address list is denoted as... ,in This represents the starting byte address of the i-th frame's image data in the original video file. Simultaneously, a variable named `cumulative padding bytes P` is declared and initialized to 0. `cumulative padding bytes P` will dynamically record the total number of padding bytes inserted for all previous frames before processing the current frame. The program also needs to prepare a new array or list of the same length as the number of frames to store the padding bytes `S` calculated for each frame.

[0048] S31. Begin sequentially traversing each frame of image data. The program enters a loop, with the loop variable i starting from 1 and incrementing gradually to N. In each loop iteration, the current frame is processed. The purpose of the loop is to independently calculate the number of padding bytes to be inserted before each frame of image data in the original video file.

[0049] S32. Obtain the memory address of the current frame. Within the loop, the program reads the corresponding address value from the memory address list based on the index of the current loop variable i. Specifically, the i-th element in the address list is assigned to a temporary variable, which represents the memory address A of the current frame. (Using mathematical notation...) This indicates that an operation is being performed. At this point, variable A stores a precise, non-negative integer that points to the beginning position of the i-th frame of data in the original file.

[0050] S33. Calculate the number of padding bytes in the current frame. This is a crucial step in the calculation process. The formula involves three key values: the memory address A of the current frame, the total number of padding bytes P up to the previous frame, and the alignment modulus 4096. The complete form of the formula is as follows: in, This represents the calculated number of padding bytes that need to be inserted before the current frame's image data. This indicates the storage address of the current frame being retrieved. This represents the current value of the cumulative padding bytes while processing the current frame. Its initial value is 0, and it is updated after processing each frame. This represents the modulo operation, i.e., calculating... The remainder after dividing by 4096. The number 4096 represents the size of a 4K-aligned byte boundary. The calculation process begins with addition. This yields a new address offset that simulates the expected starting position of the current frame data in the new file, taking into account all previously inserted padding bytes. Then, a modulo operation is performed on this expected starting position. This yields a remainder value between 0 and 4095. This remainder represents the number of bytes offset from the expected starting position to the previous 4K alignment boundary. Finally, subtracting this remainder from 4096 gives the number of bytes needed to align the expected starting position to the next 4K boundary, i.e., the padding bytes S. A special boundary case needs to be handled: if... The result is exactly 0, so according to the formula, This means the expected address is already aligned and theoretically no padding is needed. However, in actual data writing, inserting 4096 padding bytes will disrupt the alignment. Therefore, the program must correct this situation. The correct logic is: when the modulo operation result is equal to 0, force the padding byte count S to be set to 0, instead of 4096. This can be achieved through a conditional statement.

[0051] S34. Update the cumulative padding byte count P. After calculating the padding byte count S of the current frame, the program must update the cumulative padding byte count P to ensure that the value of P in the formula accurately reflects all padding bytes inserted up to the current frame when processing the next frame. The update operation follows a simple accumulation rule: in, This represents the cumulative number of padding bytes before the update, which is the P value used when calculating S in the previous step. It is the number of padding bytes just calculated for the current frame. This represents the cumulative padding bytes after the update. The program performs the assignment operation. The value of variable P is updated to the sum of the two values. This new value of P will be used when calculating the number of padding bytes for the next frame (frame i+1).

[0052] S35. Save the calculation result of the current frame and loop. The program stores the calculated number of padding bytes S into the i-th position of the pre-prepared result list. Then, the loop variable i is incremented by 1, and the program jumps back to S32 to start processing the next frame image data in the original video file, repeatedly executing the operations of obtaining the address, calculating the number of padding bytes, and updating the cumulative value.

[0053] S36. Traversal Completion and Result Output. When the value of the loop variable i is greater than the total number of frames N, it indicates that the processing of all frames has been completed. The loop ends. At this point, the result list sequentially stores the number of padding bytes calculated for each frame of image data. The final value of the cumulative fill bytes P is also equal to the sum of all S values, that is... This list of results and the final P value will be passed to the module that generates the target video file to guide the actual insertion of padding bytes.

[0054] Padding bytes are meaningless bytes inserted into the original data stream to meet specific data alignment requirements. In the specific implementation of the image transmission method, padding bytes are inserted before each frame of image data in the original video file. These bytes typically contain zeros or a fixed set of arbitrary values; they do not contain any valid image information. The purpose of inserting padding bytes is to adjust the starting storage address of each frame of image data in the newly generated target video file, ensuring that the adjusted video data as a whole meets 4K alignment. Through alignment, the system can utilize hardware acceleration features for efficient data block transmission, thereby improving the overall performance of image transmission.

[0055] S4. Insert the calculated number of padding bytes before each frame of image data in the original video file to generate the target video file. The video data in the target video file is 4K aligned. The specific implementation process is as follows: S40. Preparing Input Data and Creating the Target File. The system receives two key inputs from the upstream processing module: one is the parsed raw video file data, and the other is a list of padding bytes calculated for each frame. The raw video file data contains complete encapsulation structure information and a sequentially stored stream of frame image data bytes. The padding byte list is a sequence of N integers, denoted as... ,in This represents the number of padding bytes to be inserted before the image data in frame i, where N is the total number of video frames. Simultaneously, a completely new, blank binary file is created as the target video file, and its write handle is obtained. A padding byte array, containing all zeros and at least 4096 bytes in length, is also required as the source of padding data during writing.

[0056] S41. Copy and reconstruct the header of the target video file. Read the header portion of the original video file. The header includes all metadata describing the video stream, audio stream, and global information, such as lists and blocks like "RIFF," "hdrl," and "strl" in AVI format. Copy this header data to the beginning of the target video file as is. However, the total size of the video data portion will change due to subsequent insertion of padding bytes. Therefore, the fields in the header related to the total file size and video data block size must be modified. Specifically, locate the field describing the size of the "movi" list or the total size of the "RIFF" blocks based on the original header structure, and add the original value to the sum of all padding bytes (i.e., ...). After that, update the value of this field. This step ensures that the container structure of the target video file logically correctly describes the subsequently increased data volume.

[0057] S42. Initialize the write offset and locate the data start point. In the target video file, after the file header is copied, the current write position is the start point of the video data area. Record this position offset as . It initializes its value to the address of the first byte after the end of the file header. At the same time, in the original video file, it locates the address where the actual frame image data begins, that is, the beginning of the first data block in the "movi" list, and prepares to read each frame image data sequentially from it.

[0058] S43. Process each frame of image data in a loop to perform the insertion operation. Start a loop from 1 to N, processing frame by frame. For the i-th frame in the loop, the operation consists of two sub-steps: writing padding bytes and writing the frame image data. First, retrieve the padding byte count from the list. The value of . If Then, extract the first byte from the zero-padded byte array. Each byte is written sequentially to the current write position in the target video file. This write operation shifts the write position of the target file forward. Bytes. Next, the i-th frame of image data is read from the original video file. The size of this frame data... This was already known during the parsing of the encapsulation structure. The storage address of this frame is from the original file. At this point, read consecutively 1 byte, then this Each byte is written intact to the current position of the target video file. After writing, the write position in the target file is then shifted forward. One byte. After writing one frame, the layout in the target file becomes: padding bytes (possibly zero) followed by a complete frame of image data.

[0059] S44. Verify and Maintain 4K Alignment. To ensure the video data in the target video file is 4K aligned, verification needs to be performed during or after processing. Verification is performed after each frame of image data is written. After the i-th frame of image data is written, the starting storage address of that frame in the target file is calculated. This starting address is equal to the file offset before the data of that frame was written, which is the position after the padding bytes were written. Let the total cumulative write amount before the i-th frame (including all file headers, padding bytes of all previous frames, and data) be... Then the starting address of the i-th frame image data in the target file is... .calculate The value of this value. By design, this calculation result must be 0, indicating that the starting address of each frame of image data is an integer multiple of 4096 bytes. This property is achieved by strictly following the previous steps to calculate the number of padding bytes. This is ensured by the insertion process. The verification result can be logged to confirm successful alignment.

[0060] S45. Processing Subsequent Encapsulation Structures and Completing File Writing. Once all N frames of image data and their corresponding padding bytes have been written to the target video file, the main body of the video data is complete. Next, it's necessary to copy other necessary encapsulation structure parts located after the video data area in the original video file. For example, the "idx1" index block in an AVI file. Since the position of each frame in the target file has changed, this index block must be rebuilt. The new index entries need to be based on the new starting address of each frame's image data in the target file (i.e., the address after padding alignment) and the original frame size. This process generates and reconstructs the new index block, writing it to the end of the target video file. Finally, the write handle to the target video file is closed.

[0061] S46. Final Verification and Output. After generating the target video file, a final verification can be performed. The program can reopen the target video file, randomly select several frames, read their storage addresses, and calculate the modulo operation to confirm that the results are all 0. Simultaneously, the integrity of the file header is verified. After all verifications pass, the target video file is considered successfully generated. The video data in this target video file is 4K aligned, and its internal encapsulation structure is correct, preparing it for the next step of efficient direct memory access transfer.

[0062] S5. Repackage the target video file into an uncompressed video file and store it. The specific implementation process is as follows: S50. Receive the generated target video file as input. This target video file contains a data body that has been padded and adjusted, with the video data in 4K alignment. However, some fields of its internal encapsulation structure may still be temporary values ​​based on the original file layout, which need to be corrected to form a complete, standard uncompressed encapsulated video file. Open the target video file in binary read mode and load all its contents or key parts into the memory buffer for parsing and modification. Simultaneously, create a new binary file as the final output, re-encapsulated uncompressed encapsulated video file, and obtain its write handle.

[0063] S51. Parse the existing encapsulation structure of the target video file and extract key parameters. Following the specifications of uncompressed video encapsulation formats (such as AVI), parse the existing structure of the target video file in memory. This process aims to accurately read and record all the information required for subsequent reconstruction. Key information includes: 1) the identifier and initial size field position of the main file header; 2) the frame rate, total number of frames N, etc., in the video stream header (strh block); 3) the image width, height, bit depth, etc., in the video stream format header (strf block); 4) the starting offset O_m of the "movi" list data area and its contained, aligned image data blocks for each frame; 5) the position and content of old, potentially invalidated index blocks (such as the idx1 block). Specifically, it is necessary to reconfirm the accurate starting address A'_i and size F_i of each frame image data within the target file from the "movi" list by scanning identifiers (such as "00db") and the known frame size F_i. Where i = 1, 2, ..., N.

[0064] S53. Update the size fields in the main file header and stream header. Due to the insertion of padding bytes, the total file size and the size of the "movi" list data area have changed. The corresponding fields in the encapsulation structure must be modified. First, locate the field in the main file header that describes the total file size. In many encapsulation formats, there is a total size field at the beginning of the file, such as the DWORD immediately following the "RIFF" identifier in RIFF format. Let the original total size be... The sum of all padding bytes is The total size of the new file The calculation formula is: in, This is the final value of the previously calculated cumulative padding bytes P. Its size may also change if the index block itself is completely rebuilt due to address changes. This represents the size difference between the old and new index blocks. It is calculated using... The corresponding field in the main file header is updated. Next, the size field of the "movi" list is located and updated, its new size equal to the original "movi" data size plus... .

[0065] S54. Reconstruct the file index structure. A standard uncompressed video container file typically contains an index for fast random access to frame data. Since the address A'_i of each frame's image data in the target file is different from that in the original file, the index must be reconstructed. Create new index block data according to the format specification. For each frame's image data, generate an index entry. Each entry typically contains: a four-character code identifier for the frame data (e.g., "00db"), flags (e.g., keyframe flags), the offset of the frame data within the file, and the size F_i of the frame data. Here, the offset must be filled with the absolute address of the frame in the final repackaged file or a relative address relative to the start of the "movi" list. If a relative address is used, assuming the start of the "movi" list data area in the final file is O_m, then the relative offset R_i of the i-th frame is: Arrange the index entries of all N frames sequentially to form a new index data block. Then, update the pointers or size information pointing to the index block in the encapsulation structure to ensure consistency.

[0066] S55. Write the complete repackaged file structure. Begin writing data to the final uncompressed encapsulated video file. The writing order strictly adheres to the hierarchical structure of the encapsulation format. First, write the main file header with the total size field updated. Second, write the global information header, video stream information header (strh), and video stream format header (strf) in sequence. These header contents remain unchanged except for the size-dependent fields. Third, write the list header of the "movi" list, followed by the entire "movi" list data area. This data area is copied directly from the corresponding memory area in the target video file, as it already contains the correct padding bytes and frame data sequence. Fourth, write the newly constructed index block. Fifth, check the format specifications and write any necessary end-of-file padding or closing markers. Throughout the writing process, ensure that all data blocks meet format details such as four-byte alignment.

[0067] S56. Perform storage operation and close file. After all the data of the complete uncompressed video file has been written to the output file, a storage operation is performed. This includes calling the operating system's file system interface to ensure that all contents of the write buffer are flushed to the physical storage medium. Then, the write handle of the output file is safely closed. At this point, a brand new, re-encapsulated uncompressed video file is generated in the specified file system path. This file has a complete encapsulation structure, correct internal indexing, and the video data is maintained in 4K alignment.

[0068] S57. Post-Verification and Integrity Check. After storage, optional post-verification can be performed to ensure successful repackaging. The newly generated file can be reopened to quickly parse its main header and index block, verifying the correctness of key field values. For example, several frames can be randomly selected, their storage addresses read from the index entries, and the address modulo 4096 calculated to confirm 4K alignment. Simultaneously, the total file size is verified to match the theoretically calculated value. The verification is successful. After verification, a log can be recorded to confirm that the process of "re-encapsulating the target video file into an uncompressed video file and storing it" has been successfully completed, and the file is ready for use by the subsequent unbuffered reading and transmission modules.

[0069] S6. Read the video data from the stored uncompressed, 4K-aligned video file into memory without buffering. Specifically, taking advantage of the 4K alignment of the video data in the uncompressed video file, the video data blocks are directly read into memory using direct memory access. The specific implementation process is as follows: S60. Upon startup, a connection needs to be established and configured with the Direct Memory Access Engine (DMI) in the computer system. The DMI is a subsystem that allows peripheral hardware devices to directly read and write to the system's main memory independently of the central processing unit (CPU). By calling the driver interface provided by the operating system kernel, the program obtains a control handle for an available DMI channel and sets its operating mode, such as memory-to-memory transfer or direct read from storage devices into memory. After initializing the DMI, the program opens the uncompressed video file that has undergone repackaging. The video data in this file is 4K aligned, a fundamental condition for efficient DMI transfer. The program needs to parse the encapsulation structure of the uncompressed video file, especially the index block at the end of the file. Through parsing, the program extracts key metadata parameters: the total number of video frames contained in the uncompressed video file, denoted as... For each frame of image data, obtain its starting storage address in the current file after 4K alignment adjustment, denoted as . , where subscript Indicates the frame number. Simultaneously, the original size of each frame of image data before compression is obtained, denoted as . These parameters , and This will serve as the basis for subsequent planning and initiation of all direct memory access transfer tasks.

[0070] S61. To receive video data transmitted via direct memory access, the program must pre-allocate a contiguous physical memory region in the system's main memory as a buffer. This buffer acts as "multiple fixed-size storage spaces" to temporarily store image data blocks read from the file, forming a pipeline between reading and display. The program first determines the number of video frame data buffer units that need to be maintained in memory simultaneously, denoted as . . It is a fixed positive integer set based on the system's available physical memory capacity, video frame size, and pipeline parallelism requirements. For example, it can be set to... Next, the program needs to determine the size of each memory buffer unit, denoted as . Each frame of image data actually occupies the same amount of space as its original size in the file. In addition to the padding bytes inserted before it to achieve 4K alignment For ease of and efficiency in memory management, all memory buffer units allocated by the program use a uniform size. . The value should be set to an integer multiple of the system memory page size (typically 4KB, or 4096 bytes) and must be greater than or equal to the size of all frames. The maximum value is selected to ensure that any aligned data block can fit completely into a memory buffer unit. The program requests memory by calling the memory allocation application programming interface with alignment capabilities, specifying the total number of bytes required. The returned memory address must be physically 4K aligned. Assuming successful allocation, the starting address of the obtained memory buffer is denoted as... It meets the conditions This contiguous buffer was then logically divided into... Each unit is the same size. The starting address of each memory buffer unit It can be calculated using the following formula: in, .because and All are multiples of 4096 bytes, therefore each It is naturally a 4K aligned address.

[0071] S62, uncompressed video files have video data that is 4K aligned. This characteristic means that the video data from the file address... Start, to the starting address of all subsequent frames Each address value is a multiple of 4096 bytes. Therefore, the entire video data region can be viewed as a series of consecutive data blocks with naturally aligned starting addresses. For the... The frame image data, and the "aligned data block" it occupies in the file, not only contains the effective pixel information of that frame (size is...) (bytes), and also includes padding bytes inserted in front of it (size is...) (bytes). Therefore, the total size of this aligned data block Defined as: Insert padding bytes The purpose is to ensure The result is equal to ,and Satisfies 4K alignment. Therefore, each Numerically, this ensures the start of one alignment boundary and the end of the next. The program now needs to calculate the precise parameters required by the Direct Memory Access engine for the transmission of each frame of image data. For the data to be transmitted to the next... The first memory buffer unit For frame data, the source address for transmission is the 4K-aligned start address of that frame in the file. The destination address for transmission is the first... The starting address of each memory buffer unit The number of bytes that need to be transmitted is the total size of this aligned data block. Due to the source address and target address They are all 4K aligned, and the transmission length is... It is also an integer multiple of 4096 bytes (or at least guarantees that the transfer will not cross misaligned boundaries), which provides optimal transfer conditions for the direct memory access controller, enabling the highest bus utilization and the fastest transfer speed.

[0072] S63. The Direct Memory Access engine defines individual transfer tasks using a data structure called a "transfer descriptor." A transfer descriptor typically contains fields such as source address, destination address, number of bytes to transfer, and control flags. The program needs to prepare a set of such transfer descriptors for upcoming loop read operations. The program establishes a circular buffer management mechanism for this. This mechanism maintains two important index pointers: the write index... and reading index Their value range is arrive The initial values ​​are all set to Write to index Points to the index of the next memory buffer unit in the circular buffer that is available for the direct memory access engine to fill with data. Read index. This points to the sequence number of the next memory buffer unit in the circular buffer to be retrieved and displayed by the sequence display module. Before initiating the transfer, the program needs to initialize the preceding memory location. A direct memory access transfer descriptor is used to pre-fill the data. For sequence numbers... from arrive (Corresponding memory buffer unit) ), program configuration One transport descriptor: Set the source address to Set the target address to Set the number of bytes to be transmitted. During configuration, the program sets specific control flags, such as disabling CPU cache intervention during transfer (i.e., unbuffered reads), and allowing interrupts or completion status flags to be generated upon completion of the transfer. Once each descriptor is configured, it is submitted to the Direct Memory Access engine's processing queue.

[0073] S64, When the first batch After all Direct Memory Access (DMI) transfer descriptors have been configured and submitted, the program sends a start command to the DMI engine. The DMI controller then begins operating independently, sequentially accessing the uncompressed video files from their designated aligned addresses according to the descriptor queue. At that point, read the precise Bytes of data are then written directly to a specified, 4K-aligned memory address via the system bus. During the entire data transfer process, the central processing unit (CPU) does not need to participate in data handling and can be freed up to perform other tasks, such as processing graphical user interface events or preparing display instructions for the next stage. Whenever a transfer task corresponding to a direct memory access (DMI) transfer descriptor completes, the DMI controller, according to its settings, triggers an interrupt signal or updates a completion status bit in memory. The program's interrupt service routine or a dedicated monitoring thread will detect this event. Once the first... Once the data in each memory buffer unit is filled, the program updates and writes the index. This makes it point to the next position in the circular buffer, i.e. Meanwhile, continuously check the read index. The memory buffer unit it points to. If this unit is marked as "data ready," the display module retrieves data from that memory address. The frame image data is extracted and displayed.

[0074] S65. After the sequence display module finishes displaying the frame image data in a certain memory buffer unit, the storage space occupied by that memory buffer unit can be released to receive new video data. This embodies the core idea of ​​"releasing the storage space occupied by the single frame image data after display output and waiting for the next round of reading multiple consecutive single frame image data". The specific operation of the program here is: after the display module finishes using the data from the read index... After pointing to the buffer unit, the program marks that unit as "free". Then, the program increments the index to read the buffer. Next, the program needs to schedule the next direct memory access read task for this newly freed buffer unit. The program determines the sequence number of the next frame to be read based on the total number of frames already processed. ( Then, the program calculates the transmission parameters of the frame: source address. The target address is the address of this free buffer unit. Number of bytes transmitted The program dynamically creates a new Direct Memory Access (DMI) transfer descriptor, fills in the parameters and control flags, and submits it to the DMI engine's queue. After completing its current task, the DMI engine automatically retrieves the new task from this queue and executes it, thus transferring the current task to the next queue. The aligned data blocks of the frame are read directly into the memory buffer that was just freed. This process continues in a continuous loop, with reading and display output forming a highly efficient pipeline. Multiple fixed-size memory storage spaces are reused in a fixed cycle of "filling data, displaying output, releasing space, and then filling data again." Because the source and destination of each data transmission strictly meet 4K alignment, the Direct Memory Access Controller can always operate the data bus in the most efficient way, avoiding the performance penalty caused by unaligned access, thus achieving stable and efficient large-scale video data stream transmission.

[0075] S66. The program repeatedly executes the loop described in S64 and S65: starting transmission, waiting for completion, displaying output, releasing the buffer, and resubmitting the transmission task. This loop continues until all data in the uncompressed video file is processed. All aligned data blocks corresponding to the frame image data are read into the memory buffer via direct memory access and then displayed by the sequence display module. Throughout the loop, the CPU's responsibilities are simplified to task scheduling, buffer state management, and display control; the heavy data transfer work is entirely handled by the direct memory access engine, greatly improving the overall system efficiency and responsiveness. After all frames have been processed, the program sends a stop command to the direct memory access engine and waits for all submitted transfer tasks to complete. Subsequently, the program unconfigures all direct memory access transfer descriptors, releasing the memory occupied by the descriptors. Finally, the program safely releases the memory previously allocated in S61, with a size of [missing information]. The entire memory buffer of bytes is closed, the control handle of the direct memory access channel is closed, and the handle of the uncompressed video file is closed. At this point, the video data blocks from the uncompressed video file are directly read into memory.

[0076] S7. Output the video data that has been read into memory to the display device. The specific implementation process is as follows: S70. Initialize the display device interface and query the display mode. Before outputting video data, a communication link must be established with the display device. The display subsystem is initialized by calling the graphics device interface or the application programming interface provided by the underlying display driver. This process includes opening a connection to the display device and obtaining a handle or context representing the display device. Next, the currently supported display modes of the display device are queried, including resolution, refresh rate, and pixel format. For example, it is necessary to confirm whether the display device supports a display mode that matches the video data, such as 1920x1080 resolution, 60Hz refresh rate, and RGB24 or YUV420 pixel format. Based on the video stream format header information stored in the uncompressed video file, a compatible display mode is selected or negotiated and set up, preparing for subsequent frame data transmission.

[0077] S71. Allocating and Preparing Display Buffers. Modern display devices typically employ double buffering or page-flipping techniques to prevent screen tearing. Buffers for display need to be allocated from graphics memory or shared system memory. These buffers must be accessible to the display device and ideally meet specific memory alignment requirements. Allocate at least two display buffers that match the resolution and pixel format of the current display mode. Let the size of each display buffer be... The calculation formula is as follows: in, Indicates the horizontal pixel width of the display mode. Indicates the vertical pixel height of the display mode. This indicates the number of bytes occupied by each pixel, which depends on the pixel format. For example, for RGB24 format, Ensure that the starting address of the allocated display buffer is 4K aligned in memory, consistent with the alignment characteristics of the video data already read into memory, facilitating subsequent rapid data movement or direct referencing. Label these two buffers as the front buffer and the back buffer, respectively.

[0078] S72. Establish a data path between the video data memory and the display buffer. The video data already read into memory is stored in a dedicated memory area filled with direct memory access operations. The starting address of this area is denoted as... The video data is stored frame by frame, and the starting offset of the i-th frame of video data in this region is... Each frame of data needs to be output to the display device's back buffer. There are two main paths to achieve this. The first path is memory copying; if the display device requires the data to reside in a specific graphics memory location, the data needs to be copied from... The address to copy the position to the current back buffer The amount of data copied is the size of one image frame. Since both the source and destination addresses may maintain 4K alignment, this copy operation can be efficiently performed by the CPU or continue using the direct memory access controller. A second path is address remapping or direct transfer, where the memory region containing the video data can be directly transferred if the display driver supports it. The physical page frame number is used to inform the display device, along with the offset for each frame. This allows the display controller to read data directly from this memory area, thus saving copying overhead. The optimal path is selected based on hardware and driver support.

[0079] S73. Implement display synchronization and timing control. Smooth video output requires the frame rendering rate to be synchronized with the display device's refresh rate. Before starting the output loop, acquire the display device's vertical synchronization signal event or the corresponding synchronization object. During the processing of each frame, perform a wait operation until the next vertical synchronization signal arrives. Let the display device's refresh cycle be... Seconds, for example, for a 60Hz refresh rate, Milliseconds. The goal is in every... The preparation and submission of one frame of data is completed within the interval. A high-precision timer is used to manage this loop. At time points... This ensures that the k-th frame of video data is ready in the back buffer, and then issues a page flip command when the vertical sync signal is triggered.

[0080] S74. Perform a page flip operation to update the display. When the back buffer is filled with the complete next frame of video data and the vertical sync signal arrives, the page flip function is called through the display application programming interface. This function swaps the address of the back buffer with the address of the display controller scanning the front buffer. After the operation is complete, the original back buffer becomes the new front buffer, and its contents are scanned by the display device and displayed on the screen; while the original front buffer becomes the new back buffer, used to prepare for the next frame of video data. This swap operation is atomic, usually completed at the hardware level, ensuring that the display update is completed instantly and avoiding screen tearing. After calling page flip, the internal buffer pointer needs to be updated.

[0081] S75. Handling Pixel Format Conversion and Scaling. The original pixel format of the video data read into memory may not be entirely consistent with the pixel format required by the display device. For example, the video data may be in YUV420 planar format, while the display device requires RGB24 interleaved format. In this case, pixel format conversion needs to be performed before or simultaneously with sending the data to the display buffer. This conversion process can run on the central processing unit (CPU) or be offloaded to the graphics processor's shaders or a dedicated video processing unit, the latter being more efficient. Similarly, if the video resolution differs from the display resolution, image scaling is also required. These processing operations should be integrated as an optional step in the data path. The processed result data is written to the current back buffer.

[0082] S76. Managing the output loop and resource release. The video output process is a continuous loop, from the first frame to the last frame, and may loop continuously. Maintain a frame index. Its value increments from 1 to the total number of frames N, and resets to 1 after reaching N. In each loop iteration, the following sub-operations are executed sequentially: based on the index... Calculate source data offset Wait for the vertical synchronization signal; transmit or process the i-th frame of video data to the back buffer through the predetermined path; execute the page flip command; increment the frame index. Simultaneously, it monitors user input or control signals to respond to pause, stop, or exit commands. When the video output task is finished, resources are released sequentially: any established direct memory access mappings are released, the display buffer is released, the connection to the display device is closed, and the memory area allocated for the video data is released. Through these steps, the entire process of stably, efficiently, and synchronously outputting the video data read into memory to the display device is completed.

[0083] Suppose we have an uncompressed raw video file named raw_video.avi. The video format is YUV420, the resolution is 1920x1080, the frame rate is 30 frames per second, and the total duration is 10 seconds, so the total number of frames N = 300 frames. In the AVI container format, the starting address of its video data (stored in the "movi" list) is not an integer multiple of 4096 bytes, meaning it is not 4K aligned. The specific steps are as follows: S201. Obtain the original video file that is not aligned to 4K: The file raw_video.avi was read from the storage disk. Parsing its header confirmed that it was a video using uncompressed encoding (such as YUV) and encapsulated within an AVI container. Further inspection revealed that the starting address of its video data block was 0x1234 (hexadecimal). Calculating 0x1234 mod 4096 resulted in a non-zero value, verifying that the video data in the original video file was indeed not 4K aligned.

[0084] S202. Parse the encapsulation structure and obtain the storage address of each frame: The encapsulation structure of raw_video.avi is analyzed in depth according to the AVI format specification. It locates the "movi" list and the "idx1" index block at the end of the file. By traversing the index block, the storage address of each frame of image data in the file is obtained. For example, the storage address of the first frame of image data is A1 = 0x1234, the storage address of the second frame of image data is A2 = A1 + frame 1 size, ..., the storage address of the 300th frame of image data is A300. The size of each frame is fixed at 1920 * 1080 * 1.5 bytes = 3,110,400 bytes (YUV420 format).

[0085] S203. Calculate the number of padding bytes to be inserted before each frame: Initialize the cumulative padding bytes P = 0. Then, calculate for each frame. Specifically, for frame 1: memory address A = 0x1234. Calculate S1 = 4096 - ((0x1234 + 0) mod 4096). Assume the result S1 = 0xF00 (i.e., 3840 bytes). Update P = 0 + 3840 = 3840. For frame 2: memory address A = A2. Calculate S2 = 4096 - ((A2 + 3840) mod 4096). S2 may be 0 or other values ​​(e.g., 200 bytes). Update P = 3840 + 200 = 4040. Repeat this calculation for all 300 frames, obtaining a series of padding values ​​S1, S2, ..., S300, and the final cumulative value. .

[0086] S204. Insert padding bytes to generate a 4K aligned target video file: A new target video file is created. It first copies the header information of the original file and updates the relevant size fields. Then, it reads the first frame of image data from the original file, but before writing it to the new file, it first writes S1 (3840 bytes) of zero-padding data, then writes the 3,110,400 bytes of image data for the first frame. Next, it writes S2 (200 bytes) of padding, then writes the second frame data, and so on, until all 300 frames have been processed. In the final generated file, the starting address of each frame of image data satisfies address mod 4096 = 0, meaning the video data is 4K aligned. This file is temporarily stored as an intermediate file.

[0087] S205. Repackage the video file into an uncompressed container and store it. Based on the 4K aligned intermediate file, a complete, standard uncompressed containerized video file is reconstructed. This includes rebuilding the "idx1" index block according to the new frame addresses and updating the fields in the AVI file header regarding the total file size and the size of the "movi" list. Finally, a fully compliant uncompressed containerized video file named aligned_video.avi is generated and stored on disk. The content of this file is completely identical to the original video, only slightly larger in size due to padding bytes, and the data structure has been optimized for efficient reading.

[0088] S206, Utilizing 4K alignment features, reads data into memory without caching: When playback is needed, the aligned_video.avi file is opened. Since its internal video data is known to be 4K aligned, the file is mapped into the process's virtual address space using memory mapping or direct I / O. Then, a playback loop is started. For each frame, it utilizes direct memory access (DMI) technology. Because the frame data's starting address is naturally aligned to the 4096-byte boundary in memory, the entire frame data can be efficiently transferred directly from the mapped memory area to the graphics buffer prepared for display without much CPU intervention. This aligned reading method greatly reduces the number of memory copies and CPU overhead.

[0089] S207. Output the video data in memory to the display device: The video data (YUV420 format) already read into the graphics buffer is converted in real time into the RGB signals required by the display driver or graphics processing unit (GPU). In conjunction with the display's vertical sync signal, the buffer containing each frame's data is submitted to the display device for rendering, ultimately presenting a smooth 1080p video on the screen.

[0090] As demonstrated by this example, the core innovation of this method lies in transforming a previously cluttered, uncompressed video into a standard file with fully 4K-aligned video data blocks by pre-computing and inserting padding bytes. While this preprocessing step adds a small amount of storage space, it significantly improves transmission performance: in the final reading stage, it fully leverages the hardware advantages of direct memory access, achieving high-throughput, low-latency transmission of video data from storage media to memory (and even graphics memory), thus providing an efficient solution for real-time playback or processing of high-quality, uncompressed video. The entire process starts with file reassembly and ultimately optimizes the efficiency at the end of data transmission, forming a complete technological closed loop.

[0091] In the above embodiments, although the steps are numbered S1, S2, etc., they are only specific embodiments given by the present invention. Those skilled in the art can adjust the execution order of S1, S2, etc. according to the actual situation. The scheme after adjusting the order is also within the protection scope of the present invention. It can be understood that in some embodiments, some or all of the above embodiments may be included.

[0092] like Figure 2 As shown, an image transmission system 200 for uncompressed encapsulated video according to an embodiment of the present invention includes an original video file acquisition module 201, a storage address acquisition module 202, a padding byte count calculation module 203, a padding byte insertion module 204, an encapsulation storage module 205, an unbuffered reading module 206, and an output module 207. The original video file acquisition module 201 is used to: acquire an uncompressed original video file, wherein the video data in the original video file is in a non-4K aligned state; Storage address acquisition module 202 is used to: acquire the storage address of each frame of image data in the original video file; The padding byte count calculation module 203 is used to: calculate the number of padding bytes to be inserted before the corresponding frame of image data based on the storage address of each frame of image data; The padding byte insertion module 204 is used to: insert the calculated number of padding bytes before each frame of image data in the original video file to generate a target video file, wherein the video data in the target video file is in a 4K aligned state; The encapsulation and storage module 205 is used to: re-encapsulate the target video file into an uncompressed encapsulated video file and store it; The unbuffered reading module 206 is used to: read video data from the stored uncompressed video file into memory without buffering; The output module 207 is used to output the video data that has been read into memory to the display device.

[0093] Optionally, in the above technical solution, the padding byte count calculation module 204 is specifically used for: Set the cumulative padding bytes And initialize it to 0, For each frame of image data in the original video file, perform the following steps: Get the storage address of the current frame ; According to the formula The number of padding bytes to be inserted before the current frame's image data is calculated. ,in, This represents the modulo operation; it is used to calculate the number of padding bytes in the current frame. Then, the cumulative number of filled bytes will be... Updated to and The sum of.

[0094] Optionally, in the above technical solution, the cacheless read module 206 is specifically used for: Taking advantage of the fact that the video data in the uncompressed video file is in a 4K aligned state, the video data blocks in the uncompressed video file are directly read into memory through direct memory access.

[0095] Optionally, in the above technical solution, the storage address acquisition module 205 is used to: parse the encapsulation structure of the original video file and obtain the storage address of each frame of image data in the original video file.

[0096] It should be noted that the beneficial effects of the uncompressed video image transmission system 200 provided in the above embodiments are the same as those of the uncompressed video image transmission method described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0097] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-described uncompressed video image transmission methods.

[0098] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described uncompressed video image transmission methods.

[0099] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0100] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for transmitting uncompressed video images, characterized in that, include: Obtain an uncompressed raw video file, wherein the video data in the raw video file is in a non-4K aligned state; Obtain the storage address of each frame of image data in the original video file; Based on the storage address of each frame of image data, calculate the number of padding bytes to be inserted before the corresponding frame of image data; Before each frame of image data in the original video file, a calculated number of padding bytes are inserted to generate the target video file, wherein the video data in the target video file is in a 4K aligned state; The target video file is repackaged into an uncompressed video file and stored. The video data in the uncompressed video file is read into memory without buffering from the stored uncompressed video file. Output the video data that has been read into memory to the display device.

2. The image transmission method for uncompressed video according to claim 1, characterized in that, Based on the storage address of each frame of image data, calculate the number of padding bytes to be inserted before the corresponding frame of image data, including: Set the cumulative padding bytes And initialize it to 0; For each frame of image data in the original video file, perform the following steps: Get the storage address of the current frame ; According to the formula The number of padding bytes to be inserted before the current frame's image data is calculated. ,in, This represents the modulo operation; it is used to calculate the number of padding bytes in the current frame. Then, the cumulative number of filled bytes is... Updated to and The sum of.

3. The image transmission method for uncompressed video according to claim 1, characterized in that, Reading video data from the stored uncompressed video file into memory without buffering includes: Taking advantage of the fact that the video data in the uncompressed video file is in a 4K aligned state, the video data blocks in the uncompressed video file are directly read into memory through direct memory access.

4. A method for image transmission of uncompressed video according to any one of claims 1 to 3, characterized in that, Obtaining the storage address of each frame of image data in the original video file includes: The encapsulation structure of the original video file is parsed to obtain the storage address of each frame of image data in the original video file.

5. An image transmission system for uncompressed video, characterized in that, It includes a raw video file acquisition module, a storage address acquisition module, a padding byte count calculation module, a padding byte insertion module, a packaged storage module, an unbuffered reading module, and an output module; The original video file acquisition module is used to: acquire an uncompressed original video file, wherein the video data in the original video file is in a non-4K aligned state; The storage address acquisition module is used to: acquire the storage address of each frame of image data in the original video file; The padding byte count calculation module is used to: calculate the number of padding bytes to be inserted before the corresponding frame of image data based on the storage address of each frame of image data; The padding byte insertion module is used to insert a calculated number of padding bytes before each frame of image data in the original video file to generate a target video file, wherein the video data in the target video file is in a 4K aligned state. The encapsulation and storage module is used to: re-encapsulate the target video file into an uncompressed encapsulated video file and store it; The unbuffered reading module is used to: read video data from the stored uncompressed video file into memory without buffering; The output module is used to output the video data that has been read into memory to the display device.

6. The image transmission system for uncompressed video according to claim 5, characterized in that, The padding byte count calculation module is specifically used for: Set the cumulative padding bytes And initialize it to 0; For each frame of image data in the original video file, perform the following steps: Get the storage address of the current frame ; According to the formula The number of padding bytes to be inserted before the current frame's image data is calculated. ,in, This represents the modulo operation; it is used to calculate the number of padding bytes in the current frame. Then, the cumulative number of filled bytes is... Updated to and The sum of.

7. The image transmission system for uncompressed video according to claim 5, characterized in that, The cacheless read module is specifically used for: Taking advantage of the fact that the video data in the uncompressed video file is in a 4K aligned state, the video data blocks in the uncompressed video file are directly read into memory through direct memory access.

8. An image transmission system for uncompressed video according to any one of claims 5 to 7, characterized in that, The storage address acquisition module is used to: parse the encapsulation structure of the original video file and obtain the storage address of each frame of image data in the original video file.

9. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the image transmission method for uncompressed video as described in any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements an image transmission method for uncompressed encapsulated video as described in any one of claims 1 to 4.

Images