低带宽场景下FPV遥控车实时视频帧压缩传输方案咨询

核心问题 #

如何针对FPV遥控车场景，对每帧视频做极致实时压缩，在单包最大32字节、2Mbps传输速率的限制下，获得能看清路况的可用帧率，且Android端可通过Java重组数据包。

现有条件 #

• 单数据包最大32字节，存在丢包可能
• 传输链路最大速率2Mbps
• 采用C++实现视频采集、发送及处理

当前实验进展 #

• 基于树莓派3B，通过v4l2从USB摄像头获取YUV原始帧，转换为RGB格式存入C++数组，使用RF24库通过NRF24L01+模块传输
• 传输后数据经USB串口或HC-05蓝牙转发至自定义Android应用
• 曾用该模块实现HEVC格式预剪辑视频流传输，但非实时场景；本次不依赖网络/网络驱动，认为低规格实时流可行

已尝试方案及问题 #

• 压缩为8位色彩：Android端无法正确重组数据包
• 低分辨率无压缩传输：帧率极低（约数秒一帧），无法满足实时需求

针对性解决建议 #

1. 极端降分辨率+灰度化+帧间差分（优先推荐） #

• 处理流程：
  1. 直接提取YUV帧的Y分量（无需转RGB，减少计算量），转为8位灰度图
  2. 将分辨率降到极致，比如32x24甚至16x12——32x24单帧原始灰度数据为768字节，拆分后需24个32字节包；16x12仅192字节，只需6个包
  3. 采用帧间差分：只传输当前帧与上一帧的差异像素位置及值。每个差异点用3字节存储（1字节x坐标+1字节y坐标+1字节灰度值），32字节包可存10个差异点。FPV场景下帧间差异像素占比极低，能大幅减少传输量
• 丢包处理：每帧头部加1字节帧序号，Android端若发现丢包，直接用上一帧补全，不影响路况判断
• C++端简化实现示例：

  uint8_t prev_frame[16*12] = {0}; // 上一帧灰度数据
  uint8_t curr_frame[16*12];
  uint8_t packet[32];
  static uint8_t frame_seq = 0;
  
  // 步骤1：从YUV帧提取Y分量填充curr_frame（省略v4l2读取逻辑）
  // 步骤2：生成差异数据包
  int packet_idx = 0;
  packet[packet_idx++] = frame_seq; // 帧序号放头部
  
  for(int y=0; y<12; y++){
      for(int x=0; x<16; x++){
          int pixel_pos = y*16 + x;
          if(curr_frame[pixel_pos] != prev_frame[pixel_pos]){
              if(packet_idx + 3 > 32){
                  radio.write(packet, packet_idx); // 发送当前包
                  packet_idx = 1; // 重置，保留帧序号位
              }
              packet[packet_idx++] = x;
              packet[packet_idx++] = y;
              packet[packet_idx++] = curr_frame[pixel_pos];
          }
      }
  }
  // 发送最后一个剩余数据包
  if(packet_idx > 1){
      radio.write(packet, packet_idx);
  }
  frame_seq++;
  memcpy(prev_frame, curr_frame, 16*12); // 更新上一帧数据
  

• Android端重组逻辑：
  初始化固定大小的灰度图数组，收到带帧序号的包后，根据包内坐标更新对应像素；若连续未收到新帧序号，保持上一帧显示。

2. 线框/边缘检测压缩 #

• 处理流程：
  1. 对Y分量灰度帧做简化边缘检测（比如邻域像素差分，替代复杂的Sobel算子）
  2. 只保留边缘像素的坐标，每个边缘点用2字节存储（1字节x+1字节y），32字节包可存15个边缘点（加1字节帧序号）
  3. 结合帧间差分，仅传输新增或变化的边缘点
• 优势：数据量极小，仅保留路况轮廓，完全满足FPV方向判断需求；树莓派3B的计算能力足够实时处理简化版边缘检测。

3. 自定义极简游程编码（RLE） #

• 针对极低分辨率灰度图，用游程编码压缩连续相同灰度值的像素：比如某行前10个像素灰度为0，接下来8个为255，可编码为0x0A 0x00 0x08 0xFF，用4字节替代18字节原始数据
• 传输时按行拆分数据包，每行加1字节行号，Android端某行丢包则用上一帧对应行补全

关键注意事项 #

• 避免YUV转RGB：直接用Y分量处理，减少树莓派计算负载，提升实时性
• 数据包头部固定留1字节存帧序号/行号，方便Android端重组和丢包恢复
• 优先保证帧序号和核心差异/边缘数据，冗余数据可直接放弃
• 测试从最低分辨率（16x12）开始验证，逐步调整清晰度与帧率的平衡

内容的提问来源于stack exchange，提问作者LollosoSi