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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #11 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Patricia Muscalu from comment #7)
> (In reply to Sebastian Dröge (slomo) from comment #2)
>  > @@ +2181,3 @@
> > +
> > +      if (gst_rtsp_stream_is_complete (stream)) {
> > +        complete = TRUE;
> > 
> > Shouldn't it only be considered complete once *all* streams are complete?
> 
> But what if not all media streams are active (<=> media contains two streams
> but only one is requested). The missing part here is, to make sure that all
> active streams are complete before performing a seek on media pipeline. Do
> you agree?

You know from the SETUPs that happened before PLAY/RECORD which streams are
requested, and all those need to be complete. Or not?

(In reply to Patricia Muscalu from comment #9)
> (In reply to Patricia Muscalu from comment #7)
> > (In reply to Sebastian Dröge (slomo) from comment #2)
> >  > @@ +2181,3 @@
> > > +
> > > +      if (gst_rtsp_stream_is_complete (stream)) {
> > > +        complete = TRUE;
> > > 
> > > Shouldn't it only be considered complete once *all* streams are complete?
> > 
> > But what if not all media streams are active (<=> media contains two streams
> > but only one is requested). The missing part here is, to make sure that all
> > active streams are complete before performing a seek on media pipeline. Do
> > you agree?
> 
> The problem here is to find a mapping between active transports (session
> media has this information) and active streams.

Can we expose that information easily?


(In reply to Patricia Muscalu from comment #8)
> (In reply to Sebastian Dröge (slomo) from comment #6)
> > > > @@ +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.
> 
> The initial value of data.position is set to G_MAXINT64 and if the query
> position fails (<=> data.ret == FALSE), the position is set to
> GST_CLOCK_TIME_NONE.

Ok :)


(In reply to Patricia Muscalu from comment #10)
> (In reply to Sebastian Dröge (slomo) from comment #2)
> > @@ +2678,3 @@
> > +    g_object_set (priv->appsink[0], "async", FALSE, "sync", FALSE, NULL);
> > +  if (priv->appsink[1])
> > +    g_object_set (priv->appsink[1], "async", FALSE, "sync", FALSE, NULL);
> > 
> > Why don't we do this right after creation of the sinks?
> > Why for both indizes?
> 
> In the current implementation on master:
> * in case of udp && tcp: both indices are used
> * in case of tcp: the async and sync flags are set to false only for rtcp
> appsink.

The RTCP sinks are always sync=async=false, the RTP sinks are always
sync=async=true or not?

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