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

[Sebastian Dröge]

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
-------------- 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/20161001/5ec1d296/attachment.sig>