rtpjitterbuffer problems with tcp client-side flow-control (ONVIF)

[Matt Staples]

On Fri, Sep 30, 2016 at 1:21 AM, Sebastian Dröge
<sebastian at centricular.com> wrote:
>
> On Wed, 2016-09-28 at 18:14 -0600, Matt Staples wrote:
> > Hi,
> >
> > I'm working on a client application for playback from ONVIF Profile-G
> > storage servers.
> > 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.)
> >
> > 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.
> >
> > Is that correct,or am I misunderstanding how the existing modes work?
> >
> > If that's correct, any thoughts on the best way to tackle that
> > problem?
> > Maybe a new buffering mode that blocks on input?
> > 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?
>
> That's all correct, and it seems like rtpjitterbuffer needs a new mode
> for this that a) blocks and b) does not do any calculations based on
> receive times.
>

Thanks for confirming my thinking about this.
One danger I can see with blocking in rtpjitterbuffer itself though,
is that might make it difficult for rtspsrc's loop_interleaved to send
rtsp keep-alive messages when it needs to.
I wonder if it would be better for rtpjitterbuffer to emit signals
(a-la the queue element) when its level crosses the high_mark
threshold. rtspsrc could then do its own blocking in response to those
signals, but rtspsrc's blocking wait-loop would be able to send
keep-alive messages while otherwise blocked.   Does that make sense?

Thanks,
-Matt