[gst-devel] latency changes - New release

Christian Fredrik Kalager Schaller uraeus at linuxrising.org
Wed May 23 15:11:39 CEST 2007

Thought I should follow-up on this one. Since all the nice RTSP stuff
would end up being disabled if the latency stuff is disabled in the next
release I say we should not disable it in the upcomming release. People
have had 2 full Months now to adjust their applications since Wim send
out the email below to this corrected behavior which should be

Already discussed it with Wim and Jan, so unless someone objects heavily
to the latency changes being enabled they will be so in this upcoming


On Wed, 2007-03-21 at 13:42 +0100, Wim Taymans wrote:
> Hello hackers,
> The patch attached to bug
> http://bugzilla.gnome.org/show_bug.cgi?id=340842 regarding latency
> calculations in GStreamer has been commited recently. This patch changes
> the way state changes happen in the case of live pipelines according to
> the document that can be found here:
> http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/design/draft-latency.txt?revision=1.6&view=markup
> This patch makes it so that all sinks in a live pipeline need to be
> prerolled (receive data) before they are set to the playing statei. This
> is needed in order to query and compensate for the total pipeline
> latency. 
> This behaviour is different from previous released versions and might
> cause regressions in applications that use pipelines that previously
> used to work. Some examples:
>  alsasrc ! tee name=t ! fakesink t. ! fakesink
> This example previously worked because in the live pipeline, both sinks
> were (incorrectly?) forced to the PLAYING state, not waiting for them to
> preroll. This example requires you do disable synchronisation as well
> with older GStreamer cores.
> In the new core this pipeline is not able to preroll completely because
> the first fakesink will block on the first buffer it receives, blocking
> tee so that it cannot push another buffer to fakesink. The effect is
> that this pipeline will not be able to go to PLAYING. This situation is
> with the new changes no different from a case where the source is not a
> live source, btw. 
> To correct this problem, queues must be inserted after the forking
> element (tee), like:
>  alsasrc ! tee name=t ! queue ! fakesink t. ! queue ! fakesink
> The rule to insert queues after all splitting elements like tee and
> demuxers now also holds for live pipelines.
> It is unclear how many apps rely on the old behaviour but we know of
> at least one application that fails to work with the new changes
> (dealing with dv capture). So, we would like to introduce a transition
> period for people to test and correct their apps. 
> In order to make this transition period easier for everybody we have
> implemented the following backward compatibility into GStreamer core:
>  - CVS versions have the latency calculations enabled. The old 
>    behaviour can be activated by setting the GST_COMPAT environment
>    variable to a string containing no-live-preroll.
>  - next pre-release and release versions will have the latency disabled
>    and will print a warning when dealing with live pipelines,
>    encouraging the developer to verify if the application functions
>    properly with latency enabled. The new behaviour can be activated by
>    setting the GST_COMPAT environment variable to a string containing
>    live-preroll.
>  - release + 2 will enable the latency calculations by default, leaving
>    the option to disable it with GST_COMPAT=no-live-preroll.
>  - release + N (likely N==3) will not have the option to disable the
>    latency anymore. We expect apps to be fixed and depend on that new
>    release.
> Happy hacking!
> Wim
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

More information about the gstreamer-devel mailing list