Dynamic pipeline

[Sebastian Dröge]

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 :)

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?

-- 
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/3b887bb7/attachment.sig>