[Bug 788340] Dynamically reconfigure pipeline in PLAY based on transports

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788340

--- Comment #6 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Patricia Muscalu from comment #3)
> > Why are you adding the receiver/sender parts after PLAY and not during
> > SETUP? SETUP is basically when the client tells the server to set up these
> > pieces.
> > In PLAY/RECORD you would only finish the setup and consider the session
> > complete
> > 
> 
> We presented/suggested this solution in our earlier mail conversation with
> you.
> We do not need any pipeline in SETUP anyway. Let us know if you want us to
> change this approach and complete the pipeline in SETUP.

I think it's fine but it needs some explanation IMHO. Basically, it makes no
sense to set up all the elements before PLAY/RECORD because until that point
everything can still change anyway.

> > @@ +611,3 @@
> >    priv = media->priv;
> >  
> > +  data.position = G_MAXINT64;
> > 
> > Why this change? Generally, -1 is returned (GST_CLOCK_TIME_NONE) if nothing
> > else can be found
> 
> GST_CLOCK_TIME_NONE is not a proper initial value because we are actually
> using MIN function now.

G_MAXINT64 is not ideal either though, for position queries in TIME format
values above that are valid too). I'm not sure what to suggest here though, the
position/duration query API is broken by the usage of int64 but actually using
uint64 for TIME format.

Maybe take the code as it is in gstbin.c or gstelement.c for the generic query
handling.

(In reply to Patricia Muscalu from comment #5)
> > @@ +1381,3 @@
> > +      g_clear_object (&inetaddr);
> > +      if (multicast)
> > +        inetaddr = g_inet_address_new_any (family);
> > 
> > The problem with allocating ports ourselves is that the IP_MULTICAST_ALL and
> > control message stuff from udpsrc won't work properly, or is it still doing
> > that here?
> 
> It's done in a similar way as the case where no address pool is provided
> (lines
> 1282-1284 on master). What's the proper solution?

I'm not sure and it was broken like that before already. But maybe you can add
a FIXME comment there.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.