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

[Martin Soto]

On Tue, 2004-11-23 at 15:19 +0100, Benjamin Otte wrote:
...
> But it sounds like a good idea to use a timeout and fail. Maybe use the
> timeout to check if the queue is still working (that means emptying) and
> only fail if it's not?

I can see perfectly normal cases where the queue doesn't empty
instantly. The queue I'm using to transfer subtitles from the demuxer to
the subtitle decoder could show that behavior in quite normal operating
conditions. That wouldn't affect the behavior of the application in a
negative way though.

> Have you thought about the case when both sides try to renegotiate the
> format? Or upstream renegotiations at all?

Yes, and decided not to tackle it. The problem is that if renegotiation
comes from downstream, and there is material in the queue, I cannot push
it back.

> And you probably have run our testsuites

I would if I knew how.

>  as well as totem and rb, right?

(Arch) Rb plays my music, and (CVS) Totem plays my videos. Both of them
seek happily back and forth and keep playing no matter how much I abuse
them. Is there anything else I should test?

> release_locks in state changes works correctly?

I don't know what exactly you mean with this.

> We'll get bug reports when the deadlocks happen...

Hehehe. Look at the patch: programs that even exercise the new code
would have miserably failed before. I conclude from that, that a program
that even worked before would never deadlock now. I may be wrong, of
course. If that's the case, I'll look into it.

M. S.