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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Thu Oct 19 14:06:11 UTC 2017


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

--- Comment #12 from Patricia Muscalu <patricia at axis.com> ---

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

Ok, so I guess that the query position patch is correct, or?

> 
> (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?

This is the correct behavior, so this means that we have a bug on master.

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