-
-
Notifications
You must be signed in to change notification settings - Fork 264
Description
📌 Title
ChatGPT-summarized: WebRTC H.264 stream — RTP packets received, DTLS/SRTP OK, but Chrome framesDecoded=0
📌 Summary (Prepared by ChatGPT)
I am sharing the following issue with the help of ChatGPT, which summarized my board logs and browser logs into a clean, structured report for easier analysis.
📌 Problem Overview
I am streaming H.264 video from an embedded Linux board (Eyenix EN675) to Chrome (WebRTC) using a custom libpeer-based implementation.
The WebRTC connection itself is fully successful:
ICE connected
DTLS-SRTP handshake completed
SRTP sessions created
RTP packets arriving continuously on Chrome
However:
Chrome’s framesDecoded never increases (always 0), so video never appears.
This occurs even though RTP packets and bytes increase normally.
📌 Environment
Device: Eyenix EN675 (Linux)
WebRTC stack: libpeer (custom WebRTC implementation)
Codec: H.264 (packetization-mode=1)
Signaling: MQTT → WebSocket → Browser
Direction: Board → Browser (sendonly → recvonly)
Browser: Chrome latest
📌 What Works (Confirmed Good)
✔️ 1. ICE / STUN / DTLS-SRTP handshake
Board log shows:
state: connected → completed
mbedtls_ssl_handshake (ret=0)
Created inbound SRTP session
Created outbound SRTP session
DataChannel sid=1 opened
Browser:
ICE connected
connectionState=connected
ontrack(video)
✔️ 2. Chrome is definitely receiving RTP packets
Browser stats:
[RTP-V] ssrc=1 packets=29 bytes=9148 framesDecoded=0
[RTP-V] ssrc=1 packets=36 bytes=13380 framesDecoded=0
Packets/bytes increase, framesDecoded stays at 0.
✔️ 3. Board is transmitting SPS / PPS / IDR NALUs
Example:
[HEX][SPS_raw] len=29
00 00 00 01 67 42 C0 16 ...
[HEX][PPS_raw] len=8
00 00 00 01 68 CE 0F C8
[FRAME_IDR_raw] len=2035
00 00 00 01 67 ...
00 00 00 01 68 ...
00 00 01 65 ...
RTP:
SPS → nal_type=7 (OK)
PPS → nal_type=8 (OK)
FU-A fragments for IDR:
7C 85 ... (Start fragment)
...
(End fragment not visible in log)
Second IDR is single-NAL:
size=1010 nal_type=5 markbit=1
So SPS/PPS/IDR appear valid.
Critical Symptom
❗ Chrome continuously sends RTCP PLI/FIR
Board log:
RTCP_PSFB 15
RTCP_PSFB 15
RTCP_PSFB 15
But the board does NOT send a new IDR in response.
Because of this:
Chrome never accepts the initial keyframe
Without a valid keyframe, decoder never starts
→ framesDecoded = 0 forever
This matches classic WebRTC “keyframe missing or invalid” behavior.