Subject: RE: "seq" in Transport-Info

From: "Anders Klemets (VXtreme)" <[email-masked]>
Date: Thu, 28 Aug 1997 13:44:04 -0700

> It was suggested in Munich that this be changed to the PAUSE response
> (giving the last sequence number before pause) in order to reduce
> delay.  

> This means that the mapping between RTP timestamp and NPT changes
> during a pause and so it might have to be communicated explicitly at
> each play.  

So the suggestion is to provide the last sequence number in the PAUSE
response, and the remaining parameters in the PLAY response.  This still
means that the client needs to wait for the PLAY response before it can
start playing.  So I don't see what is gained by putting a sequence
number in the PLAY response.

> The advancement of the RTP timestamp should reflect the
> progress of real time at the server.  That is, during a pause,
> the RTP timestamp should keep ticking along with real time

Leaving the RTP "clock" running during a PAUSE operation actually
complicates things.  When the server resumes from a PAUSE, it must keep
track of for how long it was paused, and add that time to all the
timestamps it sends.  This is particularly a concern when the server is
playing from a file, as opposed to from a live encoder.

This also causes problems on the client.  Here is an example.  The
client sends a PAUSE at time T.  It already has packets with timestamps
T+1 and T+2 in its playout buffer.  Before the server has received the
PAUSE, the client also receives packet T+3.  The client then sends a
PLAY at time T+10.  Since the RTP clock is now T+10, packets T+1, T+2
and T+3 are "overdue" and might be skipped by a media renderer, or
played at a faster speed, or whatever.  The server changes the timestamp
of packet T+4 so that it becomes T+14.  Until that packet has arrived at
the client, the client has no packets with timestamps >= T+10 in its
playout buffer, and the client might "stall".

These problems are not unsolvable, of course, but they seem to require
adding extra logic in the clients to "tweak" RTP timestamps when the
problem could simply be avoided by stopping the RTP clock during a pause
operation.

Anders

---

From: Stephen Casner <[email-masked]>
Date: Thu, 28 Aug 1997 16:06:09 -0700 ()

Anders,

> number in the PLAY response.

Actually, it might not be necessary to communicate the relationship
between RTP timestamp and NPT explicitly.  I have not thought
carefully about all the reasons one might want to know that
relationship, but for a progress indicator I think the following is
sufficient:

  - the PAUSE indicates the last sequence number of the data before
    pausing (or it can add one which will be the first sequence number
    after play resumes)

  - the user moves the slider to a new point, and that new NPT is sent
    in a PLAY

  - when the first packet of the from the new PLAY arrives, the
    receiver can then associate that packet's RTP timestamp with the
    new NPT.

  - at the appropriate time, the first packet will actually be played.

  - the progress indicator can be advanced based on the advancement of
    RTP timestamps as they are played.

Now, getting access to RTP timestamps at the UI level might be
difficult, but this is all postulated on the desire to use RTP
timestamps for UI purposes.

> playing from a file, as opposed to from a live encoder.

Yes, that's right, for the case of a server playing from an "RTP
file", it could not just pump out the packets directly from the file.
In addition to adjusting the timestamps, I am saying that the server
should also adjust the sequence numbers when a reposition has been
done so that RTP packet loss accounting works.  However, if the file
format it not RTP, you are going to be building the RTP headers
anyway and this is not really any extra packet-by-packet work.

> playout buffer, and the client might "stall".

What if the client does a reposition while paused?

> problem could simply be avoided by stopping the RTP clock during a pause

I suppose there are a variety of possible implementations, but I would
expect that a low-delay system might play packets T+1,2,3 and then
pause at that point.  A high-delay system might want to implement
immediate local pause, but then the extra packets after the pause
might just be tossed.  If playback is resumed with "PLAY T", then the
packets would be sent again with timestamps T+10, etc.  Or if a
reposition is done, then "PLAY T+R" would result in packets from a
different spot in time coming with timestamps T+10.  If the client
issued the unspecified "PLAY" form, then yes it would have to adjust
the timestamps of the packets it was saving from the last play.

Being realistic, I suppose that receivers will have to be prepared to
accept all sorts of wierd behavior from servers unless we carefully
specify the behavior, and probably even if we do.
							-- Steve