v0.3: In-memory keyframe cache for faster first-frame #17
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implemented and deployed in commits
a2e0a8c→020a180→7490edd.What landed:
core/webrtc/keyframecache.go— new bounded ring buffer (keyFrameCache). Detects H.264 IDR NAL starts in both single-NAL (type 5) and FU-A (type 28, start bit set, inner type 5) packetisation modes. Capped at 512 packets / 2 MiB per source.core/webrtc/source.go— addedcache *keyFrameCachefield andEnableKeyFrameCache()method.readLoop()callscache.push(pkt)after each unmarshal (before the subscriber fanout).Subscribe()snapshots the burst outsides.mu(avoids any cross-lock ordering with push) and pre-fills the new channel with the IDR burst before registering it live — using a labeledbreak prefillto stop gracefully if the channel is full.app/webrtc/lifecycle.go—allocAdjacentPair()callsvideoSrc.EnableKeyFrameCache()immediately after binding the video UDP source. Audio sources are intentionally left uncached.Result: new WHEP subscribers receive the last H.264 keyframe burst immediately on join rather than waiting up to one full IDR interval (~2 s at GOP=60/30 fps). Verified binary contains all 8 cache symbols. Container restarted and running.