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.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Matt Staples]

On Fri, Sep 30, 2016 at 1:21 AM, Sebastian Dröge
<[hidden email]> 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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Fri, 2016-09-30 at 12:06 -0600, Matt Staples wrote:

>
> > 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?

Yes, either that or rtspsrc has to get a new thread for being able to
perform operations while downstream is blocked. Which might be a good
idea in the long run anyway, together with completely refactoring
GstRTSPConnection.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel