树莓派WebRTC H264视频流加载失败调试求助

我看你现在在树莓派上用Rust结合WebRTC做H264视频流推送到本地网页，ICE连接状态显示完成，但浏览器里的视频就是一直加载不出来，Rust这边没报错还能收到UDP数据，这种卡壳的情况确实让人头疼。我帮你梳理几个大概率的排查方向，你可以一步步试：

一、先确认H264编码参数完全匹配 #

WebRTC对H264的参数一致性要求很高，你代码里设置的sdp_fmtp_line: "packetization-mode=1;profile-level-id=42e01f"必须和树莓派摄像头输出的H264流参数完全对应：

• 检查树莓派摄像头的输出配置：比如用raspivid的话，要指定--profile high（对应42e01f的profile）和--inline（开启packetization-mode=1的分片模式），避免输出整帧NALU（packetization-mode=0）。
• 可以用工具抓摄像头输出的RTP包，解析NALU头的profile-level-id，确认和你代码里的设置一致。如果树莓派默认输出的是42001f（Baseline profile），那你代码里的sdp_fmtp_line也要改成对应的参数。

二、检查RTP包的关键头部字段是否正常 #

你现在是直接把UDP收到的字节写入TrackLocalStaticRTP，但WebRTC的媒体流依赖正确的RTP头部信息：

• 给Rust代码加个RTP包解析的打印，看看序列号（sequence number）和时间戳（timestamp）是不是正常递增的：

  // 在start_writing_track的循环里，收到包后添加：
  use webrtc::rtp::packet::Packet;
  let mut rtp_packet = Packet::default();
  if let Ok(_) = rtp_packet.unmarshal(&inbound_rtp_packet[..n]) {
      println!("RTP包: seq={}, timestamp={}", rtp_packet.header.sequence_number, rtp_packet.header.timestamp);
  }
  

  如果序列号乱跳、时间戳不按90kHz时钟递增（H264的clock_rate是90000，30帧的话每帧时间戳间隔≈3000），浏览器就无法正常解码。

三、确认WebRTC媒体连接的实际状态与流连通性 #

虽然ICE gathering完成了，但要进一步确认媒体流的传输是否真的通了：

• 在Rust的handle_offer里添加状态监听，确保PeerConnection真的进入了Connected状态，再启动摄像头流（你现在是在gather完成后启动，可能时机太早）：

  peer_conn.on_peer_connection_state_change(Box::new(|state: RTCPeerConnectionState| {
      println!("Peer连接状态: {:?}", state);
      if state == RTCPeerConnectionState::Connected {
          println!("媒体连接建立，启动摄像头流");
          camera::start_stream_rtp(); // 把启动流的逻辑移到这里
      }
      Box::pin(async {})
  })).await?;
  
  peer_conn.on_ice_connection_state_change(Box::new(|state: RTCIceConnectionState| {
      println!("ICE连接状态: {:?}", state);
      Box::pin(async {})
  })).await?;
  

• 检查RTCP接收：你代码里有rtp_sender的read循环，可以加个打印，看看有没有收到浏览器发的RTCP包，如果一直没收到，可能媒体流的方向有问题。

四、排查网页端WebRTC的处理是否完整 #

你的网页代码看起来没写完，要确保以下几点：

• 正确监听ontrack事件，把收到的流绑定到video元素，还要满足浏览器自动播放的限制（加muted playsinline）：

  async function start() {
    let pc = new RTCPeerConnection({
      iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
    });
  
    // 监听远端媒体流
    pc.ontrack = (event) => {
      if (event.streams.length > 0) {
        let video = document.createElement('video');
        video.srcObject = event.streams[0];
        video.autoplay = true;
        video.playsInline = true;
        video.muted = true; // 现代浏览器要求静音才能自动播放
        document.getElementById('remoteVideos').appendChild(video);
      }
    };
  
    // 发送Offer到后端
    let offer = await pc.createOffer();
    await pc.setLocalDescription(offer);
    
    let response = await fetch('/offer', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(pc.localDescription)
    });
    
    let answer = await response.json();
    await pc.setRemoteDescription(answer);
  
    // 打印连接状态
    pc.oniceconnectionstatechange = () => {
      log(`ICE状态: ${pc.iceConnectionState}`);
    };
    pc.onconnectionstatechange = () => {
      log(`Peer状态: ${pc.connectionState}`);
    };
  }
  
  window.onload = start;
  

• 如果网页端没正确处理ontrack，即使收到流也不会显示视频。

五、启用详细日志定位问题 #

这两个工具能帮你快速找到根因：

• Rust侧：启动程序时设置日志级别，打印WebRTC的详细日志：

  RUST_LOG=webrtc=trace ./your-rust-app
  

  可以看到codec协商、RTP包接收、解码等细节，有没有隐藏的错误。
• 浏览器侧：打开chrome://webrtc-internals/，这个页面能看到WebRTC的所有统计数据：
  • 看inbound-rtp的packetsReceived：如果是0，说明媒体流没传过来；
  • 看framesDecoded：如果packetsReceived有值但framesDecoded是0，说明H264参数不匹配导致解码失败；
  • 丢包率、延迟等数据也能帮你定位问题。

六、检查NALU起始码问题 #

树莓派有些摄像头输出的H264 RTP包里会带NALU起始码（00 00 00 01），但WebRTC的RTP流不需要这个起始码（RTP头已经做了分片标识）。如果有起始码，浏览器解码会出错，可以在Rust里写track前去掉起始码：

// 检查是否有起始码，有的话截断
let nalu_data = if inbound_rtp_packet.starts_with(&[0,0,0,1]) {
    &inbound_rtp_packet[4..n]
} else if inbound_rtp_packet.starts_with(&[0,0,1]) {
    &inbound_rtp_packet[3..n]
} else {
    &inbound_rtp_packet[..n]
};
// 用nalu_data写入track
if let Err(err) = video_track.write(nalu_data).await {
    // 错误处理
}

你可以先从浏览器的chrome://webrtc-internals/入手，看看统计数据，再结合Rust的日志，应该能很快找到问题所在。

内容来源于stack exchange