Dynamic pipeline

[Sebastian Dröge]

On Do, 2014-06-26 at 09:58 +0200, Haakon Sporsheim wrote:
> On Thu, Jun 26, 2014 at 9:09 AM, Sebastian Dröge <sebastian at centricular.com>
> wrote:
> 
> > On Mi, 2014-06-25 at 11:14 +0200, Haakon Sporsheim wrote:
> > > Hi
> > >
> > > I'm working on a product that uses GStreamer for real time communication
> > > (read: VoIP). We started out using GStreamer 0.10 a couple of years ago,
> > > and now have ported our elements to 1.0.
> > >
> > > For GStremer 0.10 we developed a pretty large test suite for testing and
> > > stressing both stock GStreamer elements and our own to check that they
> > are
> > > 'compliant' (or at least doesn't crash, leak or does stupid things). Some
> > > of these tests used a test tool called GstHarness [1] that was presented
> > by
> > > Håvard Graff at GStreamer conference 2013 [2].
> > > This tool basically starts some threads which all prod an element or a
> > set
> > > of elements. An example would be pushing buffers in one thread, sending
> > > events in the second and changing state in the third.
> > >
> > > After porting this to GStreamer 1.0 this is somewhat harder because of
> > the
> > > requirement of GST_EVENT_START_STREAM and GST_EVENT_SEGMENT being present
> > > before data flow. Going to GST_STATE_NULL will deactivate its pads, which
> > > again will remove all sticky events.
> > > I've found that if a buffer is on its way between two elements and pads
> > in
> > > a streaming thread; the downstream element goes to GST_STATE_NULL then up
> > > again to GST_STATE_PLAYING in an application thread, it will not have any
> > > sticky events and you'll get the g_warning: "Got data flow before
> > > stream-start event".
> > >
> > > I guess this is a very unlikely scenario for a real life pipeline, but
> > I'd
> > > like to get someones view on it. Is this something that should work?
> > Should
> > > it be possible to pick out an element in a pipeline, take the element
> > down
> > > in state, then up again and expect everything to just proceed as normal
> > > after that?
> > >
> > > I'll try to get some time later this week to add a test case to
> > > prove/showcase what I'm trying to describe here without the use of
> > > GstHarness.
> >
> > A testcase would be great to have, yes :)
> >
> See the two patches I attached. Second patch (_relink) will unlink and link
> the two pads. This actually causes the test to pass, which I find a bit
> weird. I guess this is what I'm trying to point at. If you say this is as
> expected I guess I'm happy with that.

The relinking makes it work because that will cause the sticky events to
be resent before the next buffer, and won't allow any buffer to pass
while it's unlinked. But that's not really a fix :) See below

> > But the problem here seems to be that you don't block the srcpad in
> > front of the element that you remove (or deactivate). So buffers are
> > just flowing with any control. That can give you all kinds of errors.
> > Do you still have this problem if you first block the srcpad in front of
> > the element you deactivate, then deactivate the element, then activate
> > it again, then unblock the srcpad again?
> >
> Yes, blocking the srcpad would help! However, what we are trying to do here
> is testing whether or not an element is thread safe. When we have tested
> elements like this we have found many issues that might only happen once in
> a blue moon.

The errors you get are to be expected if you don't block the pads. But
you mean you still get them if you block the pads?

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140626/700fcce5/attachment.sig>