Dynamic pipeline

[Haakon Sporsheim]

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.


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


>
> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140626/77fdb972/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: identity_stress.patch
Type: text/x-patch
Size: 5262 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140626/77fdb972/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: identity_stress_relink.patch
Type: text/x-patch
Size: 923 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140626/77fdb972/attachment-0003.bin>