Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #109 - 2 msgs

From: [email-masked]
Date: Fri, 28 Nov 2003 21:12:53 -0800

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-850256 ] When must RTP-Info be included? (SourceForge.net)
   2. [ rtspspec-Bugs-850256 ] When must RTP-Info be included? (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 27 Nov 2003 22:18:31 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-850256 ] When must RTP-Info be included?

Bugs item #850256, was opened at 2003-11-27 23:06
Message generated for change (Comment added) made by kjh1905m
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: When must RTP-Info be included?

Initial Comment:
At the RTSP discussion at IETF 58 there where some
discussion in regards if RTP-Info really can be
presented in all Play Responses when the media streams
are RTP. The argument was Live media. 

The current specification (05) requires this. 

Are there really a reason for changing this?

----------------------------------------------------------------------

Comment By: Jaehwan, Kim (kjh1905m)
Date: 2003-11-28 15:18

Message:
Logged In: YES 
user_id=365760

IMHO, it is enough that we focus on 2 cases: 1) the 
beginning of the live service 2) live PAUSE/Resume because 
we don't believe live streaming session supports random 
access.

1) The beginning of the live service
At this moment, there is no way for a player to see if the 
session is live or not. But if there is no RTP-Info, the player 
can start its session by the following way:
When a player gets the first rtp packet, it should store the 
rtptimestamp and has to subtract it from the remains.

2) Live PAUSE/Resume
Currently, we use monotonic rtptimestamp increament for 
random access. However, if a player requests PAUSE and 
Resume after a couple of minute, then rtptimestamp has to 
have the time gap. Without RTP-Info, how can the player 
remove the rtptimestamp gap? How can it continue the live 
session without any timegap? 

If RTSP Range header field also doesn't exist, a player can do 
that. From the begginning, the player should remember the 
first rtptimestamp and after the resume, we can just subtract 
the first from the lastest rtptimestamp. And then, we can 
calculate the real presentation time from it, comparing with 
the real PAUSE time gap.

But this behavior of a player is different from general on-
demand service having RTP-Info. Therefore, we need to chek 
our if the player can do that the both cases, RTP-Info and no 
for live. It means a general VOD player might not continue to 
work after live PAUSE.

Feel free to give me an advise regarding this matter if I am 
wrong.

Thank you!
Jae-Hwan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 27 Nov 2003 23:59:12 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-850256 ] When must RTP-Info be included?

Bugs item #850256, was opened at 2003-11-27 15:06
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Nobody/Anonymous (nobody)
Summary: When must RTP-Info be included?

Initial Comment:
At the RTSP discussion at IETF 58 there where some
discussion in regards if RTP-Info really can be
presented in all Play Responses when the media streams
are RTP. The argument was Live media. 

The current specification (05) requires this. 

Are there really a reason for changing this?

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2003-11-28 08:59

Message:
Logged In: YES 
user_id=302620

The argument why a server could not present a RTP-Info
header in a PLAY response was due to that the distribution
server might not be aware of inter media synchronization of
the media streams it forwards. If that is the case there
exist the possibility to perform intermedia synchronization
with RTCP. 

In regards to Jae-Whan's comments: 

Regarding "1) The beginning of the live service" the first
comment is that there is no way of knowing that a session is
live. This we have addressed through the definition that any
open range in the SDP a=range attribute shall be considered
Live. 

"When a player gets the first rtp packet, it should store the 
rtptimestamp and has to subtract it from the remains." I
don't see how this relates to the intermedia synchronization
problem. A client can't rely on that all media streams first
packet will represent the same point in time and would
therefore result in bad synchronization between the media. 

In regards to 2: In a live session if you are continuing
after a couple of minutes there is no reason for removing
the timestamp gap. In a live media session the media will
have advanced during the paused time, therefore there does
not seem to be any reason to synchronize the media prior to
the pause to the one after the pause. Therefore the player
should in a live case flush the buffers when it resumes play
after a pause. Thus the lack of RTP-Info in this case would
have no effect. As the RTP timestamp continues correctly
during the paused time the intermedia synchronization
established prior to pausing will still be valid

I think the main problem of not always requiring RTP-Info is
the intermedia synchronization. RTCP can be used, however
the time until RTCP has been received for all media may be
on order of seconds, thus possibly resulting in that
playback has to be commeneced without synchronization. 

----------------------------------------------------------------------

Comment By: Jaehwan, Kim (kjh1905m)
Date: 2003-11-28 07:18

Message:
Logged In: YES 
user_id=365760

IMHO, it is enough that we focus on 2 cases: 1) the 
beginning of the live service 2) live PAUSE/Resume because 
we don't believe live streaming session supports random 
access.

1) The beginning of the live service
At this moment, there is no way for a player to see if the 
session is live or not. But if there is no RTP-Info, the player 
can start its session by the following way:
When a player gets the first rtp packet, it should store the 
rtptimestamp and has to subtract it from the remains.

2) Live PAUSE/Resume
Currently, we use monotonic rtptimestamp increament for 
random access. However, if a player requests PAUSE and 
Resume after a couple of minute, then rtptimestamp has to 
have the time gap. Without RTP-Info, how can the player 
remove the rtptimestamp gap? How can it continue the live 
session without any timegap? 

If RTSP Range header field also doesn't exist, a player can do 
that. From the begginning, the player should remember the 
first rtptimestamp and after the resume, we can just subtract 
the first from the lastest rtptimestamp. And then, we can 
calculate the real presentation time from it, comparing with 
the real PAUSE time gap.

But this behavior of a player is different from general on-
demand service having RTP-Info. Therefore, we need to chek 
our if the player can do that the both cases, RTP-Info and no 
for live. It means a general VOD player might not continue to 
work after live PAUSE.

Feel free to give me an advise regarding this matter if I am 
wrong.

Thank you!
Jae-Hwan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=850256&group_id=23194

End of Rtspspec-bugs Digest

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