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

From: "Matthew Heaney" <[email-masked]>
Date: Mon, 27 Oct 2003 12:37:25 -0500

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Monday, October 27, 2003 4:46 AM
> To: Tom Marshall
> 
> 4. Use a RTP extension.
> This solution can either be implemented through a new RTP 
> payload format 
> including the necessary information, or through some RTP 
> header extension.
> - Will go in the media channel as media rather than signalling.
> - Can't be sent in advance for certain media requiring continuos RTP 
> sequence numbers if it requires its own packets.
> - Is not robust will require that one either uses some type 
> of ACKs and 
> adaptive transmission of them or do a repetition accomplishing high 
> enough delivery probability.
> - The use of header extension would prevent other header extensions.
> - The use of a payload format would either require its own 
> RTP packet or 
>   use of RFC 2198.

Other issues:

o What is the rtp timestamp of the EOS indication?

o If the EOS indication increments (rtp timestamps are "monotonically
increasing"), then by how much should the timestamp increment for each
EOS sent?

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

---

From: "Matthew Heaney" <[email-masked]>
Date: Mon, 27 Oct 2003 14:19:02 -0500

I suppose I should also bring up the issue of end-of-stream vs.
end-of-play.  

Perhaps it would be useful for the server to indicate that it's done
playing all the streams implied by the aggregate play request.

(This actually requires some work in the TrueCast case, since each
stream is more or less independent.  Right now I leave it up to the
client to decide when to issue the (aggregate) PAUSE or TEARDOWN request
following receipt of one or more EOS indications.)

-Matt

> From: Matthew Heaney 
> Sent: Monday, October 27, 2003 12:37 PM
> To: Magnus Westerlund; Tom Marshall
> Cc: [email-masked]; [email-masked]
> Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to 
> indicate end of medi a stream
> 
> 
> 
> 
> o If the EOS indication increments (rtp timestamps are 
> "monotonically increasing"), then by how much should the 
> timestamp increment for each EOS sent?
> 
>

---

From: Thomas Zeng <[email-masked]>
Date: Mon, 27 Oct 2003 11:24:22 -0800

> From: Matthew Heaney [mailto:[email-masked]]
> Sent: Monday, October 27, 2003 11:19 AM
> To: Matthew Heaney; Magnus Westerlund; Tom Marshall

> playing all the streams implied by the aggregate play request.

Do you imply "end-of-play" should be signalled by RTSP server, then?

---

From: "Matthew Heaney" <[email-masked]>
Date: Mon, 27 Oct 2003 15:19:27 -0500

> From: Thomas Zeng [mailto:[email-masked]] 
> Sent: Monday, October 27, 2003 2:24 PM
> 

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.

---

From: "Amir Wolf" <[email-masked]>
Date: Tue, 28 Oct 2003 11:02:21 +0200

Hi All,
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. 

> 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]