Software compensation method and device for hardware platform not supporting target compression format

Abstract

The application provides a software compensation method and device for a hardware platform not supporting a target compression format, which comprises the following steps: converting original image data into compressed data in a target compression format through a format conversion program, and generating hardware configuration parameters corresponding to the target compression format; sending the compressed data and the hardware configuration parameters to the hardware platform; reconfiguring the physical layer and / or protocol layer parameters of a display serial interface of the hardware platform based on the received hardware configuration parameters; and sending the received compressed data as original data flow to a display device through the reconfigured display serial interface. The conversion of the compressed data format is completed on an external processing unit, and the hardware platform only needs to receive the converted compressed data and dynamically adjust the clock and timing parameters of the display interface according to the matching configuration parameters, so that the research and development and testing costs can be greatly reduced, and the flexibility of the scheme is improved.

Description

Technical Field

[0001] This application relates to the field of image data transmission, and more specifically, to a software compensation method and apparatus for a hardware platform that does not support the target compression format. Background Technology

[0002] With the continuous development of display technology, high-resolution, high-refresh-rate display panels are becoming increasingly common. However, the transmission of ultra-high-definition video data places extremely high demands on interface bandwidth. To alleviate bandwidth pressure, the Video Electronics Standards Association (VESA) proposed the Display Stream Compression (DSC) standard. DSC is a visually lossless real-time compression algorithm that can achieve a compression ratio of approximately 3:1 while maintaining image quality, and is widely used in display interfaces such as MIPI DSI and HDMI 2.1.

[0003] The normal operation of a DSC system requires an encoder at the transmitting end and a decoder at the receiving end. Currently, display driver chips (DDICs) and display panels supporting DSC functionality typically require dedicated hardware platforms that also support DSC encoding to transmit test images during the R&D, verification, and after-sales debugging phases. However, these dedicated hardware platforms are often expensive, and their support for certain DSC formats may be incomplete; in some cases, the required format hardware platforms may not even be available on the market. This presents cost and technical obstacles to the R&D and verification of DDICs and panels. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a software compensation method and apparatus for hardware platforms that do not support the target compression format, which can significantly reduce research and development and testing costs and improve the flexibility of the solution.

[0005] In a first aspect, embodiments of this application provide a software compensation method for a hardware platform that does not support a target compression format, comprising: converting raw image data into compressed data of the target compression format through a format conversion program, and generating hardware configuration parameters corresponding to the target compression format; sending the compressed data and the hardware configuration parameters to the hardware platform; the hardware platform reconfiguring the physical layer and / or protocol layer parameters of its display serial interface based on the received hardware configuration parameters; and sending the received compressed data as a raw data stream to a display device through the reconfigured display serial interface.

[0006] In one embodiment, the hardware platform reconfigures the physical layer and / or protocol layer parameters of its display serial interface based on the received hardware configuration parameters, including: the hardware platform calculating the equivalent image width based on the amount of compressed data; and recalculating the bit clock and / or total horizontal pixels of the display serial interface based on the equivalent image width.

[0007] In one embodiment, the hardware platform calculates the equivalent image width based on the amount of compressed data, including: calculating the equivalent image width according to the original display width and the specified pixel data format type in the hardware configuration parameters, and according to the mapping relationship corresponding to the pixel data format type.

[0008] In one embodiment, recalculating the bit clock and / or total horizontal pixels of the display serial interface based on the equivalent image width includes: replacing the original display width with the equivalent width, recalculating the serial clock frequency and horizontal synchronization period of the display serial interface; and configuring the display serial interface according to the recalculated serial clock frequency and horizontal synchronization period.

[0009] In one embodiment, before converting the original image data into compressed data of the target compression format using a format conversion program, the method further includes: loading the original image data and receiving user configuration parameters for the target compression format; wherein the configuration parameters include one or more of the following parameters: compression version, bits per component, bits per pixel, image height, image width, segment height, and segment width.

[0010] In one embodiment, the method further includes: the hardware platform receiving the compressed data through an extended communication mechanism in a boot loading mode, and storing the received compressed data in a frame buffer.

[0011] In one embodiment, sending the compressed data and the hardware configuration parameters to the hardware platform includes: sending the hardware configuration parameters to the hardware platform via a first communication method; and sending the compressed data to the hardware platform via a second communication method.

[0012] In one embodiment, the hardware configuration parameters include image parameter set parameters; the image parameter set parameters include slice width, slice height, bits per pixel, and color component bits.

[0013] In one embodiment, the target compression format is a display stream compression format. This embodiment of the application transfers the conversion of compressed data formats from the hardware platform to an external processing unit (e.g., a PC). The hardware platform only needs to receive the converted compressed data and dynamically adjust the clock and timing parameters of its display interface according to the corresponding configuration parameters to send the compressed data out in a "pass-through" manner. Thus, a low-cost hardware platform that originally lacked the ability to send compressed data can now drive display panels that support compressed formats, significantly reducing R&D and testing costs and improving the flexibility of the solution.

[0014] Secondly, embodiments of this application also provide a software compensation device for a hardware platform that does not support a target compression format, comprising: a format conversion module, configured to convert the original image data into compressed data of the target compression format through a format conversion program, and generate hardware configuration parameters corresponding to the target compression format; a sending module, configured to send the compressed data and the hardware configuration parameters to the hardware platform; a first configuration module, configured for the hardware platform to reconfigure the physical layer and / or protocol layer parameters of its display serial interface based on the received hardware configuration parameters; and a second configuration module, configured to send the received compressed data as an original data stream to a display device through the reconfigured display serial interface.

[0015] Thirdly, embodiments of this application also provide an electronic device, including: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method described in the first aspect above, or any possible implementation of the first aspect.

[0016] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the software compensation method for a hardware platform that does not support the target compression format as described in the first aspect or any possible implementation of the first aspect.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, specific embodiments are described below in conjunction with the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1A schematic diagram illustrating the operating environment of the software compensation method for a hardware platform that does not support the target compression format, as provided in the embodiments of this application. Figure 2 A block diagram illustrating an electronic device provided in an embodiment of this application; Figure 3 A flowchart illustrating a software compensation method for a hardware platform that does not support the target compression format, as provided in an embodiment of this application. Figure 4 A schematic diagram of the functional modules of a software compensation device for a hardware platform that does not support the target compression format, provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0021] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0022] Through long-term research, the inventors of this application have discovered that the existing solutions mainly have the following problems: First, a hardware platform that supports a specific VESA-DSC format may not even exist on the market. Because the VESA-DSC standard includes various compression formats (such as different compression versions, bit count per component, bit count per pixel, and other parameter combinations), not all formats have corresponding commercially available hardware platforms, which hinders research and development and verification efforts.

[0023] Second, even if hardware platforms supporting specific VESA-DSC formats exist on the market, their prices are often very high. For teams with limited R&D budgets, the cost of purchasing such dedicated hardware platforms is a significant burden, hindering rapid product iteration and cost control.

[0024] Third, the VESA-DSC format supported by existing hardware platforms on the market is fixed. Users cannot flexibly customize or fine-tune the parameters of the VESA-DSC format according to their own needs. Limited by the characteristics and support range of the hardware platform itself, it is difficult to meet diverse R&D and debugging needs.

[0025] In view of this, this application proposes a software compensation method for hardware platforms that do not support the target compression format. This method transfers the conversion of compressed data formats from the hardware platform to an external processing unit (e.g., a PC). The hardware platform only needs to receive the converted compressed data and dynamically adjust the clock and timing parameters of its display interface according to the corresponding configuration parameters, sending the compressed data out in a "pass-through" manner. Thus, a low-cost hardware platform that originally lacked the ability to send compressed data can now drive display panels that support compressed formats, significantly reducing R&D and testing costs and improving the flexibility of the solution.

[0026] To facilitate understanding of this embodiment, the operating environment for implementing the automated commissioning and configuration method of a centralized power distribution terminal (DTU) disclosed in this application embodiment will be described in detail first.

[0027] like Figure 1 The diagram shown illustrates the operating environment of a software compensation method for a hardware platform that does not support the target compression format, as provided in this embodiment of the application. The operating environment for this software compensation method for a hardware platform that does not support the target compression format includes a hardware platform 20 and a format conversion program 10, which are connected via a USB interface.

[0028] To facilitate understanding of this embodiment, the electronic device implementing the software compensation method for a hardware platform that does not support the target compression format disclosed in this application embodiment will be described in detail below.

[0029] like Figure 2 The diagram shown is a block illustration of an electronic device. The electronic device 100 may include a memory 111 and a processor 113. Those skilled in the art will understand that... Figure 2 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 100. For example, the electronic device 100 may also include components that are more... Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown.

[0030] The aforementioned memory 111 and processor 113 are electrically connected to each other directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The aforementioned processor 113 is used to execute executable modules stored in the memory.

[0031] The memory 111 can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory 111 stores programs, and the processor 113 executes these programs upon receiving execution instructions. The methods executed by the electronic device 100 as defined in any embodiment of this application can be applied to the processor 113, or implemented by the processor 113.

[0032] The aforementioned processor 113 may be an integrated circuit chip with signal processing capabilities. The processor 113 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a digital signal processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor.

[0033] The electronic device 100 in this embodiment can be used to execute various steps in the various methods provided in the embodiments of this application. The implementation process of the software compensation method for hardware platforms that do not support the target compression format is described in detail below through several embodiments.

[0034] Please see Figure 3 This is a flowchart of a software compensation method for a hardware platform that does not support the target compression format, provided in an embodiment of this application. The following will describe... Figure 3 The specific process shown will be explained in detail.

[0035] Step 201: Convert the original image data into compressed data of the target compression format using a format conversion program, and generate hardware configuration parameters corresponding to the target compression format.

[0036] The format conversion program here runs on a host computer (such as a personal computer or workstation), and it is a completely self-developed user interface program. The program converts raw image data into compressed data that conforms to the target compression format standard. It includes an image loading module, a format conversion module, and a data transmission module.

[0037] In one embodiment, after the format conversion program starts running, the user plugs the Universal Serial Bus (USB) into the USB port of the host computer and the hardware platform, and then clicks the configuration button. A configuration dialog box will pop up, allowing the user to configure processor interface-related parameters. These parameters include the number of horizontal pixels in the effective display area of ​​the screen, the number of vertical rows in the effective display area of ​​the screen, the number of rows occupied by the vertical sync pulse, the vertical back shoulder, the vertical front shoulder, the clock cycle occupied by the horizontal sync pulse, the horizontal back shoulder, the horizontal front shoulder, the frame rate, the physical data channels in the MIPI interface, the 24-bit color format, and the RGB color model.

[0038] Furthermore, clicking the "Connect" button in the dialog box will connect to the hardware platform; then clicking "Image Conversion" in the menu bar will bring up the target compression format data conversion parameter configuration interface, where users can configure the target compression format to be converted. Finally, select the directory containing all the image files to be observed, and then click the "Set" button. The image file loading module will read all image files in the directory and their configured Vesa-DSC related parameters, and call the Vesa-DSC conversion program module to process them sequentially. The data output by the Vesa-DSC conversion program will then be saved as a .txt file according to the user's naming rules. This process will continue until all images in the directory have been processed. Then, the user can use a specified command (specifying a specific image filename) to call the Universal Serial Bus port data transfer module to index the corresponding image file's .txt file, and transmit this .txt data to the hardware platform via batch transfer.

[0039] Optionally, configurable parameters include the protocol version number, the original bit depth of each color component, the average number of bits occupied by each pixel after compression, the width and height of the original image, and the size of the slice, which together constitute the 128-byte parameters of PPS.

[0040] Step 202: Send compressed data and hardware configuration parameters to the hardware platform.

[0041] The compressed data and hardware configuration parameters generated by the host computer are transmitted to the embedded hardware platform through a universal serial bus port (such as a USB interface).

[0042] Optionally, the hardware platform can be based on Android or Linux systems, and can receive compressed data and hardware configuration parameters through the operating system's fast boot mechanism.

[0043] Step 203: Based on the received hardware configuration parameters, the hardware platform reconfigures the physical layer and / or protocol layer parameters of its display serial interface.

[0044] In this embodiment, after receiving compressed data and hardware configuration parameters, the hardware platform's platform initialization and configuration module parses the hardware configuration parameters. Since the hardware platform natively only supports uncompressed data formats, the clock and timing parameters of its MIPIDSI interface were originally configured according to the amount of uncompressed data. To adapt to the compressed data volume, the hardware platform needs to reconfigure the display serial interface. Specifically, this includes: First, the equivalent image width is calculated based on the amount of compressed data. Then, based on the equivalent width, the bit clock of the DSI PHY is recalculated to match the data rate of the compressed data. Additionally, the hardware platform configures the data type of the DSI interface to match the data type corresponding to the compressed data sent in display mode by the target compression format.

[0045] Optionally, the instructions obtained by parsing the hardware configuration parameters may include parameter update instructions, image upload instructions, video stream start instructions, video stream stop instructions, control send instructions, read / query instructions, etc., and these instructions can be selected according to the actual situation.

[0046] Step 204: The received compressed data is used as the raw data stream and sent to the display device through the reconfigured display serial interface.

[0047] In one embodiment, the hardware platform treats the received compressed data as a raw data stream and, according to the reconfigured DSI interface parameters, transmits the compressed data via the MIPI DSI interface in a pass-through manner to a display panel that supports decoding the target compression format. The decoder inside the display panel decodes the compressed data and displays the image normally.

[0048] In the above implementation process, the conversion of compressed data format is transferred from the hardware platform to an external processing unit (e.g., a PC). The hardware platform only needs to receive the converted compressed data and dynamically adjust the clock and timing parameters of its display interface according to the corresponding configuration parameters to send the compressed data out in a "pass-through" manner. Thus, a low-cost hardware platform that originally lacked the ability to send compressed data can now drive display panels that support compressed formats, significantly reducing R&D and testing costs and improving the flexibility of the solution.

[0049] In one possible implementation, step 203 includes: the hardware platform calculating the equivalent image width based on the amount of compressed data; and recalculating the bit clock and / or total horizontal pixels of the display serial interface based on the equivalent image width.

[0050] For example, if the original image width is W, the original bit depth per pixel is bpp_original, and the equivalent bit depth per pixel after compression is bpp_compressed, then the equivalent width real_width = (W × bpp_original) / bpp_compressed.

[0051] Furthermore, based on the equivalent width, the bit clock of the DSI PHY is recalculated to match the data rate of the compressed data; at the same time, the timing parameters such as the total horizontal pixels of the DSI Host are reconfigured.

[0052] In one possible implementation, the hardware platform calculates the equivalent image width based on the amount of compressed data, including: calculating the equivalent image width according to the original display width in the hardware configuration parameters and the specified pixel data format type, based on the mapping relationship corresponding to the pixel data format type.

[0053] Optionally, the pixel data format types include native RGB formats (such as RGB888, RGB565, RGB101010, etc.) and various predetermined target compression formats (such as VESA8to8, VESA10to8, VESA10to10, VESASPR8to8, VESASPR10to8, VESA32to12, VESA32to16, VESA40to16, etc.).

[0054] In one embodiment, after determining the equivalent image width, the interface configuration module replaces the original display width with the equivalent image width and reconfigures the parameters of the physical layer and the link layer.

[0055] In one possible implementation, recalculating the bit clock and / or total horizontal pixels of the display serial interface based on the equivalent image width includes: replacing the original display width with the equivalent width, recalculating the serial clock frequency and horizontal synchronization period of the display serial interface; and configuring the display serial interface according to the recalculated serial clock frequency and horizontal synchronization period.

[0056] In one embodiment, the serial clock frequency of DSI Phy is recalculated based on the equivalent image width. The calculation of the serial clock frequency needs to take into account factors such as effective width, height, frame rate, blanking parameters, and number of channels to ensure that data can be transmitted on the DSI interface at the correct rate.

[0057] The horizontal synchronization period of the DSI Host is reconfigured based on the equivalent image width. The horizontal synchronization period determines the total number of cycles for each line of data in the horizontal direction, including the effective display area and the horizontal blanking area.

[0058] Configure the corresponding data packet type identifier according to the pixel data format type. For example, the data type of RGB888 format is 0x3E in video mode. If the data type of the data stream sent to the panel does not match the actual data format, the panel will display an error.

[0059] In one possible implementation, before converting the original image data into compressed data of the target compression format via a format conversion procedure, the method further includes: loading the original image data and receiving user configuration parameters for the target compression format.

[0060] In this embodiment, the bmp image loading program sequentially traverses the bmp files in the bmp directory and passes the rgb888 data and target compression format parameters to the data conversion module. Finally, the output data of the data conversion module is saved as a txt file according to the naming rules required by the user.

[0061] Users send the .txt data in .dsc format corresponding to the BMP to be observed to the embedded hardware platform via USB bulk using the uppic command.

[0062] In one embodiment, a format conversion program can be run on a host computer. This program provides a user configuration interface, allowing users to set various configuration parameters of the target compression format.

[0063] After loading the original image data (e.g., a BMP format image file), the format conversion program, based on the user-set configuration parameters, calls the compression algorithm of the target compression format to convert the original image data into compressed data in the target compression format and saves it as a compressed data file. Simultaneously, the format conversion program generates a hardware configuration parameter file corresponding to the target compression format.

[0064] The configuration parameters include one or more of the following: compression version, bits per component, bits per pixel, image height, image width, slice height, and slice width.

[0065] In one possible implementation, the method further includes: the hardware platform receiving compressed data through an extended communication mechanism in a boot loading mode, and storing the received compressed data in a frame buffer.

[0066] In one embodiment, the software module receives compressed data from the host computer via the fastboot mechanism and stores it in a frame buffer for later display.

[0067] Optionally, the software module can respond to user commands (e.g., upload parameters, upload images, start video stream, stop video stream, send commands, read commands / status, etc.), and execute the corresponding processing flow according to the parsed commands after parsing each command.

[0068] The hardware platform here has a DSI interface compliant with the MIPI standard, which can be used to communicate with the display panel. The software module is a secondary development based on the bootloader. The functions of this software module include: a DSC data receiving module that receives data via Fastboot, developing user commands and their handlers to respond to user-issued platform configuration commands, and commands to send DSC data to the panel. It also performs hardware platform initialization configuration upon receiving parameters of a certain compression format, preparing for the transmission of data in that format.

[0069] In this embodiment, the initialization platform configuration for sending vesa-dsc data is implemented on the basis that the hardware platform can only send data in the RGB888 / RGB565 format.

[0070] Understandably, since the hardware platform can only display the received raw data to the panel in RGB888 or RGB565 format, when the hardware platform is configured to use other formats, it will only treat the received data as RGB888 format data, i.e., raw data. However, the data size of compressed RGB888 data has changed. For example, an RGB888 image with width=1080 and height=2400, after being converted to Vesa8to8 format by DSC, will no longer have a data size of 1080*2400*3, but rather 360*2400*3. Therefore, the actual width after mapping calculation should be 360. Thus, when configuring DSI Phy and DSI Host, it is necessary to recalculate the bit clock, use the actual width as the baseline for the horizontal total, and reconfigure the hardware platform to use the data types required in video mode for this data format. For example, in RGB888 format video mode, the data type is 0x3E. If the data stream sent to the panel has a data type of 0x3E, but the data is in the target compression format, the panel will display an error. For example, when calculating the actual width based on the user-configured width, the actual width is used to configure the clock signal bits of the DSI Phy, the total horizontal dimension of the DSI Host, and the corresponding data type used to configure the video mode of the DSIHost. The actual width can be determined using the following code: void panel_valid_width_calculate(void) { real_width = raw_width; / / pix_format can take values ​​of rgb888, rgb565, rgb101010, vesa8to8, vesa10to8, / / vesa10to10, vesaspr8to8, vesaspr10to8, vesa32to12, / / vesa32to16, vesa40to16, etc. switch(pix_format) { case RGB101010: real_width = real_width * 10 / 8; break case VESA8to8: case VESA10to8: if(real_width % 3) { dataType = 0x0b00; real_width = real_width / 2; pix_format = RGB565; bpp = 2; } else { real_width = real_width / 3; } break } } In one possible implementation, step 202 includes: sending hardware configuration parameters to the hardware platform via a first communication method; and sending compressed data to the hardware platform via a second communication method.

[0071] The first communication method can be USB control mode, and the second communication method can be USB bulk mode.

[0072] Optionally, the hardware configuration parameters may include width, height, pixel format, frame rate, vertical sync pulse width, vertical sync back shoulder, vertical sync front shoulder, horizontal sync pulse width, horizontal sync back shoulder, horizontal sync front shoulder, number of channels, MIPI working mode, etc., and these hardware configuration parameters can be selected according to actual conditions.

[0073] In one possible implementation, the hardware configuration parameters include image parameter set parameters.

[0074] The image parameter set here includes slice width, slice height, bits per pixel, and bit depth of color components.

[0075] In one possible implementation, the target compression format is a display stream compression format. Based on the same application concept, this application embodiment also provides a software compensation device for a hardware platform that does not support the target compression format, corresponding to the software compensation method for a hardware platform that does not support the target compression format. Since the principle of the device in this application embodiment is similar to the aforementioned software compensation method embodiment for a hardware platform that does not support the target compression format, the implementation of the device in this embodiment can refer to the description in the above method embodiment, and the repeated parts will not be described again.

[0076] Please see Figure 4 This is a functional module diagram of the software compensation device for a hardware platform that does not support the target compression format, provided in an embodiment of this application. Each module in the software compensation device for a hardware platform that does not support the target compression format in this embodiment is used to execute the steps in the above method embodiments. The software compensation device for a hardware platform that does not support the target compression format includes a format conversion module 301, a sending module 302, a first configuration module 303, and a second configuration module 304; wherein, The format conversion module 301 is used to convert the original image data into compressed data of the target compression format through a format conversion program, and generate hardware configuration parameters corresponding to the target compression format.

[0077] The sending module 302 is used to send the compressed data and the hardware configuration parameters to the hardware platform.

[0078] The first configuration module 303 is used for the hardware platform to reconfigure the physical layer and / or protocol layer parameters of its display serial interface based on the received hardware configuration parameters.

[0079] The second configuration module 304 is used to send the received compressed data as a raw data stream to the display device through the reconfigured display serial interface.

[0080] In one possible implementation, the first configuration module 303 is further configured to: calculate the equivalent image width based on the amount of compressed data; and recalculate the bit clock and / or total horizontal pixels of the display serial interface based on the equivalent image width.

[0081] In one possible implementation, the first configuration module 303 is specifically used to: calculate the equivalent image width according to the original display width and the specified pixel data format type in the hardware configuration parameters, and according to the mapping relationship corresponding to the pixel data format type.

[0082] In one possible implementation, the first configuration module 303 is specifically used to: replace the original display width with the equivalent width, recalculate the serial clock frequency and horizontal synchronization period of the display serial interface; and configure the display serial interface according to the recalculated serial clock frequency and horizontal synchronization period.

[0083] In one possible implementation, the software compensation device for the hardware platform that does not support the target compression format further includes a loading module for loading the original image data and receiving user configuration parameters for the target compression format; wherein the configuration parameters include one or more of the following parameters: compression version, bits per component, bits per pixel, image height, image width, segment height, and segment width.

[0084] In one possible implementation, the software compensation device for the hardware platform that does not support the target compression format further includes a caching module, which is used by the hardware platform to receive the compressed data through an extended communication mechanism in a boot loading mode, and to store the received compressed data in a frame buffer.

[0085] In one possible implementation, the sending module 302 is specifically used to: send the hardware configuration parameters to the hardware platform via a first communication method; and send the compressed data to the hardware platform via a second communication method.

[0086] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the software compensation method for a hardware platform that does not support the target compression format as described in the above method embodiments.

[0087] The computer program product of the software compensation method for hardware platforms that do not support the target compression format provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the steps of the software compensation method for hardware platforms that do not support the target compression format as described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0088] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0089] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0090] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. It should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0091] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A software compensation method for a hardware platform that does not support the target compression format, characterized in that, include: The original image data is converted into compressed data of the target compression format through a format conversion program, and hardware configuration parameters corresponding to the target compression format are generated. Send the compressed data and the hardware configuration parameters to the hardware platform; The hardware platform reconfigures the physical layer and / or protocol layer parameters of its display serial interface based on the received hardware configuration parameters. The received compressed data is used as the raw data stream and sent to the display device through the reconfigured display serial interface.

2. The method according to claim 1, characterized in that, Based on the received hardware configuration parameters, the hardware platform reconfigures the physical layer and / or protocol layer parameters of its display serial interface, including: The hardware platform calculates the equivalent image width based on the amount of compressed data; The bit clock and / or total horizontal pixels of the display serial interface are recalculated based on the equivalent image width.

3. The method according to claim 2, characterized in that, The hardware platform calculates the equivalent image width based on the amount of compressed data, including: Based on the original display width and the specified pixel data format type in the hardware configuration parameters, the equivalent image width is calculated according to the mapping relationship corresponding to the pixel data format type.

4. The method according to claim 2, characterized in that, The recalculation of the bit clock and / or total horizontal pixels of the display serial interface based on the equivalent image width includes: The original display width is replaced by the equivalent width, and the serial clock frequency and horizontal synchronization period of the display serial interface are recalculated. Configure the display serial interface according to the recalculated serial clock frequency and horizontal synchronization period.

5. The method according to claim 1, characterized in that, Before converting the original image data into compressed data of the target compressed format using a format conversion program, the method further includes: Load the original image data and receive the user's configuration parameters for the target compression format; The configuration parameters include one or more of the following: compression version, bits per component, bits per pixel, image height, image width, slice height, and slice width.

6. The method according to claim 1, characterized in that, The method further includes: The hardware platform receives the compressed data through an extended communication mechanism in boot loading mode and stores the received compressed data in a frame buffer.

7. The method according to claim 1, characterized in that, Sending the compressed data and the hardware configuration parameters to the hardware platform includes: The hardware configuration parameters are sent to the hardware platform via a first communication method. The compressed data is sent to the hardware platform via a second communication method.

8. The method according to claim 1, characterized in that, in, The hardware configuration parameters include image parameter set parameters; The image parameter set parameters include slice width, slice height, bits per pixel, and bit depth of color components.

9. The method according to claim 1, characterized in that, in, The target compression format is a display stream compression format.

10. A software compensation device for a hardware platform that does not support the target compression format, characterized in that, include: The format conversion module is used to convert the original image data into compressed data of the target compression format through a format conversion program, and generate hardware configuration parameters corresponding to the target compression format; The sending module is used to send the compressed data and the hardware configuration parameters to the hardware platform. The first configuration module is used for the hardware platform to reconfigure the physical layer and / or protocol layer parameters of its display serial interface based on the received hardware configuration parameters. The second configuration module is used to send the received compressed data as a raw data stream to the display device through the reconfigured display serial interface.

11. An electronic device, characterized in that, include: The processor and memory, wherein the memory stores machine-readable instructions executable by the processor, wherein when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 9.

Images