<div dir="ltr">Hi,<div><br></div><div>I'm working on a client application for playback from ONVIF Profile-G storage servers.  </div><div>One of the issues I've run into (and that I haven't seen discussed in any ONVIF-related archive searches) is related to ONVIF's "Rate-Control: no" option where the server can send over TCP as fast as it's able, expecting the client to do flow-control on their end.  (That feature is used mainly for downloading entire recordings, but there are other interesting use-cases.)</div><div><br></div><div>I've been using the rtspsrc element for this, but it's use of rtpjitterbuffer presents a problem in this scenario. As near as I can tell, jitterbuffer doesn't have a mode that will block input when it fills up (or reaches some target fullness level).  Rather, it accepts all input and simply overflows if the downstream side doesn't pop data as fast as the upstream side pushes it.</div><div><br></div><div>Is that correct,or am I misunderstanding how the existing modes work?</div><div><br></div><div>If that's correct, any thoughts on the best way to tackle that problem?</div><div>Maybe a new buffering mode that blocks on input?  </div><div>Or maybe somehow bypass the jitterbuffer altogether, since TCP already ensures reliable packet delivery, and ONVIF RTP headers contain the necessary (de-jittered) timestamp information?<br></div><div><br></div><div>Thanks in advance.</div><div><br></div></div>