Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream

From: "Matthew Heaney" <[email-masked]>
Date: Tue, 28 Oct 2003 11:14:44 -0500

> -----Original Message-----
> From: Amir Wolf [mailto:[email-masked]]
> Sent: Tuesday, October 28, 2003 4:02 AM

> I think that signaling EOS per stream has more value since
> one of the most helpful uses of this feature is when you play 
> a very low fps video e.g. average of 1/4 fps and audio. It is 
> important for the player to know when video ends, while it 
> can easily identify end of session by getting the required duration. 

What do you mean by "required duration"?  The value of the RTSP Range
header, or something else?

The problem is a PLAY request.  At least in the current spec, if a
play-with-range request is received while a previous play request is
still playing, the server is supposed to queue the request.  A
play-sans-range request is a query if the server is still playing, but
causes a state change if the server is not playing.

The problem is defining what "still playing" means.  In the normal case
the audio and video streams are never exactly the same duration, so one
stream can easily finish before another.  (The is especially true in the
TrueCast case, because I try to stay 5 sec. ahead of real-time for
audio, so that stream will definitely finish first.)

So if one stream finishes, does this mean the original play request is
"still playing," because not all of the streams are done?  This is what
I was alluding to in my previous post about a play request being
"atomic."

The issue is that if the client must synthesize whether the server
thinks it's done, by keeping track of the different EOS indicators, then
the client might reach a conclusion that's different from the server.
If the server says that it's done, then there is no ambiguity.

This can be a problem if the client issues a play request (say, sans
range header), because he doesn't know apriori whether the server will
treat this as a no-op query, or actually start playing, unless the
client knows the exact state of the server.

The RTSP spec isn't very helpful on this point, because it doesn't
clearly define what "still playing" means for an aggregate play request.

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf 
> > Of Matthew Heaney
> > Sent: Monday, October 27, 2003 10:19 PM
> > To: Thomas Zeng; Magnus Westerlund; Tom Marshall
> > Cc: [email-masked]
> > Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to
> > indicate end of medi a stream
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Thomas Zeng [mailto:[email-masked]]
> > > Sent: Monday, October 27, 2003 2:24 PM
> > > 
> > > > -----Original Message-----
> > > > From: Matthew Heaney [mailto:[email-masked]]
> > > > Sent: Monday, October 27, 2003 11:19 AM
> > > > 
> > > > Perhaps it would be useful for the server to indicate
> > that it's done
> > > > playing all the streams implied by the aggregate play request.
> > > 
> > > Do you imply "end-of-play" should be signalled by RTSP
> server, then?
> > 
> > I was thinking that if we treat the original play request
> as "atomic,"
> > that perhaps the server should indicate that the entire
> play request
> > has finished.  By "finished" I mean all the streams that entered the

> > playing state as a result of the aggregate play request are done.
> > 
> > If you send an EOS indicator for each stream separately, then it's 
> > up to the client to figure out when to move to another aggregate
> play state.
> > Right now he must synthesize this information himself, based
> > on how many
> > streams were reported back in the RTP-Info of the PLAY 
> > response, and how
> > many different EOS indicators he has received.
> > 
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked] https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Oct 2003 17:50:23 +0100

Hi Matthew,

I can do one simplification for you. When we are discussing an End of 
stream or play request we are doing this in the context of the updated 
specification. However I do see that there is probably need to make some 
short considerations on how this will interoperate with RFC 2326 
implementation.

However if you are not familiar with the currently ongoing work on 
updating RTSP you can start with looking at the latest draft version. 
However I will already now make it clear that the draft is not 
publication ready. We authors are hoping to get a version out before 
christmas that actual incorporates all decided fixes to the protocol.

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt

The current RTSP is a protocol stripping away all functionality that was 
not implemented in RFC 2326. So the following functionality has been 
removed:

- Queued play
- Record and Announce methods.
- Use of non-aggregated play and pause control in Aggregated sessions.

More information about this work can be seen on:
http://rtsp.org
http://rtspspec.sourceforge.net

In regards to the end of media/play request fulfilled signalling this 
does not change much. However your arguments about separating initial 
and any queued play is probably not a argument we would give much 
attention to.

This allows me to bring up a discussion on why this signalling is need. 
Reasons I see:

- For living signalling without a predestined end of the session. In 
this case it seems the main goal is to inform the client that session 
has ended. Possibly a user readable reason is desirable to be given, 
Like "Tonight's jam session has now ended, come back next Tuesday for 
more interesting music!". The timing of this is that the message should 
be possible to give as soon as the last media has been played out.

- To allow the transport handler in the client to know what the last 
packet it will receive to prevent unsecurity about buffering handling, 
retransmission. Thus it is desired to know before the last packet is 
received that it will be the last one. This is true independently of the 
session type.

- To inform the client about that the play request has been fulfilled 
and all media streams will be delivered when the given packets has been 
received. However for media streams that has a determined length and for 
PLAY requests with closed ranges this information is derivable to a high 
degree. The exact sequence number can't be determined, however the RTP 
timestamp for the end of the request can be determined.

- Something new which we haven't discussed so far is: Error information. 
If the server fails to fulfil the request during the playout. Using a 
server->client message the server can inform the client that the 
delivery has failed, why, and at which point in the media stream.

Are there any more reasons for having something like this?

I would also like to make people aware that depending on what usage are 
the most important the preferred choice of delivery is different.

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]