[gst-devel] Re: [gst-cvs] soto gstreamer: gstreamer/ gstreamer/gst/

[Martin Soto]

On Tue, 2004-11-23 at 02:03, Jan Schmidt wrote:
> <quote who="Martin Soto">
> > Log message:
> > 2004-11-23  Martin Soto  <martinsoto at users.sourceforge.net>
> > 	* gst/gstqueue.c (gst_queue_init, gst_queue_link_sink)
> > 	(gst_queue_link_src): Allow for renegotiating the caps of the sink
> > 	pad. The queue will now wait until it is empty and forward the new
> > 	caps to the source.
> 
> Can one of the other core guys comment on this? 

Just for the record: I asked for comments on this patch two weeks ago:
http://sourceforge.net/mailarchive/forum.php?thread_id=5922077&forum_id=5947

Of course, I'd still appreciate the (hard)core guys to look into this
issue if they haven't already.

> It's a pretty big change to the behaviour of queue - 

No that much. Before, capsnego just failed if an attempt was done to
renegotiate at a time where material was present in the queue. I don't
think any existing application was relying on the queue failing in this
particular case, because this behavior is just not very useful. Please
correct me if I'm wrong, though.

> and this patch doesn't
> have any timeout system or anything. What if the queue never drains because
> the far side isn't pulling? In that case, perhaps the queue should just time
> out and return FAILED.

If the other end isn't pulling, the queue blocks. Is the same thing that
happens when the queue is full and you try to write. Anyway, if people
consider that a timeout would be necessary, I can work on it. The
question is rather how this timeout would be defined, because the normal
queue timeout would be too short, so we'd need an additional option for
it. Or maybe we make the whole behavior optional, but I still think the
original behavior is not that useful, so why making the queue (even)
more complex to support it?

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>
Universität Kaiserslautern