[gst-devel] latency changes

[Wim Taymans]

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