A driving recorder video display method and system based on an SPI interface display screen

Abstract

This invention discloses a video display method and system for a dashcam based on an SPI interface display screen. The main control chip of the dashcam has video encoding capabilities and an SPI interface, which is connected to an SPI display screen. The dashcam video display includes video recording mode, menu interaction mode, and video playback mode. This method, through an innovative data overlay and transmission strategy, achieves a stable and acceptable display effect on a low-cost hardware platform with only an SPI display interface, while meeting the basic safety preview and playback requirements of the dashcam. Real-time video, playback video data, and GUI data are pre-overlaid and fused in the frame buffer in the chip's memory to generate a complete frame image, which is then sent out through the SPI interface. This overcomes the bandwidth limitation of the SPI interface and enables the dashcam to achieve real-time preview, UI interaction, and video playback functions that meet vehicle safety requirements on a low-cost hardware platform.

Description

Technical Field

[0001] This invention relates to the field of dashcam video display technology, specifically to a dashcam video display method and system based on an SPI interface display screen. Background Technology

[0002] Dashcams have become standard equipment in modern cars. Their core function is to record driving videos in real time and display them on a built-in screen, while also providing a user interface for parameter settings, video playback, and other operations. Currently, mainstream dashcams generally use LCD screens with RGB parallel interfaces or high-speed serial interfaces such as MIPI. These interfaces have high bandwidth characteristics and can directly transmit real-time video frames rendered by the main control chip, thereby achieving a smooth display effect. Correspondingly, the main control chip of the dashcam also needs to integrate such high-speed display interfaces.

[0003] For example, patent CN111739193B discloses a method for displaying images from a dashcam and a dashcam. The method includes: acquiring the driving speed; adjusting the display frame rate of the dashcam according to the driving speed, with the display frame rate set lower for higher driving speeds; extracting image frames from the image frames captured by the dashcam according to the adjusted display frame rate for display; adjusting the display frame rate of the dashcam according to the driving speed, with the display frame rate set lower for higher driving speeds; and extracting image frames from the image frames captured by the dashcam according to the adjusted display frame rate for display. This method can reduce the sense of regression in the human eye when viewing the video images displayed by the dashcam, reduce the dizziness of previewing the dashcam images, effectively improve the user experience, and facilitate its use as a rearview mirror.

[0004] For example, patent CN105681718B discloses a display method for video playback from a dashcam and a dashcam, including: displaying the video to be displayed on the dashcam's screen in a two-dimensional array, wherein the two-dimensional array displays all videos from the same trip along the same dimension, and the videos from the same trip are all videos recorded by the dashcam from the time it is turned on to the time it is turned off; by displaying the recorded videos on the dashcam's screen in a two-dimensional array, and displaying all videos from the same trip along the same dimension of the two-dimensional array, the displayed videos are arranged in a regular pattern, making it easier for users to quickly locate and find the videos they want to play back, thus improving the user experience.

[0005] For example, patent CN119964268A discloses a connected car dashcam system and a car. The system includes a switch module, an audio acquisition module, a video acquisition module, a processor module, a storage module, a cloud storage module, and a display module. The output of the switch module is connected to the input of the processor module; the output of the audio acquisition module is connected to the input of the processor module; the video acquisition module is connected to the processor module; the storage module is connected to the processor module; the cloud storage module is connected to the processor module; and the display module is connected to the processor module. The connected car dashcam system can take photos in real time while the car is in motion.

[0006] Displays with RGB or MIPI interfaces and the main control chips that support these interfaces are relatively expensive, which is not conducive to developing highly cost-competitive entry-level products. Some chips that originally had high cost-performance advantages in image processing and encoding may not have integrated high-speed display interfaces such as RGB or MIPI because they were not originally designed for devices with screens. This limits their application in the dashcam field. SPI interface displays have become an attractive alternative due to their extremely low cost and wide availability. However, the fatal flaw of the SPI interface is its extremely low communication bandwidth, which makes it difficult to directly transmit high-resolution, high-frame-rate real-time video data. If the traditional rendering-transmission-display method is used, it will cause serious stuttering and tearing of the display screen, which cannot meet the basic usage requirements of dashcams.

[0007] To address the aforementioned issues, there is an urgent need for innovative design based on existing dashcam video display systems. This invention targets entry-level, low-cost dashcam scenarios. Without relying on the hardware constraints of high-bandwidth display interfaces such as RGB / MIPI, it adapts to the inherent bandwidth limitations of the SPI interface through a dedicated display architecture. While meeting the basic display requirements for in-vehicle safety recording, it achieves an acceptable real-time preview, UI interaction, and video playback experience. Summary of the Invention

[0008] The purpose of this invention is to provide a video display method and system for a dashcam based on an SPI interface display screen, in order to solve the fatal flaw of the SPI interface mentioned in the background art, which is its extremely low communication bandwidth, making it difficult to directly transmit high-resolution, high-frame-rate real-time video data. If the traditional rendering-transmission-display method is used, it will lead to severe stuttering and tearing of the display screen, which cannot meet the basic usage requirements of a dashcam.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a video display method and system for a dashcam based on an SPI interface display screen. The main control chip of the dashcam has video encoding capabilities and an SPI interface. The SPI interface is connected to an SPI display screen. The video display method of the dashcam includes the following modes: Video recording mode display steps: In step A1, the image processing unit built into the main control chip continuously captures video data from the camera and encodes and stores it.

[0010] Step A2 utilizes the multi-stream encoding capability natively supported by the main control chip's hardware encoder to simultaneously generate a high-resolution main stream for storage and a low-resolution, low-bitrate sub-stream dedicated to SPI display. This does not require adding an extra computing module and represents a targeted reuse of the chip's existing hardware capabilities.

[0011] Step A3: In the graphics processing unit of the main control chip, a graphics buffer with the same resolution as the SPI display screen is allocated as the final display frame buffer.

[0012] Step A4: After decoding the extracted sub-stream video data, an interpolation scaling algorithm is used to adjust it to the display screen resolution, and the data is synchronously written to the underlying video layer of the display frame buffer.

[0013] Step A5: Render the user interface elements using a lightweight graphics library, and then alpha blend and overlay the rendered UI layer with the underlying video frame in the display frame buffer.

[0014] Step A6: The final superimposed image data is pushed to the display screen via DMA streaming through the SPI interface at a safe transmission rate adapted to the bandwidth, avoiding long-term full load on the bus.

[0015] Menu interaction mode display steps: In step B1, when the user enters the pure menu interface, the main control chip triggers an interrupt command to stop the video data acquisition and overlay process, thereby saving system resources and optimizing the allocation of system computing power.

[0016] Step B2: Enable only the LVGL graphics library to render the full menu interface.

[0017] Step B3: The rendered menu interface data is pushed to the SPI display via the SPI interface. Since there is no need to transmit dynamic video data, the bandwidth of the SPI interface can ensure the smoothness of menu operation.

[0018] Video playback mode display steps: Step C1: The user selects to play back the recorded video file, which is a high-resolution main stream.

[0019] In step C2, the main control chip calls the software decoding library to perform software decoding on the video file. To reduce decoding overhead, it prioritizes decoding the low bitrate sub-streams contained in the file.

[0020] Step C3 involves overlaying the video frames decoded by software onto the playback control UI rendered by LVGL.

[0021] Step C4: The superimposed image data is pushed to the display screen through the SPI interface. The SPI data transmission rhythm is dynamically adjusted according to the decoding frame rate to ensure the synchronization of video playback and UI interaction, and to achieve a stable playback effect that meets the needs of viewing driving records.

[0022] Preferably, the main control chip specifically includes: an image processing and encoding unit, integrating an ISP and a hardware encoder, responsible for the acquisition, preprocessing, and hardware encoding of camera video data, realizing hardware-level encoding and bitstream separation, and balancing storage and display requirements; a graphics processing and frame buffer, including a GPU and a dedicated video memory area, responsible for the compositing of the display image, layer blending, and frame data caching, ensuring display effects through hardware acceleration and buffering mechanisms; a software decoder, which realizes software decoding of video files based on CPU computing power, realizes software decoding and bitstream adaptation of stored video files, adapts to the software decoding requirements of playback scenarios, and supports intelligent bitstream switching to optimize performance; and an SPI controller, which is the communication interface between the main control chip and the SPI display screen, realizing stable data transmission through high-speed communication and timing control.

[0023] Preferably, the image processing and encoding unit in the dashcam's encoding process is as follows: Raw video acquisition: The camera outputs a high-resolution, high-frame-rate raw video stream, which is then preprocessed by the ISP unit of the main control chip; Multi-stream encoding configuration: In the hardware encoder, both main stream parameters and sub-stream parameters are configured simultaneously; Synchronous encoding generation: The encoder synchronously encodes the same raw video stream using different parameters, generating two independent encoded streams. The main stream is written to the TF card for storage, and the sub-stream is directly used for local display; Sub-stream extraction: The encoder outputs the sub-stream directly to the display link of the main control chip through an internal channel for subsequent local screen display.

[0024] Preferably, the sub-stream adaptation to the display resolution includes three steps: decoding, scaling, and writing to the frame buffer. The specific process is as follows: Sub-stream decoding: First, the sub-stream is restored to the original video frames by a hardware decoder to obtain a low-resolution video image consistent with the sub-stream parameters; Interpolation scaling algorithm adjusts the resolution: Since the sub-stream resolution is lower than the display resolution, the interpolation scaling algorithm includes bilinear interpolation and nearest neighbor interpolation. The low-resolution sub-stream video frames are enlarged according to the physical resolution ratio of the display screen to output an image consistent with the display screen pixels, while correcting image stretching and distortion problems; Synchronously writing to the underlying video layer of the display frame buffer: Layer areas are divided in the graphics processing and frame buffer of the main control chip. The scaled sub-stream image is written to the video memory area corresponding to the underlying video layer to prepare for subsequent UI overlay.

[0025] Preferably, the Alpha blending overlay merges the UI layer and the underlying video image into a set of data according to their transparency ratio. The core logic is as follows: the layers are layered, the underlying video image is stored in the frame buffer, and the UI layer is an independent upper transparent layer; pixel-level blending calculation: for each pixel, the final color is calculated according to the formula, final pixel = (UI pixel × Alpha value + underlying video pixel × (255 - Alpha value)) ÷ 255; the overlay result is written to the frame buffer, and the blended pixel data will be updated to the final display frame buffer as the image to be output to the display screen.

[0026] Preferably, the high-speed transmission mechanism of the SPI interface includes: rate configuration, where the SPI controller of the main control chip is set to a safe clock frequency that adapts to the bandwidth, thereby improving efficiency while ensuring stable transmission; data format adaptation, where the superimposed RGB format image data is encapsulated according to the display screen's interface protocol and serially output through the MOSI line; and streaming transmission, where a continuous frame transmission mode is adopted, and the image data in the frame buffer is pushed sequentially row by row and column by column according to pixel order, avoiding display tearing caused by data interruption.

[0027] Preferably, the LVGL graphics library rendering is based on the frame buffer device of the main control chip, and the core process is as follows: UI resource loading: LVGL calls the pre-stored menu layout configuration, icon materials and interaction logic code to initialize the menu rendering environment; control drawing optimization: through the hardware acceleration interface of LVGL, batch rendering of multi-level menu lists, parameter options, sliders, confirmation buttons and other UI controls, supporting visual effects such as anti-aliasing, gradient fill and rounded corner display, while adopting a local redraw mechanism to update only the areas that change when switching menus, reducing invalid rendering overhead; rendering result caching: storing the pixel data of the complete menu interface in an independent area of ​​the frame buffer to ensure the integrity and stability of the interface data.

[0028] Preferably, the video playback mode adopts a sub-stream priority and main stream optional decoding strategy to balance playback smoothness and hardware computing power consumption. The recorded video file contains two encoded streams: a high-resolution main stream for archiving and a low-bitrate sub-stream for fast preview. The two streams are integrated into a single file using a container format such as MP4, with the sub-stream existing as a preview track. After the user triggers the playback operation, the main control chip prioritizes reading the sub-stream data in the file instead of directly decoding the main stream. The sub-stream has lower resolution and bitrate, requiring less CPU computing power, thus avoiding stuttering caused by the low-performance main control chip decoding the main stream.

[0029] Preferably, the layer overlay mechanism of the video frame and the playback control UI includes independent processing of two layers and pixel-level overlay synthesis; the bottom layer: the YUV format video frame output by software decoding, after color space conversion and resolution scaling, is written to the bottom video channel of the frame buffer; the top layer: the LVGL graphics library renders the playback control UI component based on user interaction requirements, and the UI data is stored in the upper transparent layer of the frame buffer in RGB format with an alpha channel, supporting 0-255 levels of transparency adjustment; the graphics processing unit of the main control chip uses a hardware-accelerated alpha blending algorithm to use a fixed alpha value for static UI areas and a high-brightness alpha value for dynamic interactive areas, ensuring UI readability without obscuring key video content.

[0030] A dashcam video display system based on an SPI interface display screen, used in the aforementioned dashcam video display method based on an SPI interface display screen, the dashcam video display system comprising: The camera module is used to capture raw video streams during driving and directly outputs raw video data to the image processing and encoding unit of the main control chip.

[0031] The main control chip module, including an image processing and encoding unit, a software decoder, a graphics processing and frame buffer, and an SPI controller, connects to the camera, storage module, and display screen to complete the entire process of video acquisition, encoding, storage, decoding, synthesis, and display.

[0032] The storage module stores the main bitstream video file encoded by the main control chip, receives the encoded main bitstream written by the main control chip, and provides the video file to the software decoder of the main control chip during playback.

[0033] The SPI display module receives SPI data and displays the final image, enabling the display of video previews, menus, and playback screens.

[0034] Compared with the prior art, the beneficial effects of the present invention are: Compared with the traditional RGB / MIPI interface solution, the BOM cost is reduced, a cost-effective security main controller without a high-speed display interface can be used, the reliability in vehicles is higher, the SPI only requires 3 to 4 signal lines, the wiring is simple, the resistance to vibration and interference is stronger, and the system power consumption is lower. The power consumption of SPI transmission and display is reduced by 20% to 40% compared with the RGB solution.

[0035] Achieving complete functionality, the dashcam fully implements the three core display functions of real-time preview, menu interaction, and video playback at extremely low hardware costs, providing a good user experience.

[0036] Resource efficiency is achieved through strategies such as sub-streams, hardware / software division of labor, and mode switching, which rationally allocate the chip's CPU, GPU, memory, and I / O resources to ensure the overall stability and smoothness of the system.

[0037] Real-time video, playback video data, and GUI data are pre-overlaid and fused in the frame buffer in the chip's memory to generate a complete frame of image, which is then sent out through the SPI interface. This avoids the need to transmit video and UI data separately through the low-speed SPI interface, greatly reducing the bandwidth pressure on the SPI interface.

[0038] Based on different operation modes such as recording, interaction, and playback, the data source and content sent to the frame buffer are dynamically adjusted. The recording mode uses a low-load sub-stream, the menu interaction mode completely cuts off the video stream, and the playback mode uses software-decoded sub-streams, ensuring the system's response efficiency under limited processing capabilities.

[0039] By fully utilizing the streaming characteristics of the SPI interface and employing techniques such as double buffering or partial refresh, the entire frame or changing image area data can be efficiently sent to the display screen after the overlay is completed, maximizing the utilization of the SPI interface. Attached Figure Description

[0040] Figure 1 This is a system framework diagram of the present invention.

[0041] Figure 2 This is a system flowchart of the present invention.

[0042] Figure 3 This is a flowchart of the video recording mode of the present invention.

[0043] Figure 4 This is a flowchart of the menu interaction mode of the present invention.

[0044] Figure 5 This is a flowchart of the video playback mode of the present invention. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] This application provides a dashcam video display method based on an SPI interface display screen. The dashcam video display includes a video recording mode, a menu interaction mode, and a video playback mode. The video recording mode display steps are as follows: Step A1, the image processing unit built into the main control chip continuously captures video data from the camera and encodes and stores it; Step A2, utilizing the multi-stream encoding capability natively supported by the main control chip's hardware encoder, a high-resolution main stream for storage and a low-resolution, low-bitrate sub-stream dedicated to SPI display are simultaneously generated, without the need for additional computing power modules, representing a targeted reuse of the chip's existing hardware capabilities; Step A3, ... In the graphics processing unit of the main control chip, a graphics buffer with the same resolution as the SPI display screen is allocated as the final display frame buffer; in step A4, after decoding the extracted sub-stream video data, an interpolation scaling algorithm is used to adjust it to the display screen resolution, and it is synchronously written to the underlying video layer of the display frame buffer; in step A5, a lightweight graphics library is used to render user interface elements, and the rendered UI layer is alpha-blended and superimposed with the underlying video image in the display frame buffer; in step A6, the data is pushed to the display screen via DMA streaming at a safe transmission rate adapted to the bandwidth through the SPI interface to avoid long-term full load on the bus. The menu interaction mode display steps are as follows: in step B1, when the user enters the pure menu interface, the main control chip triggers an interrupt instruction to stop the acquisition and superposition process of video data, saving system resources and optimizing the allocation of system computing power; in step B2, only the LVGL graphics library is enabled to render the complete menu interface; in step B3, the rendered menu interface data is pushed to the SPI display screen through the SPI interface. Since there is no need to transmit dynamic video data, the bandwidth of the SPI interface can ensure the smoothness of menu operation. The video playback mode display steps are as follows: Step C1, the user selects a recorded video file to play back; the video file is a high-resolution main bitstream. Step C2, the main control chip calls the software decoding library to perform software decoding on the video file. To reduce decoding overhead, it prioritizes decoding the low-bitrate sub-bitstreams contained in the file. Step C3, the software-decoded video frames are overlaid with the LVGL-rendered playback control UI. Step C4, the overlaid image data is pushed to the display screen through the SPI interface. The SPI data transmission rhythm is dynamically adjusted according to the decoding frame rate to ensure the synchronization of video playback and UI interaction, achieving a stable playback effect that meets the needs of viewing driving records.

[0047] Example 1: To better understand the above technical solution, the following will provide a detailed description of the technical solution in conjunction with the accompanying drawings and specific implementation methods. (Refer to...) Figures 1-5As shown in this embodiment of the present application, a dashcam video display method based on an SPI interface display screen is provided. The main control chip of the dashcam has video encoding capability and an SPI interface. The SPI interface is connected to an SPI display screen. The dashcam video display includes video recording mode, menu interaction mode and video playback mode.

[0048] Video recording mode display steps: In step A1, the image processing unit built into the main control chip continuously captures video data from the camera and encodes and stores it.

[0049] In this embodiment, the main control chip specifically includes: an image processing and encoding unit, integrating an ISP and a hardware encoder, responsible for the acquisition, preprocessing, and hardware encoding of camera video data, realizing hardware-level encoding and bitstream separation, and balancing storage and display requirements; a graphics processing and frame buffer, including a GPU and a dedicated video memory area, responsible for the compositing of the display image, layer blending, and frame data caching, ensuring display quality through hardware acceleration and buffering mechanisms; a software decoder, which realizes software decoding of video files based on CPU computing power, realizes software decoding and bitstream adaptation of stored video files, adapts to the software decoding requirements of playback scenarios, and supports intelligent bitstream switching to optimize performance; and an SPI controller, which is the communication interface between the main control chip and the SPI display screen, realizing stable data transmission through high-speed communication and timing control.

[0050] It should be noted that the ISP is responsible for preprocessing the raw image input from the camera, such as denoising, white balance, and exposure compensation. The hardware encoder uses the H.264 / H.265 standard to compress and encode the processed video stream in real time. It also supports the synchronous generation of the main stream (high-resolution storage) and the sub-stream (low-resolution display), which reduces the bandwidth usage of the display link while ensuring the quality of the stored image.

[0051] It should be noted that the GPU supports hardware-accelerated image scaling, alpha blending, and other operations, which can efficiently complete the overlay and compositing of video frames and UI layers; the frame buffer opens up double or multiple buffer spaces to store the underlying video frames and the upper-layer UI data respectively, and avoids display tearing through video memory read and write optimization, ensuring the continuity and stability of the output.

[0052] It should be noted that the software decoder is compatible with MP4 and other container formats as well as H.264 and H.265 encoding standards. It supports intelligent bitstream selection, prioritizing the decoding of low bitrate sub-streams during playback to reduce computing power consumption, and switching to the main bitstream for high-definition playback. It also provides a YUV to RGB color space conversion function to adapt the decoded video frames to the display's color format.

[0053] It should be noted that the SPI controller, as the communication interface between the main control chip and the SPI display, supports SPI 4-wire / 3-wire modes and a transmission rate of up to 10MHz. It can configure data transmission timing (such as CPOL / CPHA) and realize high-speed streaming transmission of frame buffer data to the display through DMA (direct memory access). It adaptively adjusts the transmission rate in different display modes to balance bandwidth requirements and power consumption control, ensuring smooth display in scenarios such as video preview, menu interaction, and video playback.

[0054] Step A2 utilizes the multi-stream encoding capability natively supported by the main control chip's hardware encoder to simultaneously generate a high-resolution main stream for storage and a low-resolution, low-bitrate sub-stream dedicated to SPI display. This does not require adding an extra computing module and represents a targeted reuse of the chip's existing hardware capabilities.

[0055] In this embodiment, sub-stream adaptation to display resolution includes three steps: decoding, scaling, and writing to the frame buffer. The specific process is as follows: Sub-stream decoding: First, the sub-stream is restored to the original video frames by a hardware decoder, resulting in a low-resolution video image consistent with the sub-stream parameters. Interpolation scaling algorithm adjusts the resolution: Since the sub-stream resolution is lower than the display resolution, the interpolation scaling algorithm includes bilinear interpolation and nearest neighbor interpolation. The low-resolution sub-stream video frames are enlarged according to the physical resolution ratio of the display, outputting an image consistent with the display pixels, while correcting image stretching and distortion issues. Synchronously writing to the underlying video layer of the display frame buffer: The graphics processing of the main control chip and the division of layer areas in the frame buffer result in the scaled sub-stream image being written to the corresponding video memory area of ​​the underlying video layer, preparing for subsequent UI overlay.

[0056] It should be noted that bitstream separation technology is a technique that simultaneously generates multiple encoded streams with different parameters (resolution, frame rate, bit rate) during the video encoding stage. It is commonly used in devices such as surveillance cameras and dashcams. After a single raw video capture, the hardware encoder simultaneously outputs a high-resolution, high-bitrate main bitstream (for storage) and a low-resolution, low-bitrate sub-bitstream (for local preview and low-bandwidth transmission), avoiding the waste of computing power from multiple encodings.

[0057] Among them, the sub-stream uses the hardware decoding built into the main control display link, which does not occupy CPU resources; during video playback, software decoding is only enabled as needed and only low bitrate sub-streams are decoded. In this invention, multi-stream encoding, hardware decoding, and software decoding are enabled in a time-sharing manner according to the working mode, and do not run at full load at the same time, which is not a redundant stacking of computing power.

[0058] Step A3: In the graphics processing unit of the main control chip, a graphics buffer with the same resolution as the SPI display screen is allocated as the final display frame buffer.

[0059] In this embodiment, the encoding process of the image processing and encoding unit in the dashcam is as follows: Raw video acquisition: The camera outputs a high-resolution, high-frame-rate raw video stream, which is then fed into the ISP unit of the main control chip for preprocessing; Multi-stream encoding configuration: In the hardware encoder, the main stream parameters and sub-stream parameters are configured simultaneously; Synchronous encoding generation: The encoder synchronously encodes the same raw video stream according to different parameters, generating two independent encoded streams. The main stream is written to the TF card for storage, and the sub-stream is directly used for local display; Sub-stream extraction: The encoder outputs the sub-stream directly to the display link of the main control chip through an internal channel for subsequent local screen display.

[0060] Step A4: After decoding the extracted sub-stream video data, an interpolation scaling algorithm is used to adjust it to the display screen resolution, and the data is synchronously written to the underlying video layer of the display frame buffer.

[0061] It should be noted that interpolation scaling algorithms are a key technology in embedded display systems for adapting low-resolution images to high-resolution display devices. Essentially, it fills in pixel gaps through mathematical calculations to generate a complete image that matches the target resolution. In dashcam scenarios, it is used to enlarge low-resolution video frames (e.g., 176×144) of the sub-stream to the SPI display resolution (e.g., 480×272), resolving the issue of screen size mismatch.

[0062] It should be noted that commonly used interpolation scaling algorithms include: bilinear interpolation, which calculates the new pixel value by weighted average of neighboring pixels, balancing efficiency and image quality; and the lighter nearest neighbor interpolation, which directly takes the value of the nearest pixel, resulting in lower computational overhead.

[0063] It should be noted that nearest neighbor interpolation directly selects the color value of the nearest pixel in the original image as the new pixel value for the target pixel position. There is no complicated calculation and the computing power overhead is extremely low. It only requires pixel coordinate comparison, which is suitable for main control chips with limited performance. However, after magnification, the image will show obvious jagged edges and pixel block effect, and the image quality is rough. It is suitable for embedded devices that do not have high requirements for image quality and pursue ultimate performance.

[0064] It should be noted that bilinear interpolation is a more refined algorithm. It first performs linear interpolation on the adjacent pixels of the original image in the horizontal direction, and then performs a second interpolation in the vertical direction. The target pixel value is calculated by weighted average, which effectively smooths jagged edges and makes the image transition more natural, balancing efficiency and image quality. However, the computing power is slightly higher than that of nearest neighbor interpolation, but it is still suitable for embedded devices and applicable to dashcam video frame scaling (sub-stream adaptation to display screen). It is the optimal choice for balancing performance and image quality.

[0065] Step A5: Render the user interface elements using a lightweight graphics library, and then alpha blend and overlay the rendered UI layer with the underlying video frame in the display frame buffer.

[0066] In this embodiment, Alpha blending and overlay merges the UI layer and the underlying video image into a set of data according to their transparency ratio. The core logic is as follows: Layers are layered, the underlying video image is stored in the frame buffer, and the UI layer is an independent upper transparent layer; pixel-level blending calculation: for each pixel, the final color is calculated according to the formula: final pixel = (UI pixel × Alpha value + underlying video pixel × (255 - Alpha value)) ÷ 255; the overlay result is written to the frame buffer, and the blended pixel data will be updated to the final display frame buffer as the image to be output to the display screen.

[0067] It should be noted that the lightweight graphics library is a UI rendering tool adapted for embedded devices (dashcams). It renders UI elements such as timestamps, recording status icons, and parameter options based on the frame buffer resources of the main control chip. By calling the graphics library's API, such as drawing rectangles, text, and icons, the pixel data of the UI elements is generated in an independent UI layer buffer. It consumes little computing power and memory, and can quickly complete UI drawing on low-performance main control chips.

[0068] Step A6: The final superimposed image data is pushed to the display screen via DMA streaming through the SPI interface at a safe transmission rate adapted to the bandwidth, avoiding long-term full load on the bus.

[0069] This invention addresses the SPI bandwidth bottleneck by fixing and adapting parameters: the sub-stream resolution is set to 320×180 or 480×272, the frame rate is 10-15fps, and the color format is RGB565 (16-bit). Under the condition that the SPI clock is ≤10MHz, the single frame transmission time is <1ms, which can meet the basic safety display requirements of dashcams for road condition recognition and license plate visibility, and is not a meaningless reduction in image quality.

[0070] In this embodiment, the high-speed transmission mechanism of the SPI interface includes: rate configuration, where the SPI controller of the main control chip is set to a safe clock frequency that adapts to the bandwidth, thereby improving efficiency while ensuring stable transmission; data format adaptation, where the superimposed RGB format image data is encapsulated according to the display screen's interface protocol and serially output through the MOSI line; and streaming transmission, where a continuous frame transmission mode is adopted, where the image data in the frame buffer is pushed sequentially row by row and column by column according to pixel order, avoiding display tearing caused by data interruption.

[0071] In practice, before transmission, a setting display window command is sent via the DC line to specify the display area (full screen) of the entire frame image, and then image pixel data is sent continuously. After the SPI display receives the data, it is directly written into its built-in GRAM (video memory). After the entire frame data transmission is completed, the display controller automatically refreshes the screen to achieve real-time display of the image. The main control chip is strictly synchronized with the display through the SPI clock signal (SCLK) to ensure the accurate transmission timing of each bit of data and avoid data errors caused by excessively high speed.

[0072] It should be noted that, taking a 1080×234 resolution SPI display as an example, the data volume of a single frame is approximately 1080×234×2=505KB. If the SPI transmission rate is 10MHz, the actual effective rate is approximately 8Mbps, and the transmission time of a single frame is only about 0.5ms, which is far lower than the single frame interval of 30fps video, which is about 33ms, fully meeting the requirements for smooth display of dynamic video.

[0073] Menu interaction mode display steps: In step B1, when the user enters the pure menu interface, the main control chip triggers an interrupt command to stop the video data acquisition and overlay process, thereby saving system resources and optimizing the allocation of system computing power.

[0074] In practice, when a user enters a pure menu interface through physical buttons or touch operation in a dashcam, the hardware sends an external interrupt request to the main control chip. After the interrupt controller of the main control chip responds, it triggers control commands to pause the processes of video acquisition by the camera, preprocessing by the ISP unit, and multi-stream encoding by the hardware encoder. It also shuts down the computing power usage of the image processing and encoding units, switches hardware resources such as the ISP and encoder from video processing mode to low-power standby mode, stops the output of sub-streams to the graphics processing unit, disconnects the connection between the video layer and the frame buffer, and retains only the UI rendering link of the LVGL graphics library.

[0075] It should be noted that video capture, encoding, and decoding operations typically consume more than 60% of the main control chip's computing power. After stopping, the resources can be released for LVGL UI rendering, improving the smoothness of menu operations. The SPI interface does not need to transmit dynamic video streams, and the bandwidth is used entirely for menu data transmission, avoiding interaction delays. Hardware modules (such as cameras and encoders) enter a low-power state, reducing the dashcam's power consumption, which is especially suitable for low-power scenarios such as parking monitoring.

[0076] When the user exits the menu interface, the main control chip triggers an interrupt again and reverses the recovery process: restart video capture → start ISP preprocessing → restore multi-stream encoding → sub-stream re-enter the display link → video layer overlay with UI. The entire process is completed within 100ms, achieving seamless switching between menu and video modes.

[0077] Step B2: Enable only the LVGL graphics library to render the full menu interface.

[0078] In this embodiment, the LVGL graphics library rendering is based on the frame buffer device of the main control chip. The core process is as follows: UI resource loading: LVGL calls the pre-stored menu layout configuration, icon materials and interaction logic code to initialize the menu rendering environment; control drawing optimization: through the hardware acceleration interface of LVGL, multi-level menu lists, parameter options, sliders, confirmation buttons and other UI controls are rendered in batches, supporting visual effects such as anti-aliasing, gradient fill and rounded corner display. At the same time, a local redraw mechanism is adopted to update only the areas that change when switching menus, reducing unnecessary rendering overhead; rendering result caching: the pixel data of the complete menu interface is stored in an independent area of ​​the frame buffer to ensure the integrity and stability of the interface data.

[0079] Step B3: The rendered menu interface data is pushed to the SPI display via the SPI interface. Since there is no need to transmit dynamic video data, the bandwidth of the SPI interface can ensure the smoothness of menu operation.

[0080] In practice, the menu interface rendered by LVGL is static image data, with no need for real-time updates of dynamic video streams. The data volume depends only on the display resolution. For example, the data volume of a 480×272 resolution screen is approximately 393KB / frame. It is pushed to the SPI display screen via an asynchronous transmission mode at a transmission rate of 5-10MHz through the SPI 4-wire interface. The theoretical transmission bandwidth of the SPI interface is calculated as "transmission rate × bus width ÷ 8", such as 10MHz × 4 lines ÷ 8 = 5MB / s. The refresh requirement of the static menu interface is only 10-15fps, and the data transmission time of a single frame is approximately 80μs, which is far below the bandwidth limit of the SPI interface. Since there is no need to synchronously transmit dynamic video streams, which require more than 80% of the SPI bandwidth, the remaining bandwidth of the SPI interface in the menu interaction mode fully meets the real-time response requirements of operations such as control switching and parameter adjustment, avoiding ghosting, stuttering, or operation delays, and ensuring a smooth user experience.

[0081] Video playback mode display steps: Step C1: The user selects to play back the recorded video file, which is a high-resolution main stream.

[0082] In this embodiment, the video playback mode adopts a sub-stream priority and main stream optional decoding strategy to balance playback smoothness and hardware computing power consumption. The recorded video file contains two encoded streams: a high-resolution main stream for archiving and a low-bitrate sub-stream for fast preview. The two streams are integrated into a single file using encapsulation formats such as MP4, with the sub-stream existing as a preview track. After the user triggers the playback operation, the main control chip prioritizes reading the sub-stream data in the file instead of directly decoding the main stream. The sub-stream has lower resolution and bitrate, requiring less CPU computing power, thus avoiding stuttering caused by the low-performance main control chip decoding the main stream.

[0083] In step C2, the main control chip calls the software decoding library to perform software decoding on the video file. To reduce decoding overhead, it prioritizes decoding the low bitrate sub-streams contained in the file.

[0084] In practice, the main control chip calls software decoding libraries such as FFmpeg to complete the sub-stream decoding. The specific steps are as follows: file parsing and stream separation: the decoding library first parses the video file's encapsulation format, such as the moov atom of MP4, and locates the encoded data track of the sub-stream, which is usually in H.264 / H.265 format; software decoding execution: based on the CPU's multi-core scheduling, the extracted sub-stream data is decoded at the frame level, restoring the encoded compressed data to the original video frames in YUV format; decoding adaptation: the decoded sub-stream video frames have a lower resolution and are directly sent to the graphics processing unit for scaling, UI overlay, and other operations to adapt to the display resolution.

[0085] If users need to view high-definition images, such as replaying critical accident clips, they can switch to main stream decoding through the UI. At this time, the decoding library stops reading sub-streams and starts parsing the main stream data. Although this will increase the CPU load, it can output high-definition images with the same quality as the recorded images, satisfying the need for detailed viewing.

[0086] Step C3 involves overlaying the video frames decoded by software onto the playback control UI rendered by LVGL.

[0087] In this embodiment, the layer overlay mechanism for video frames and the playback control UI includes independent processing of two layers and pixel-level overlay synthesis; the bottom layer: the YUV format video frames output by software decoding are written to the bottom video channel of the frame buffer after color space conversion and resolution scaling; the top layer: the LVGL graphics library renders the playback control UI components based on user interaction requirements, and the UI data is stored in the upper transparent layer of the frame buffer in RGB format with an alpha channel, supporting 0-255 levels of transparency adjustment; the graphics processing unit of the main control chip uses a hardware-accelerated alpha blending algorithm to use a fixed alpha value for static UI areas and a high-brightness alpha value for dynamic interactive areas, ensuring UI readability without obscuring key video content.

[0088] It should be noted that the frame buffer of the main control chip is divided into an independent low-level video channel and an upper-level UI channel. The low-level channel is dedicated to storing video frame data after color conversion (YUV→RGB) and scaling. The data format is strictly matched with the physical resolution of the display screen. The upper-level channel stores UI data rendered by LVGL, using the ARGB8888 format with an alpha channel. In addition to RGB color information, each pixel contains an additional 8-bit alpha transparency value.

[0089] It should be noted that LVGL uses differentiated rendering for different components of the playback control UI. For static UI components, such as the play button icon and timestamp text, the Alpha value is set to 192 (75% opaque), which ensures clear visibility while allowing the underlying video image to show through. For dynamic interactive components, such as the progress bar drag block and the speed selection highlight box, the Alpha value is set to 255 (completely opaque), which, together with the highlight color scheme, highlights the user's focus.

[0090] Step C4: The superimposed image data is pushed to the display screen through the SPI interface. The SPI data transmission rhythm is dynamically adjusted according to the decoding frame rate to ensure the synchronization of video playback and UI interaction, and to achieve a stable playback effect that meets the needs of viewing driving records.

[0091] It should be noted that the main control chip obtains the decoding frame rate of the current video frame in real time through the callback function of the decoding library, such as 10fps for the sub-stream and 30fps for the main stream, and records the timestamp of each frame decoding completion to form a dynamic frame rate monitoring linked list.

[0092] The SPI controller dynamically adjusts the data transmission parameters based on the monitored decoding frame rate. In high frame rate scenarios (main stream 30fps), the SPI clock frequency is increased to the highest supported value, such as 20MHz, and DMA (direct memory access) batch transfer mode is adopted. The data transmission time of a single frame is controlled within 30μs, matching the playback interval of 33ms / frame. In low frame rate scenarios (sub-stream 10fps), the SPI clock frequency is reduced to 5-10MHz, and an interrupt-triggered transmission mode is adopted to reduce invalid bandwidth occupation and lower system power consumption. Synchronous calibration involves correcting the transmission rhythm by comparing timestamps after every 3-5 frames of data transmitted, thus avoiding video stuttering or audio-visual desynchronization caused by decoding delays.

[0093] Example 2: This application provides a dashcam video display system based on an SPI interface display screen. The dashcam video display system includes: The camera module is used to capture raw video streams during driving and directly outputs raw video data to the image processing and encoding unit of the main control chip.

[0094] The main control chip module, including an image processing and encoding unit, a software decoder, a graphics processing and frame buffer, and an SPI controller, connects to the camera, storage module, and display screen to complete the entire process of video acquisition, encoding, storage, decoding, synthesis, and display.

[0095] The storage module stores the main bitstream video file encoded by the main control chip, receives the encoded main bitstream written by the main control chip, and provides the video file to the software decoder of the main control chip during playback.

[0096] The SPI display module receives SPI data and displays the final image, enabling the display of video previews, menus, and playback screens.

[0097] In this embodiment, the main control chip of the dashcam is the Sigmastar SSC375 chip, which has powerful H.264 / H.265 video encoding capabilities, but no RGB / MIPI interface. The display screen is a 320*180 resolution SPI interface IPS screen.

[0098] In video recording mode: The SSC375 continuously encodes the 1080P main stream and stores it in the TF card. At the same time, the ISP generates a 320*180@15fps sub-stream (adapted to SPI bandwidth). This sub-stream is directly sent to the underlying layer of the GPU's frame buffer (320*180). The LVGL engine draws the UI (such as time, GPS speed icons, etc.) on the GPU and mixes it with the video. The final mixed image is continuously sent to the SPI screen via SPI.

[0099] When the user presses the menu button, the system enters menu interaction mode: Background video recording continues, but sub-stream generation and frame buffering are stopped, the frame buffer is cleared, LVGL draws the complete settings menu, and the SPI interface only needs to transmit the changed pixel data when the menu changes (such as page turning), resulting in extremely fast response speed.

[0100] When the user selects video playback: The system calls the FFmpeg software decoder to read the sub-streams in the video file for decoding. The decoded video frames are then overlaid on the playback control UI and displayed via the SPI interface. Although the frame rate may be lower than the real-time preview, it is sufficient to view the playback content clearly and smoothly.

[0101] This embodiment is designed for optimal adaptation in entry-level, low-cost vehicle scenarios. The multi-stream, hardware decoding, and software decoding introduced are all minimum necessary modules, which are activated in a time-sharing manner according to the mode. There is no redundant computing power. The sub-stream parameters are strictly matched to the SPI bandwidth limit, which can clearly identify road conditions and license plates, and meet the legal basic usage requirements of dashcams.

[0102] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A video display method for a dashcam based on an SPI interface display screen, wherein the main control chip of the dashcam has video encoding capabilities and an SPI interface, and the SPI interface is connected to an SPI display screen, characterized in that, The dashcam video display method includes the following modes: Video recording mode display steps: Step A1: The image processing unit built into the main control chip continuously captures video data from the camera and encodes and stores it. Step A2 utilizes the multi-stream encoding capability natively supported by the main control chip's hardware encoder to simultaneously generate a high-resolution main stream for storage and a low-resolution, low-bitrate sub-stream dedicated to SPI display. This does not require adding an additional computing power module and represents a targeted reuse of the chip's existing hardware capabilities. Step A3: In the graphics processing unit of the main control chip, a graphics buffer with the same resolution as the SPI display screen is allocated as the final display frame buffer. Step A4: After decoding the extracted sub-stream video data, an interpolation scaling algorithm is used to adjust it to the display screen resolution, and the data is synchronously written to the underlying video layer of the display frame buffer. Step A5: Use a lightweight graphics library to render user interface elements, and then perform alpha blending and overlay on the rendered UI layer and the underlying video frame in the display frame buffer. Step A6: The final superimposed image data is pushed to the display screen via DMA streaming through the SPI interface at a safe transmission rate adapted to the bandwidth, avoiding long-term full load on the bus. Menu interaction mode display steps: Step B1: When the user enters the pure menu interface, the main control chip triggers an interrupt command to stop the video data acquisition and overlay process, thereby saving system resources and optimizing the allocation of system computing power. Step B2: Enable only the LVGL graphics library to render the full menu interface; Step B3: Push the rendered menu interface data to the SPI display via the SPI interface. Since there is no need to transmit dynamic video data, the bandwidth of the SPI interface can ensure the smoothness of menu operation. Video playback mode display steps: Step C1: The user selects to play back the recorded video file, which is a high-resolution main stream. In step C2, the main control chip calls the software decoding library to perform software decoding on the video file. To reduce decoding overhead, it prioritizes decoding the low bitrate sub-streams contained in the file. Step C3: Overlay the video frames decoded by software with the playback control UI rendered by LVGL. Step C4: The superimposed image data is pushed to the display screen through the SPI interface. The SPI data transmission rhythm is dynamically adjusted according to the decoding frame rate to ensure the synchronization of video playback and UI interaction, and to achieve a stable playback effect that meets the needs of viewing driving records.

2. The video display method for a dashcam based on an SPI interface display screen according to claim 1, characterized in that: The main control chip specifically includes: The image processing and encoding unit integrates an ISP and a hardware encoder, and is responsible for the acquisition, preprocessing and hardware encoding of camera video data, realizing hardware-level encoding and stream separation, while taking into account both storage and display requirements. Graphics processing and frame buffer, including the GPU and dedicated video memory area, is responsible for compositing the displayed image, layer blending and frame data caching, and ensures the display effect through hardware acceleration and buffering mechanisms; The software decoder uses CPU computing power to perform software decoding of video files, enabling software decoding and bitstream adaptation of stored video files, adapting to the software decoding needs of playback scenarios, and supporting intelligent bitstream switching to optimize performance. The SPI controller serves as the communication interface between the main control chip and the SPI display screen, enabling stable data transmission through high-speed communication and timing control.

3. The video display method for a dashcam based on an SPI interface display screen according to claim 2, characterized in that: The image processing and encoding unit performs the following encoding process in the dashcam: Raw video capture: The camera outputs a high-resolution, high-frame-rate raw video stream, which is then fed into the ISP unit of the main control chip for preprocessing. Multi-stream encoding configuration allows for the simultaneous configuration of main stream parameters and sub-stream parameters within the hardware encoder. Synchronous encoding generation: The encoder synchronously encodes the same original video stream with different parameters to generate two independent encoded streams. The main stream is written to the TF card for storage, and the sub-stream is directly used for local display. Sub-stream extraction: The encoder outputs the sub-stream directly to the display link of the main control chip through an internal channel for subsequent local display.

4. The video display method for a dashcam based on an SPI interface display screen according to claim 1, characterized in that: The sub-stream adaptation to the display resolution includes three steps: decoding, scaling, and writing to the frame buffer. The specific process is as follows: Substream decoding first uses a hardware decoder to restore it to the original video frames, resulting in a low-resolution video image with the same parameters as the substream. Interpolation scaling algorithms adjust the resolution. When the sub-stream resolution is lower than the display resolution, the interpolation scaling algorithm includes bilinear interpolation and nearest neighbor interpolation. It enlarges the low-resolution sub-stream video frames according to the physical resolution of the display screen, outputting an image consistent with the display screen pixels, while correcting image stretching and distortion problems. The underlying video layer is synchronously written to the display frame buffer. The graphics processing of the main control chip is combined with the division of the layer area in the frame buffer. The scaled sub-stream image is written to the video memory area corresponding to the underlying video layer, preparing for the subsequent UI overlay.

5. A video display method for a dashcam based on an SPI interface display screen according to claim 1, characterized in that: The Alpha blending overlay merges the UI layer and the underlying video frame into a single set of data based on their transparency ratios. The core logic is as follows: The layers are layered; the underlying video frame is stored in the frame buffer, while the UI layer is an independent upper transparent layer. Pixel-level blending calculation: For each pixel, the final color is calculated according to the formula: Final pixel = (UI pixel × Alpha value + underlying video pixel × (255 - Alpha value)) ÷ 255; The superposition result is written to the frame buffer, and the mixed pixel data is updated to the final display frame buffer as the image to be output to the display screen.

6. The video display method for a dashcam based on an SPI interface display screen according to claim 1, characterized in that: The high-speed transmission mechanism of the SPI interface includes: In terms of speed configuration, the SPI controller of the main control chip is set to a safe clock frequency that adapts to the bandwidth, thereby improving efficiency while ensuring stable transmission. Data format adaptation: The superimposed RGB format image data is encapsulated according to the display screen's interface protocol and output serially via the MOSI line; Streaming transmission uses a continuous frame transmission mode, pushing image data in the frame buffer row by row and column by column in pixel order to avoid display tearing caused by data interruption.

7. A video display method for a dashcam based on an SPI interface display screen according to claim 1, characterized in that: The LVGL graphics library rendering is based on the frame buffer device of the main control chip, and the core process is as follows: UI resources are loaded, and LVGL calls the pre-stored menu layout configuration, icon materials and interaction logic code to initialize the menu rendering environment; Control rendering is optimized. Through the hardware acceleration interface of LVGL, multi-level menu lists, parameter options, sliders, confirmation buttons and other UI controls are rendered in batches. It supports visual effects such as anti-aliasing, gradient fill and rounded corner display. At the same time, a local redraw mechanism is adopted to update only the area that changes when switching menus, reducing unnecessary rendering overhead. The rendering result cache stores the pixel data of the complete menu interface in a separate area of ​​the frame buffer, ensuring the integrity and stability of the interface data.

8. A video display method for a vehicle recorder based on an SPI interface display screen according to claim 1, characterized in that: The video playback mode adopts a decoding strategy that prioritizes sub-streams and allows selection of the main stream, balancing playback smoothness with hardware computing power consumption. The recorded video file contains two encoded streams: a high-resolution main stream for archiving and a low-bitrate sub-stream for fast previewing. The two streams are integrated into a single file using container formats such as MP4, and the sub-stream exists as a preview track. After the user triggers the playback operation, the main control chip prioritizes reading the sub-stream data in the file instead of directly decoding the main stream. The sub-stream has lower resolution and bitrate, and requires less CPU computing power, thus avoiding stuttering caused by the low-performance main control chip decoding the main stream.

9. A video display method for a vehicle recorder based on an SPI interface display screen according to claim 1, characterized in that: The layer overlay mechanism of the video frame and playback control UI includes independent processing of dual layers and pixel-level overlay synthesis; Bottom layer: YUV format video frames output by software decoding, after color space conversion and resolution scaling, are written to the bottom video channel of the frame buffer; Upper layer: The LVGL graphics library, based on user interaction needs, renders and plays back UI components. UI data is stored in the upper transparent layer of the frame buffer in RGB format with an alpha channel, supporting 0-255 levels of transparency adjustment. The graphics processing unit of the main control chip uses a hardware-accelerated alpha blending algorithm to apply a fixed alpha value to static UI areas and a highlighted alpha value to dynamic interactive areas, ensuring UI readability without obscuring key video content.

10. A dashcam video display system based on an SPI interface display screen, used to execute the dashcam video display method based on an SPI interface display screen as described in any one of claims 1 to 9, characterized in that, The dashcam video display system includes: The camera module is used to capture raw video streams during driving and directly outputs raw video data to the image processing and encoding unit of the main control chip. The main control chip module, including an image processing and encoding unit, a software decoder, a graphics processing and frame buffer, and an SPI controller, connects to the camera, storage module, and display screen to complete the entire process of video acquisition, encoding, storage, decoding, synthesis, and display. The storage module stores the main stream video file encoded by the main control chip, receives the encoded main stream written by the main control chip, and provides the video file to the software decoder of the main control chip during playback. The SPI display module receives SPI data and displays the final image, enabling the display of video previews, menus, and playback screens.

Images