Subject: Stream State Machine

From: Guido Franceschini <[email-masked]>
Date: Mon, 10 Mar 1997 11:07:19 +0100

All,

I just realized that last week I erroneously sent an e-mail to Henning only,
instead of the whole list. I therefore re-post it with some additional
reference to recent discussions. It is about the already standardized
solution for a Stream State Machine (from DSMCC).
Note that the DSMCC solution also takes into account issues that have been
neglected so far in RTSP: hw video-pumps (controlled by the State Machine
but asynchrous with respect to the State Machine itself) are not considered
in RTSP, and race conditions not yet addressed.

Guido Franceschini

------

Dear Henning and others,

I have seen in recent e-mail messages on this mailing list a lot of
discussion about the semantic of commands for the stream control in the RTSP
protocol draft. This reminds me the same steps I and others covered 1-2
years ago during the specification of a particular section of the DSMCC-UU
protocol (part 6 of the MPEG2 ISO/IEC standard), that is the section
concerning the Stream Interface and the related Stream State Machine. This
triggers a number of questions:
1) Are you aware of the existence of such DSMCC-UU Stream Interface and its
related Stream State Machine?
2) Are you aware that a considerable number of companies are already
implementing pieces of the DSMCC specifications, including the DSMCC-UU
Stream Interface and its related Stream State Machine? [I would encourage
you to look at
http://drogo.cselt.stet.it/mpeg/faq_dsm-cc.htm#What_companies, and in
general to the entire dsmcc faq at
http://drogo.cselt.stet.it/mpeg/faq_dsm-cc.htm]
NOTE: the FAQ is still being reviewed, particularly on references external
to the DSMCC itself.
3) If you are not aware of that, let me remind you that DAVIC adopts DSMCC,
and that DAVIC is now (at last) getting more and more interested in Internet
integration.

All the above means to me that the definition of two different protocols for
doing a quite simple thing (the control of a stream delivery) is a non-sense.
While it may be argued that RTSP is a lighter protocol than DSMCC-UU, as it
is message based instead of relying on RPCs, at least the semantic of the
messages in both protocols should be maintained, to avoid the totally
unuseful definition of two different state machines. This would at least
allow implementors to develop a single Stream State Machine and to use it
for both RTSP and DSMCC-UU.

Maybe the advantages of sharing such a Stream State Machine are not that
relevant, however I believe that at least there are no disadvantages! And
adopting the semantic of the DSMCC-UU Stream Interface would avoid any
further loss of energy in the definition of a powerful enough stream control
mechanism in RTSP!

Just to give the basic hints on the DSMCC-UU Stream Interface, here are the
commands specified:

	void resume (in AppNPT rStart, in Scale rScale)
	void pause (in AppNPT rStop) 
	void jump (in AppNPT rStart, in AppNPT rStop, in Scale rScale)
	void play (in AppNPT rStart, in AppNPT rStop, in Scale rScale)
	void status (in Stat rAppStatus, out Stat rActStatus)
	void reset ()

where the types are:

        typedef u_long Mode;
        struct AppNPT {s_long aSeconds; u_long aMicroSeconds;};
        struct Scale {s_short aNumerator; u_short aDenominator;};
	struct Stat {AppNPT rPosition; Scale rScale; Mode aMode;};
	
and the modes defined are:

	const Mode OPEN_M = 0;			
	const Mode PAUSE_M = 1;			
  	const Mode TRANSPORT_M = 2; 		
	const Mode TRANSPORT_PAUSE_M = 3; 	
	const Mode SEARCH_TRANSPORT_M = 4; 	
	const Mode SEARCH_TRANSPORT_PAUSE_M = 5; 
	const Mode PAUSE_SEARCH_TRANSPORT_M = 6; 
	const Mode END_OF_STREAM_M = 7; 		
	const Mode PRE_SEARCH_TRANSPORT_M = 8;
	const Mode PRE_SEARCH_TRANSPORT_PAUSE_M = 9;

The Scale parameter allows for fast forwarding, reverse, slow motion ...
Resume resumes the stream starting from rStart, with scale rScale;
Pause pauses the stream when it reaches rStop;
Play plays the stream from rStart to rStop, at scale rScale;
Jump allows to seamless jump between different segments of the stream,
jumping at rStart when rStop is reached, playing then with scale rScale.
The rStart and rStop parameters also have the notion of NOW, which is coded
as 0x80000000 aSeconds.

A few more words on the Stream State Machine philosophy:

As you can see, the Stream State Machine is NOT just a 2 or 3 state machine,
but involves 10 states! At a first glance this may seem too complex. 
However, the RTSP State Machine will grow this way too, if hw video-pumps
(controlled by the State Machine but asynchrous with respect to the State
Machine itself) are being introduced in the picture, and race conditions
fully addressed.
Nevertheless, once we accept that a server is statefull, it does not care
that much how many states are defined: what really cares instead, is that
the State Machine is not broken!

But let me try to explain how we arrived at defining such many states in
DSMCC: the whole design of this State Machine allows for storing up to 1
Stop and up to one Start position, and associates the presence of such
stored Start and/or Stop with the State definition. That is, the conceptual
"sending" state translates to:

- TRANSPORT if no Start or Stop are stored
- TRANSPORT_PAUSE if a Stop is stored
- PAUSE_SEARCH_TRANSPORT_PAUSE if both a Stop and a Start are stored

Moreover, the granularity of the State Machine has been fully explicitated
in order to allow a precise description of it and consider the possible race
conditions. The model takes into account the fact that the stream-pump may
actually be run asynchronously with respect to the Stream State Machine
itself (that is, different intelligent units might take care of the Stream
State Machine and of the actual delivery of the bits). This leads to the
definition of a number of additional states, which actually could not even
exist on simpler, full-software server implementations. Namely:

- SEARCH_TRANSPORT is the state between the instant a Start is considered by
the State Machine and the instant in which the transmission begins (and no
Stop is stored): it almost instantaneously transitions to TRANSPORT
- SEARCH_TRANSPORT_PAUSE is like the previous one, but is a different state
in order to take into account that a Stop is stored: it almost
instantaneously transitions to TRANSPORT_PAUSE
- PRE_SEARCH_TRANSPORT is the state between the instant a new Start is
received by the State Machine (that is: a Play or Resume command is
received) while already in TRANSPORT or TRANSPORT_PAUSE, and the instant the
current transmission stops (e.g: to complete a video frame): it almost
instantaneously transitions to SEARCH_TRANSPORT and then TRANSPORT
- PRE_SEARCH_TRANSPORT_PAUSE is like the previous one, but is a different
state in order to take into account that a Stop is stored: it almost
instantaneously transitions to SEARCH_TRANSPORT_PAUSE and then TRANSPORT_PAUSE

To complete this description, let me show how the lists of commands
suggested by Henning would work in DSMCC:

>All commands are issued in short succession:
>
>PLAY 10-15
>PLAY 17-19
>
>means that the server should play NPT 10 through 15, immediately
>followed by 10 through 19. (Rather than interrupting the playing of
>10-15 and jumping to 17-19 as soon as it gets the second PLAY).
>
DSMCC: OPEN ==>
       <PLAY 10-15> ==>
       SEARCH_TRANSPORT_PAUSE (Start=10, Stop=15) ==>
       TRANSPORT_PAUSE (Stop=15) ==>
       <PLAY 17-19> ==>
       PRE_SEARCH_TRANSPORT_PAUSE(Stop immediately, then Start=17, Stop=19) ==>
       SEARCH_TRANSPORT_PAUSE(Start=17, Stop=19) ==>
       TRANSPORT_PAUSE(Stop=19) ==>
       <timeline reaches 19> ==>
       PAUSE()
Actually means that the second PLAY cancels the previous one.

>PLAY 10-15
>PLAY 17-19
>PAUSE
>
>would interrupt the server whenever it gets the PAUSE, in either the
>first or second segment.
>
DSMCC: OPEN ==>
       <PLAY 10-15> ==>
       SEARCH_TRANSPORT_PAUSE (Start=10, Stop=15) ==>
       TRANSPORT_PAUSE (Stop=15) ==>
       <PLAY 17-19> ==>
       PRE_SEARCH_TRANSPORT_PAUSE(Stop immediately, then Start=17, Stop=19) ==>
       SEARCH_TRANSPORT_PAUSE(Start=17, Stop=19) ==>
       TRANSPORT_PAUSE(Stop=19) ==>
       <PAUSE> ==>
       PAUSE()
Actually means that the second PLAY cancels the previous one, and that the
PAUSE pauses the delivery at the time it is received. (It is PAUSE NOW, in
DSMCC terminology). All previous Start/Stop are forgotten!

>PLAY 10-15
>PLAY 17-19
>PAUSE 16
>
>would pause the stream after playing 10-15, position NPT to 16 and not
>play 17-19 at all.
>
DSMCC: OPEN ==>
       <PLAY 10-15> ==>
       SEARCH_TRANSPORT_PAUSE (Start=10, Stop=15) ==>
       TRANSPORT_PAUSE (Stop=15) ==>
       <PLAY 17-19> ==>
       PRE_SEARCH_TRANSPORT_PAUSE(Stop immediately, then Start=17, Stop=19) ==>
       SEARCH_TRANSPORT_PAUSE(Start=17, Stop=19) ==>
       TRANSPORT_PAUSE(Stop=19) ==>
       <PAUSE 16> ==>
       PAUSE()
Actually means that the second PLAY cancels the previous one, and that the
PAUSE pauses the delivery at the time it is received. (It is equivalent to
PAUSE NOW, in DSMCC terminology, as the Stop parameter refers to a point in
the timeline which has been already elapsed). All previous Start/Stop are
forgotten!

Comments?
__________________________________________________________________________

Guido Franceschini

Multimedia Applications

CSELT                         Tel.:  + 39 11 2286137
Via G.  Reiss Romoli, 274     Fax :  + 39 11 2286190
10148 Torino - Italy          E-mail :  [email-masked]
__________________________________________________________________________

---

From: Changjian SUN <[email-masked]>
Date: Mon, 10 Mar 1997 23:34:19 +0800 (CST)

All,

Please sign me off. Thanks.

-Yongzhou Zhuang