[gst-devel] State reordering issues

[Erik Walthinsen]

It's generally been decided that we're going to switch from the states
being in their current ordering:

NULL <-> READY <-> PLAYING <-> PAUSED

to a slightly more sane one:

NULL <-> READY <-> PAUSED <-> PLAYING

This mostly impacts the actual state change code, and the thread
interlocking, but it does affect a few plugins:

1394/dv1394src.c
arts/gst_arts.c
xmms/gstxmmsinput.c
filters/ladspa/gstladspa.c

Anyone making use of the old ordering explicitely should be prepared to
switch, and for the following macros go to away:

GST_STATE_READY_TO_PLAYING
GST_STATE_PLAYING_TO_READY
GST_STATE_PLAYING_TO_PAUSED
GST_STATE_PAUSED_TO_PLAYING

in favor of the new ones:

GST_STATE_READY_TO_PAUSED
GST_STATE_PAUSED_TO_READY
GST_STATE_PAUSED_TO_PLAYING
GST_STATE_PLAYING_TO_PAUSED

Note that the semantics of the paused state are very simple, which is why
most elements completely ignore it.  It simply means that plugin code
won't be called at all, because it's the scheduler's responsibility to
make this happen at the right time.

This is noticably different from DirectShow's concept of PAUSED, which is
no different from PLAYING except for sink elements, which are expected to
be stopped.  The correct name for this (come on, M$, say it with me now)
is "pre-roll".  Pre-roll is better accomplished in the GStreamer case by
simply explicitly PLAYING everything but the sink elements, mangling their
clock a little, and playing them after the queues have filled up to a
decent level (which will be possible shortly with an improved queue that
efficiently implements high- and low-watermark signals).

If you have any questions about the impact of this change on your own
project, either post them here or jump in IRC.

TTYL,
    Omega

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_