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

[Matt Staples]

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?

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160928/2fe63f30/attachment.html>