[Bug 707605] Need "reverse-funnel" element

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sat Jan 18 07:09:40 PST 2014


https://bugzilla.gnome.org/show_bug.cgi?id=707605
  GStreamer | gstreamer (core) | git

--- Comment #68 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-01-18 15:09:29 UTC ---
Some further comments below...

but most importantly this needs a decision if something like this should go
into core, or better first into bad? Or if we want a different kind of element
that can demux based on other aspects too?

For myself this would be fine for core... once it has more tests for more use
cases (see below).

(In reply to comment #67)

> @@ +169,3 @@
> +
> +  return TRUE;
> +}
> 
> It might be worth a note that this only works because they are forwarded right
> after a new stream-id is received, so that prevents it from sending mixed
> stream-ids.
> 
> Also, can this handle different streams with different caps/segments?

I think this should get a unit test, yes.

> @@ +284,3 @@
> +      g_object_notify (G_OBJECT (demux), "active-pad");
> +    }
> +  }
> 
> The locking in this block looks confusing to me, it works because this is
> inside the event handler, so only one event handler can run at a time (for the
> same pad).
> 
> I'd prefer having the lock before the get_srcpad_by_stream_id (and make this
> function assume it should be called with the lock already) and then unlock
> inside the if/else branches.
> 
> For the if, you likely will have to split the srcpad_create into 2 parts. The
> first part would just create the GstPad and can be run with the lock taken. The
> second one activates and adds the pad and should be run without the lock.
> 
> On the else branch, it should be the same.
> 
> Not sure if you agree with this, but it seems to make a more consistent
> locking.

Most importantly no lock must be taken while calling g_object_notify() :) Good
catch.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list