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

[Sebastian Dröge]

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.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160930/56b51306/attachment.sig>