You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(video): checkpoint on encoder reconfig + real PTS-derived segment duration
Two related issues with live RTMP video.
1. "Very old video then stops"
When OBS reconfigures its encoder mid-session (resolution change,
preset swap, restart) it re-sends the AVCDecoderConfigurationRecord
with new SPS/PPS. Any bytes already in the 8 MB video ring buffer
were encoded under the *old* parameters, and the cached keyframe
offsets point into them. A listener that subscribed after the
reconfig would replay those old frames with the new SPS/PPS active
and decode blew up, then stalled.
parseAVCConfig now detects that it already had SPS/PPS (i.e. this
is a reconfig, not first init) and calls
videoStream.CheckpointAtHead(), which marks the current
Buffer.Head as a new MinListenerOffset and clears the keyframe
index (Buffer.ResetKeyframes). serveStreamData bumps any new
listener's start offset up to MinListenerOffset before seeking
to the latest keyframe, so reconfigs no longer replay stale
content. Stream.GetMinListenerOffset / new CheckpointAtHead
encapsulate the read/write under the stream mutex.
2. "Buffering at 90%, 5s cache"
The HLS ring previously recorded every segment with the
configured SegmentDuration regardless of the actual wall time of
the frames inside — a mismatch with OBS's keyframe interval made
the player wait for phantom content that was never coming.
segmentLoopFramed now derives segment duration from the span of
PTS values it actually included (pesBatchRange returns first +
last-end PTS across the audio and video batches) and pushes that
into the ring. EXTINF is now accurate and TARGETDURATION adapts
correctly via math.Ceil over the real durations.
0 commit comments