Subject: PLAY, PAUSE timing

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 07 Mar 1997 09:29:24 -0500

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

PLAY 10-15
PLAY 17-19
PAUSE

would interrupt the server whenever it gets the PAUSE, in either the
first or second segment.

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.

Any comments?

Henning

---

From: Anup Rao <[email-masked]>
Date: Fri, 07 Mar 1997 10:20:30 -0800

> would pause the stream after playing 10-15, position NPT to 16 and not

Some thoughts on the requirements and trade-offs:

a) Retreival of data on a  specific and accurate scale. This is mostly
for editing or other high-end stuff. I think this is being dealt with
well in the current draft with a few additions decided on(such as PAUSE
at a certain time or offset).

b) As far as possible, simplicity of implementation of applications that
do not need a)

c) Possible queuing of  PLAY requests at the server. PAUSE requests
could be applied towards the PLAY in progress.

It would seem that a very simple state model aids greatly in
implemenation, particulary over UDP. c) could cause complexity
particularly in the UDP case since order is not guaranteed. Also, the
client may not know which PLAY message the PAUSE is being applied to -
this cannot do any good. Clearly , by not queueing up PLAYs at the
server, one would occur atleast a RTT delay in starting playing another
range after the first one has ended. This delay is probably
inconsequential from a human user perspective, but not if the client
entity is non-human.

If we absolutely do need this queuing, one option is to associate every
PLAY with an id in its PLAY_REPLY, and for the PAUSE to explicity
reference this id. This way, the high-end client knows what it is
pausing, and state management at the server is somewhat simplified.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 07 Mar 1997 16:06:36 -0500

> b) As far as possible, simplicity of implementation of applications that

A server that anticipates to be a "consumer grade server" (no remote
editing) will always just see PLAY 17-, PAUSE, PLAY 19- rather than
ranges in any event and can be dumbed down accordingly. It may not do
the correct thing when used for editing, but then you don't expect to do
frame-level editing with a $199 VCR, either. But, as pointed out below,
the effort of doing it right is pretty small.

> inconsequential from a human user perspective, but not if the client

Having implemented a few simulators, queueing requests is pretty simple.
You already need to keep track of how much to play. When you reach that
point, just pick the next PLAY command off the list. PAUSE commands
without time skip the queue, with time it finds the appropriate first
match in the PLAY queue. Shouldn't take more than a few lines of code
(we'll see :-)).

Reordering with UDP is a problem only if commands are issued very close
to each other, although I don't have recent reordering distance
measurements.

> pausing, and state management at the server is somewhat simplified.

This doesn't seem necessary or helpful.