说实话第一次在ESP32-P4上把ST7703的RGB屏跑出24fps视频轮播效果时我确实在屏幕前面愣了好几秒。之前我一直觉得“MCU做视频播放”就是玩个GIF轮播真正上手P4这颗带MIPI-DSI控制器和H.264硬解的单片机之后才意识到这套方案已经能撑起一个正经的视频轮播器720×720的屏幕24fps稳定刷新多段视频循环切换SD卡换素材即插即用。如果你正在纠结“用MCU做广告机/数字相框/展会演示屏到底行不行”或者已经被SPI屏的刷新率折磨得想放弃这篇文章就是给你写的。我会把整个项目从0到1完整拆开为什么选ESP32-P4和ST7703、硬件怎么接线、视频怎么预处理、上游怎么解码、下游怎么送显以及最后怎么把帧率稳在24fps。代码部分不是截几个功能片段而是把初始化、解码、显示、轮播的完整闭环给出来你照着抄就能跑。1. 项目先导为什么这套组合能打1.1 需求痛点视频轮播器到底难在哪视频轮播器最常见的使用场景是门店广告屏、展会演示、产品展厅、数字相框这一类。它们的共同要求是能循环放视频、画面尽量清晰流畅、7×24小时稳定运行、换内容方便最好还有一个相对合理的成本。过去要做这种事大家的首选是安卓盒子或者树莓派但这些方案的启动速度、系统稳定性、外设成本以及每次换视频还要连鼠标键盘的维护方式放在嵌入式场景里多少有点杀鸡用牛刀。反过来如果你用传统MCU比如ESP32-S3、STM32F4这类走RGB8080并口或者SPI接口刷一帧480×480的画面都够CPU喘半天更别提24fps的视频流了。问题拆开来看其实就三点一是MCU算力够不够解码视频帧二是屏幕数据通道能不能扛住高分辨率高帧率的带宽三是整个系统能不能保证帧率稳定不撕裂不闪烁。传统MCU卡在第二和第三条上而ESP32-P4这颗芯片的MIPI-DSI外设和硬件编解码器刚好把这几条全打通了。1.2 核心选型ESP32-P4和ST7703分工明确先聊聊为什么选ESP32-P4。它是乐鑫的旗舰级MCU双核RISC-V跑到400MHz内置了MIPI-DSI控制器、MIPI-CSI摄像头接口、H.264编码器和解码器还有独立的JPEG编解码器。这些能力放到以前的MCU上根本不敢想。以前MCU做显示最高效的也就是SPI_DMA刷屏分辨率一高就得靠牺牲帧率来换而P4有专门的硬件解码单元CPU只需要把压缩流丢给硬件解码器然后把解码出来的帧搬运到显存即可。搬运这件事也能用DMA完成配上双buffer甚至三buffer帧率自然就稳了。再聊ST7703。很多朋友第一次看到ST7703屏幕会有点懵这芯片到底算什么角色简单说它是一颗MIPI-DSI转RGB的驱动桥芯片面板本身是RGB接口的LCDST7703负责接收MCU发来的MIPI-DSI信号转换成RGB并行信号去驱动液晶玻璃。所以你买到的“ST7703屏幕模组”其实是一个“MIPI-DSI输入RGB输出到LCD”的完整模组。ST7703很常见的分辨率是480×480、720×720这类方形屏色彩支持RGB565或者RGB888刷新率可以做到30fps以上厂商一般还会提供初始化序列Init Code你烧进去基本就能用。ES32-P4负责“大脑”的部分ST7703负责“显示驱动”的部分两者通过MIPI-DSI这根高速管道连接。选这个组合而不是直接上Linux小板最大的理由是接口简单、启动快、代码可控、纯MCU方案在工业级稳定性上更让人放心。1.3 24fps的可行性带宽与算力都算过一遍先说结论720×720 RGB565、24fps这套配置对ESP32-P4来说是绰绰有余的。我们来算一笔账。一帧画面720×720像素每个像素RGB565占2字节那么一帧的数据量就是720×720×2 1,036,800 字节约1MB。24fps的话每秒需要传输约24.9MB的数据折算成带宽就是24.9 × 8 ≈ 200Mbps。MIPI-DSI这边ESP32-P4的D-PHY通常可以跑每lane 1Gbps左右即使只开2 lane理论带宽也有2Gbps远高于200Mbps的实际需求。所以显示通道完全不是瓶颈。解码这边如果走MJPEG方案JPEG硬件解码器能轻松处理720×720的帧如果走H.264方案P4内置的H.264解码器也能扛住这个分辨率。真正的瓶颈往往不在MCU本身而在SD卡的读取速度和内存拷贝策略。这个问题我会在第4章仔细讲但至少从芯片选型层面来说24fps是完全可以达成的目标。注意很多ST7703模组标称支持60fps甚至更高但那是面板的极限能力实际工程里还要考虑解码、搬运、刷新同步的开销定在24fps是一个兼顾流畅度和稳定性的务实选择尤其适合视频广告机这类场景。2. 硬件准备、接线与信号链路2.1 物料清单复制这套项目之前先把东西备齐。以下是我实际使用的清单全部列出来你直接照着买就行。物料型号/规格备注主控开发板ESP32-P4 官方 DevKit / 任意带MIPI-DSI引出的开发板注意确认DSI接口已经引到排针或FPC座LCD模组ST7703驱动720×720 RGB屏最好带RGB888/RGB565切换存储介质TF/SD卡Class 10或以上建议16GB以上放视频素材电源5V/2A及以上USB电源MIPI屏背光MCU同时耗电别用劣质充电头杜邦线/FPC转接板视开发板而定验证阶段用杜邦线成品建议打样FPC逻辑分析仪/示波器可选排查MIPI信号问题时有用有一点要提醒买ST7703屏幕的时候不要只看店家给的“接口类型”描述。很多ST7703模组上面既有MIPI-DSI的FPC座还有一排引脚看起来像是8080并口但那一排引脚实际是RGB信号并行输出给屏体用的不是给你接MCU的。所以你只需要关注模组的MIPI-DSI输入接口和背光、复位引脚。2.2 接线要点MIPI-DSI、背光、复位MIPI-DSI看起来很高端接线其实不算复杂但每一条都有讲究。ESP32-P4开发板上的DSI接口一般引出以下信号时钟线DSI_CLKP、DSI_CLKN这是一对差分时钟数据线DSI_D0P、D0N、D1P、D1N部分板子有4 lane那还有D2P、D2N、D3P、D3N复位线LCD_RST背光线LCD_BL / LCD_PWM电源3.3V、GND差分信号讲究的是等长、阻抗匹配。在开发板上走线已经被Layout固定好了你要做的是把它和屏幕排线连起来。如果是用Dupont线验证注意把P/N对应好不要交叉接反。我曾经有一块板子一直花屏最后发现是D0P和D0N接反了MIPI链路能Link上但数据全乱。快速接线参考以2 lane为例ESP32-P4开发板引脚ST7703模组引脚说明3V3VCC模组数字电源5V / VBUSLED背光正极背光电流较大建议从5V取GNDGND共地DSI_CLKPCLKP差分时钟正DSI_CLKNCLKN差分时钟负DSI_D0PD0PLane0正DSI_D0ND0NLane0负DSI_D1PD1PLane1正DSI_D1ND1NLane1负GPIO如4RESET复位低有效GPIO如5BL_PWM背光PWM接线里最容易翻车的两个点一是背光供电。如果模组上LED和LED-直接接了5V电源那么背光电流可能达到几百毫安USB供电电流不足的话屏幕一亮整个系统就重启。二是复位脚的时序。ST7703的复位要求低电平保持一段时间再拉高如果上来直接用Chip Enable引脚代替有的屏会初始化不彻底直接黑屏。2.3 电气细节为什么不能随便乱接MIPI-DSI是高速差分信号理想的工作环境是PCB上做100Ω差分阻抗匹配。开发板上信号线已经布好但当你要把板子和屏幕用杜邦线连起来时这段线就成了阻抗不连续的“天线”。如果是低速的I2C、UART乱接问题不大MIPI-DSI跑在Gbps级别信号完整性就很敏感。我的建议是验证阶段可以短距离用杜邦线但线长控制在10cm以内并且把P/N两根线绞在一起能有效减少共模干扰。另外ST7703模组供电一般分两路数字逻辑供电VCC是3.3V背光LED供电需要单独接。我见过不少新手直接把背光LED接到3.3V结果是屏幕能亮但非常暗因为白光LED的正向导通压降和电流需求摆在那里。硬件层面先把这两个电源分开能避免很多莫名其妙的症状。3. 搭建开发环境与最小工程3.1 ESP-IDF环境准备ESP32-P4的上手方式和普通ESP32系列差不多官方推荐用ESP-IDF v5.4及以上版本。装好IDF之后首次编译P4的工程需要执行idf.py set-target esp32p4如果还没安装P4的支持包先执行. $IDF_PATH/export.sh idf.py install esp32p4考虑到P4是RISC-V内核工具链和之前Xtensa的ESP32不太一样刚装完环境后第一次编译耗时比较长耐心等就行。建议开发完一个可用的最小工程后把编译缓存保留好后续做增量编译很快。3.2 创建工程并配置Board Support最稳妥的方式是在IDF的组件库里直接找到MIPI-DSI的示例工程。我建的工程目录结构大概是这样的video_player/ ├── CMakeLists.txt ├── main/ │ ├── CMakeLists.txt │ ├── main.c │ ├── display.c │ ├── display.h │ ├── video_decoder.c │ ├── video_decoder.h │ ├── player.c │ └── player.h └── sdkconfig.defaults在sdkconfig.defaults里需要额外开启几个关键选项CONFIG_ESP_LCD_MIPI_DSIy CONFIG_ESP_LCD_ST7703y CONFIG_SPIRAMy CONFIG_SPIRAM_MODE_OCTySPIRAMPSRAM对视频播放至关重要。P4虽然有内置SRAM但显示缓冲和视频解码帧缓冲动辄几MB肯定得放在PSRAM里。如果不开PSRAM程序能编译过但跑到申请内存时就崩了。3.3 点亮屏幕的最小工程验证在写播放器代码之前我强烈建议先跑一个纯色填充的小程序确认MIPI链路和ST7703初始化正常。代码核心就是创建DSI Bus、创建Panel IO、创建ST7703屏幕实例然后填充纯色给面板。下面这段是迷你验证代码你可以直接复制到main.c里测试#include stdio.h #include freertos/FreeRTOS.h #include freertos/task.h #include esp_lcd_mipi_dsi.h #include esp_lcd_panel_st7703.h #include esp_lcd_panel_ops.h void app_main(void) { // 1. 创建 MIPI DSI Bus esp_lcd_dsi_bus_config_t bus_config { .bus_id 0, .num_data_lanes 2, .phy_clk_src MIPI_DSI_PHY_CLK_SRC_DEFAULT, .lane_bit_rate_mbps 1000, // 1Gbps per lane }; esp_lcd_dsi_bus_handle_t mipi_dsi_bus; ESP_ERROR_CHECK(esp_lcd_new_dsi_bus(bus_config, mipi_dsi_bus)); // 2. 创建 DSI Panel IO esp_lcd_dsi_io_config_t io_config { .virtual_channel 0, .lcd_cmd_bits 8, .lcd_param_bits 8, }; esp_lcd_panel_io_handle_t mipi_dsi_io; ESP_ERROR_CHECK(esp_lcd_new_panel_io_dsi(mipi_dsi_bus, io_config, mipi_dsi_io)); // 3. 创建并初始化 ST7703 面板 esp_lcd_panel_dev_config_t panel_config { .reset_gpio_num 4, .rgb_ele_order LCD_RGB_ELEMENT_ORDER_RGB, .bits_per_pixel 16, // RGB565 }; esp_lcd_panel_handle_t panel; ESP_ERROR_CHECK(esp_lcd_new_panel_st7703(mipi_dsi_io, panel_config, panel)); ESP_ERROR_CHECK(esp_lcd_panel_reset(panel)); ESP_ERROR_CHECK(esp_lcd_panel_init(panel)); ESP_ERROR_CHECK(esp_lcd_panel_disp_on_off(panel, true)); // 4. 填充一个纯色帧并刷上去 uint16_t *frame heap_caps_malloc(720 * 720 * 2, MALLOC_CAP_SPIRAM); for (int i 0; i 720 * 720; i) { frame[i] 0xF800; // 红色 } esp_lcd_panel_draw_bitmap(panel, 0, 0, 720, 720, frame); vTaskDelay(pdMS_TO_TICKS(5000)); // 绿色 for (int i 0; i 720 * 720; i) { frame[i] 0x07E0; } esp_lcd_panel_draw_bitmap(panel, 0, 0, 720, 720, frame); vTaskDelay(pdMS_TO_TICKS(5000)); }如果你看到屏幕先变红再变绿说明MIPI链路、ST7703初始化、帧缓冲申请全部正常接下来可以放心往播放器方向走。如果这里是黑屏先别往下写播放器先把硬件链路问题找出来否则后面排错会很痛苦。注意如果你的屏幕是RGB888模组bits_per_pixel可以改成24同时帧缓冲也要对应调整每个像素3字节。一般ST7703模组默认支持RGB565RGB888要额外切换数据格式最好看一眼店家的初始化文档。4. 视频源准备转码与播放列表设计4.1 为什么不能直接播放电脑里的视频很多人会问我有一堆MP4直接拷到SD卡不就行了原则上可以但你要考虑两件事。一是编码格式兼容性虽然ESP32-P4有H.264硬解但它支持的H.264是有限制的Main Profile、High Profile复杂的参考帧、B帧都有可能让硬解性能大打折扣。二是码率和分辨率720×720只是屏幕分辨率视频文件本身如果是4K硬解出来的画面还得缩放很浪费算力。所以我的建议是不要直接扔原始文件统一用ffmpeg预处理成最适合P4的格式。这一步一劳永逸后面所有视频素材都能无缝播放。4.2 两套预处理方案对比MJPEG与H.264我实际测试了两条路线各有取舍方案清晰度CPU消耗硬解依赖帧率稳定性适合场景MJPEG中高静止画面压缩比高很低不依赖H.264仅JPEG解码非常稳画面变化不剧烈的内容如展示图、产品视频H.264高压缩率更高动态画面更优中必须依赖P4的H.264硬解需要额外调优动态画面多、期望更高清晰度时我现在的默认方案是MJPEG因为JPEG硬解码器比H.264更简单丢帧概率更低代码也好写。H.264则在后面可以平滑升级。转MJPEG的命令是这样的ffmpeg -i input.mp4 -vf scale720:720:flagslanczos -r 24 -an -c:v mjpeg -q:v 3 output.mjpeg这里有几个关键参数解释一下-r 24强制抽帧成24fps避免视频原本是30fps导致播放时长和显示节奏不匹配-q:v 3JPEG质量1是最大质量5以下观感都还行3是兼顾文件大小和质量的选择-an视频轮播器暂时不需要音频直接用轮播逻辑或者外接背景音乐即可转H.264的话命令稍微改一下ffmpeg -i input.mp4 -vf scale720:720:flagslanczos -r 24 -an -c:v libx264 -profile:v baseline -level 3.0 -pix_fmt yuv420p -movflags faststart output.mp4H.264转码时务必注意-profile:v baseline和-pix_fmt yuv420p这直接关系到P4硬解是否支持。B帧多的High Profile文件在某些固件版本上解码到一半会卡死。4.3 播放列表与SD卡结构视频轮播器顾名思义要“轮播”所以多个视频文件不能只是简单堆在根目录。我在SD卡里建了这样的目录结构/sd ├── playlist.txt ├── video/ │ ├── 01.mjpeg │ ├── 02.mjpeg │ └── 03.mjpeg └── logo.jpgplaylist.txt的内容很简单video/01.mjpeg 5 video/02.mjpeg 10 video/03.mjpeg 8第一列是路径第二列是停留/播放秒数。有些素材是循环动画但不需要播放完整视频这时候在播放列表里指定秒数就行。程序启动后先读这个文件把路径列表解析到内存里然后逐个打开、解码、播放、切换。这样换素材就非常方便直接改txt文件就行不用重新编译固件。5. 核心代码实现播放器闭环5.1 初始化Display的完整过程前面最小工程里已经把MIPI链路过了一遍真正做播放器时要在初始化环节把帧率相关的VSync和显示时序一并配置好。这个display_init函数里包含了DSI Bus、Panel IO、ST7703以及DPI模式的完整配置static esp_lcd_panel_handle_t s_panel NULL; static void display_init(void) { // MIPI DSI Bus 配置 esp_lcd_dsi_bus_config_t bus_config { .bus_id 0, .num_data_lanes 2, .phy_clk_src MIPI_DSI_PHY_CLK_SRC_DEFAULT, .lane_bit_rate_mbps 1000, }; esp_lcd_dsi_bus_handle_t mipi_dsi_bus; ESP_ERROR_CHECK(esp_lcd_new_dsi_bus(bus_config, mipi_dsi_bus)); // Panel IO 配置 esp_lcd_dsi_io_config_t io_config { .virtual_channel 0, .lcd_cmd_bits 8, .lcd_param_bits 8, }; esp_lcd_panel_io_handle_t mipi_dsi_io; ESP_ERROR_CHECK(esp_lcd_new_panel_io_dsi(mipi_dsi_bus, io_config, mipi_dsi_io)); // ST7703 面板配置 esp_lcd_panel_dev_config_t panel_config { .reset_gpio_num 4, .rgb_ele_order LCD_RGB_ELEMENT_ORDER_RGB, .bits_per_pixel 16, }; esp_lcd_panel_handle_t panel; ESP_ERROR_CHECK(esp_lcd_new_panel_st7703(mipi_dsi_io, panel_config, panel)); ESP_ERROR_CHECK(esp_lcd_panel_reset(panel)); ESP_ERROR_CHECK(esp_lcd_panel_init(panel)); // DPI (video mode) 配置 esp_lcd_dpi_panel_config_t dpi_config { .pixel_clock 24000000, // Pixel Clock 24MHz对应 24fps .h_res 720, .v_res 720, .hsync_pulse_width 16, .hsync_back_porch 16, .hsync_front_porch 16, .vsync_pulse_width 4, .vsync_back_porch 4, .vsync_front_porch 4, }; ESP_ERROR_CHECK(esp_lcd_dpi_panel_config(panel, dpi_config)); ESP_ERROR_CHECK(esp_lcd_panel_disp_on_off(panel, true)); s_panel panel; }注意DPI模式下MCU不直接控制每一个像素的刷新时序而是通过MIPI-DSI的视频模式把像素流持续送给ST7703ST7703再自己控制LCD的行场扫描。这种方式非常省CPUMCU只需要往frame buffer里写内容屏幕就会自动刷新帧率稳定性也更好。5.2 解码线程与显示线程的配合视频播放器的核心逻辑其实就两件事解码一帧送显一帧。但“解码”和“送显”的速度不一样必须用多线程和帧缓冲来解耦。我的设计是一个Decoder Task读取当前视频文件取出一帧压缩数据交给硬件解码器解出RGB565帧写入双缓冲中的后台缓冲。一个Display Task等到VSync事件把已解码的帧缓冲通过esp_lcd_panel_draw_bitmap刷到屏幕上然后切换前后台缓冲。双缓冲能有效防止撕裂tearing。如果只用一个buffer解码线程往buffer里写数据的同时显示线程正在读取同一块内存就会出现画面上下两部分不是同一帧的情况。Decoder Task的伪代码框架static void decoder_task(void *arg) { while (1) { // 等待下一帧需要解码的请求 xSemaphoreTake(s_frame_req_sem, portMAX_DELAY); // 从当前视频句柄读一帧压缩数据 int len video_file_read(s_video_ctx, s_dec_inbuf, DEC_INBUF_SIZE); if (len 0) { // 视频读完切换下一个视频 player_switch_to_next_video(); continue; } // JPEG 硬解 jpeg_decoder_process(s_jpeg_dec, s_dec_inbuf, len, s_frame_buffers[s_write_idx], JPEG_OUT_RGB565); // 通知显示线程可以送显了 xSemaphoreGive(s_frame_ready_sem); } }Display Task的核心逻辑static void display_task(void *arg) { uint8_t cur_idx 0; while (1) { // 等待一帧解码完成 xSemaphoreTake(s_frame_ready_sem, portMAX_DELAY); // 把当前帧刷到屏幕 esp_lcd_panel_draw_bitmap(s_panel, 0, 0, 720, 720, s_frame_buffers[cur_idx]); // 翻转 buffer s_write_idx (s_write_idx 1) % 2; cur_idx (cur_idx 1) % 2; // 通知解码器可以继续解下一帧 xSemaphoreGive(s_frame_req_sem); } }这里有个需要注意的点解码器硬解是异步的我调用的jpeg_decoder_process在真正解码完成前不能去读输出buffer。所以两个Semaphore实际上做了一个简单的生产者/消费者模型Display等Ready信号Decoder等Request信号保证“解一帧、显一帧”的流水线不冲突。5.3 帧同步与帧率控制怎么稳定卡在24fps光靠解码快就能到24fps吗不一定。如果解码速度比24fps快画面会像按了快进一样如果解码速度比24fps慢画面就会掉帧。想要稳定在24fps必须以屏幕的节奏为准。ST7703配置DPI video mode后屏幕本身就按照24MHz像素时钟在跑所以番茄钟其实掌握在ST7703的刷新节奏里。但MCU侧刷帧的时机如果不在VSync的固定相位还是会产生撕裂。我用的方法是在Display Task里不直接“准备好了就刷”而是注册一个VSync中断回调让刷新动作和VSync对齐。以ESP-IDF的MIPI DSI实现来看可以通过esp_lcd_dsi_frame_finished这类回调或者定时器延时来让位。如果SDK版本没有现成回调用高分辨率定时器模拟也可以关键是刷帧的周期必须严格按1/24秒来。一种比较简单粗暴的方法是用vTaskDelayUntilTickType_t last_wake xTaskGetTickCount(); const TickType_t frame_interval pdMS_TO_TICKS(1000 / 24); while (1) { // 等待解完一帧 xSemaphoreTake(s_frame_ready_sem, portMAX_DELAY); // 刷帧 esp_lcd_panel_draw_bitmap(s_panel, 0, 0, 720, 720, s_display_buf); // 严格等到下一帧时间点 vTaskDelayUntil(last_wake, frame_interval); }用vTaskDelayUntil而不是普通的vTaskDelay是因为它会把任务的唤醒时间对齐到绝对时间点不会因为上一帧处理耗时太长而累积延迟。这样才能让长时间轮播不出现“越来越慢”的问题。5.4 轮播逻辑实现多视频顺序切换轮播器里会有一个状态机记录当前正在播放的视频序号、当前视频文件句柄、当前读取位置。当解码器读文件读到EOF时就触发切换动作。我的切换逻辑大概是static void player_switch_to_next_video(void) { // 关闭当前视频 if (s_video_ctx) { video_file_close(s_video_ctx); } // 获取下一项播放列表 s_playlist_idx (s_playlist_idx 1) % s_playlist_count; playlist_item_t *item s_playlist[s_playlist_idx]; // 打开新视频 s_video_ctx video_file_open(item-path); s_video_elapsed_sec 0; printf([player] switch to %s\n, item-path); }如果你在playlist里指定了播放秒数还需要有一个Timer或者专门的检查逻辑在播放时间达到设定值后提前触发切换。这个逻辑放到Decoder Task里每次读完一帧后检查即可如果累计播放秒数大于配置就立刻切视频。帧缓冲的申请放到全局static uint8_t *s_frame_buffers[2]; // 在 app_main 里分配 s_frame_buffers[0] heap_caps_malloc(720 * 720 * 2, MALLOC_CAP_SPIRAM); s_frame_buffers[1] heap_caps_malloc(720 * 720 * 2, MALLOC_CAP_SPIRAM);PSRAM分配这几个MB完全没压力但在编码时不要忘了检查返回指针是否为空。6. 常见问题排查与性能优化实录6.1 黑屏、白屏排查速查做MIPI屏最折磨人的就是黑屏因为它的原因可以排出一长串。我遇到过的黑屏情况用排除法基本能定位现象可能原因排查方法完全无亮光背光电源没接好测LED对地电压确认5V/电流足够背光亮但屏幕全黑ST7703复位没生效检查RESET脚拉低时间确认代码里reset_gpio_num正确背光亮但屏幕显示乱码或全白DSI Lane数量配置错误检查bus_config里num_data_lanes是否与硬件一致屏幕只有半边或滚动Panel尺寸配置错误检查h_res/v_res是否和屏一致点屏幕无响应且系统重启供电不足换5V/2A电源测量上电瞬间电压跌落最诡异的一次黑屏是我忘了给ST7703模组接3.3V只接了背光5V结果屏幕亮得像小夜灯但怎么初始化都不出画面。后来才意识到数字逻辑都没供电自然没法工作。6.2 花屏、画面撕裂、闪烁问题花屏往往和RGB的数据格式配置有关。如果你把RGB888的数据写到RGB565的屏上颜色是乱的把RGB565的数据按3字节发帧全部错位。检查panel_config.bits_per_pixel和帧缓冲里像素类型是否一致。画面撕裂是单缓冲的典型症状也可能是刷帧时机没有对齐VSync。解决办法就是双缓冲同步。视频轮播器对画面稳定性要求高千万不要用单缓冲省那1MB内存双缓冲带来的稳定体验绝对值这个代价。闪烁还有可能是背光PWM频率太低。如果你用GPIO做PWM调光频率低于500Hz人眼会明显感觉到屏幕在闪。把PWM频率设到1kHz以上或者背光直接常亮只用系统来控制亮度闪烁问题基本就消失了。6.3 卡顿掉帧瓶颈到底在哪如果画面能出但帧率只有10fps或者时不时卡一下先别急着怀疑解码器。我从这个项目里总结出的排查顺序是先看SD卡读取速度。如果用SPI模式读SD卡720×720的MJPEG帧每帧压缩后也有50KB~200KBSPI模式往往只能跑到几MB/s读一帧要几十毫秒这就成了瓶颈。换成SDMMC 4-bit模式后读取速度能提升一个量级整个帧率随之上涨。再看内存拷贝。硬件解码器解出来的帧如果要从内部SRAM再拷贝到PSRAM、再从PSRAM传到DSI控制器中间多一层memcpy就会吃掉不少CPU周期。建议让解码器直接输出到PSRAM的目标buffer减少中间拷贝。最后才看解码器配置。JPEG硬解如果输出像素格式选错了比如选了RGB888但你的屏是RGB565转换过程会额外耗时。选对格式、对齐分辨率解码性能会好很多。我的实测数据是在720×720 MJPEG素材、Class 10 SD卡、SDMMC 4-bit模式下解码一帧约20ms送显一帧约5ms总耗时25ms左右刚好卡在24fps的边缘。进一步优化后比如把像素时钟和DMA配置好可以稳定跑到24fps甚至30fps。6.4 调优到24fps的3个关键配置调优时最关键的一步是搞清楚瓶颈到底在CPU搬运还是外设刷新。我最后稳定在24fps主要做了三件事第一把SD卡切换成4-bit SDMMC模式这是所有优化里收益最大的一步读取速度提升了将近5倍。第二把帧缓冲放在PSRAM里同时打开DMA传输。显示数据从PSRAM直接DMA到DSI控制器CPU几乎不参与像素搬运CPU算力留着给协议解析和轮播逻辑。第三把Display Task的优先级调到比Decoder Task高并且绑在不同的核心上。P4是双核RISC-V把解码线程跑在Core 0显示线程跑在Core 1两个流水线互不干扰帧率稳定性好很多。调优之后整个系统跑了一晚上没有掉帧屏幕的温度也就比体温高一点功耗比我预想的低很多。实操心得这类项目最容易犯的错是一开始就追求“高大上”。我建议你第一次跑通先用最简单的MJPEG方案帧率哪怕25fps都行先把链路全部打通。通了之后再去优化到24fps甚至挑战30fps。因为显示链路的坑很多如果一上来就堆H.264硬解、三缓冲、双核调度出了问题根本没法定位。关于后续扩展这个播放器框架的可玩性其实很高。你可以加一个BLE/WiFi通道在手机端推送新的播放列表也可以叠加一个摄像头输入通过MIPI-CSI做画中画或者再加入手势传感器让轮播器的画面跟着人靠近而暂停。硬件基础摆在这儿ESP32-P4给的扩展空间非常宽裕真正限制你的不是芯片而是你的想象力和Debug的耐心。
