Frames write() returned false for: for video, rejected by libwebrtc's
adapter; for audio, they did not fit in the bounded publish queue.
Frames accepted.
OptionallastTimestamp of the most recently accepted frame, in microseconds.
Queue bound. Always 0 for video. For audio, the bound in 10 ms chunks.
Current buffered frames. Always 0 for video.
Frames accepted whose timestamp did not advance past the previous one.
Counted, not rejected: a producer may legitimately restart (looping a file), and silently reordering or discarding would hide a real problem. A rising count on a live source means the timestamps being supplied are wrong, which will show up downstream as jitter.
Publish-side statistics for one local track.
Video publish is synchronous -
write()hands the frame straight to the encoder - so there is no SDK-side send queue andsendQueueDepth/maxQueueare0; aframesDroppedthere means libwebrtc's adapter rejected the frame. Audio publish does have a bounded queue, drained at 10 ms, so its depth and bound are real.For audio,
framesWritten,framesDropped,lastTimestampandtimestampRegressionscount this track's ownwrite()calls, whilesendQueueDepthandmaxQueuedescribe the audio device shared by every local audio track in the process. With one local audio track - the normal case - the distinction does not arise.