Subject: RE: [MMUSIC] draft-rfc2326-06 comments wrt live streaming

From: Thomas Zeng <[email-masked]>
Date: Wed, 7 Apr 2004 14:17:08 -0700

Hi Geetha and Magnus:

I have been reading this thread of discussion, and have some feedback for
your reference.

See inline.

Cheers,
-Thomas

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Thursday, April 01, 2004 1:44 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming

Hi Geetha,

See inline

Geetha Srikantan wrote:

> Magnus,
> 
> I see your point of view on this, since you clarified your assumptions.
> 
> In previous offline discussions there were discussions about how a RTSP 
> server would
> maintain timing info for live streams. My confusion was centered around 
> that.
> 
> I believe RTCP SR-based synchronization is possible, as you pointed 
> out..however it does
> have some issues, as mentioned previously.
> 
> Replying inline to some of the points in this mesage...
> 
[snip]

>>> Section 14.40, page 91:
>>> ssrc:
>>> The transport header in the server's response cannot populate the ssrc
>>> for each stream, accurately in certain scenarios.
>>> The source of the live stream may not be RTSP-aware, and the server 
>>> has to rely on RTP/RTCP to determine ssrc for each stream.
>>> The server may have joined a multicast live session and receives, 
>>> say, one of the streams.
>>> It also receives SETUP request from a client and needs to respond to 
>>> SETUP from a client,
>>> before it sees the first packet of each stream.
>>> Dropping the ssrc parameter from the Transport header in the SETUP 
>>> response would
>>> simplify this case.
>>
>>
>>
>> It is possible to skip the SSRC, however not recommend as it indicates 
>> for which SSRC the synchronization information in RTP-Info applies to. 
>> Thus I would recommend that server awaits at least the first RTP 
>> packet to determine what SSRC is used for media distribution.
> 
> 
> I am not convinced that the user experience is good when a server 
> refuses clients access to live sessions until
> it has access to all the stream synchronization information. If the 
> server were to send RTP and RTCP packets,
> without the RTP-Info or SSRC in RTSP responses,

[tz] Geetha: SSRC serves another purpose besides stream synchronization, and
therefore without SSRC some players may not function well. Hence I second
Magnus recommendation: server waits for the first RTP to get SSRC -- the
delay is not that bad, right? Here are some more details: in our player
(PacketVideo player) implementation, we use SSRC to filter out spurious
packets on the RTP and RTCP receive port. Here is how it works: we record
the SSRC in RTSP SETUP response; after we change to PLAYING state, we obtain
RTP packets from our RTP receive port. We then filter the RTP packets by the
expected SSRC.
[tz] Here is how it helps: in wireless environment, it is not uncommon to
have connections dropped due to bad channel conditions. Many a time player
connects back and start a new session, but the OS happens to assign the same
RTP receive port number. The server is not yet aware that previous session
has been dropped (it needs to go through the timeout period waiting for RRs
to come), and is sending both old session's RTP and new session's to the
player. Filtering by SSRC helps the player to ignore unwanted RTP packets.

> the client has an 
> opportunity to start decoding each stream
> independently and perform inter-stream synchronization as soon as the 
> client receivess one RTCP SR per stream.
> There is at least some media being rendered at the client, even if it is 
> not lip-sync'd etc.
> 

As I wrote in the other mail I don't think this will occur frequently. 
In a well designed system using RTSP the synch information will be 
distributed using TCP, and will basically arrive as soon as possible. If 
there are problems delivering the RTSP response.

A server waiting for the synchronization information can also use a 1xx 
code to tell that it is in fact waiting for the sync info.

I would like to get some feedback from client implementors, it they 
really are willing start without synch and then try to do graceful fix 
of the synchronization when the information arrives. 

[tz] In the early days we (PacketVideo) did have a version of player that
can start with neither RTP-Info information nor SR information. It assumes
the first received RTP packet in video track is in synch with the first RTP
packet in audio track, which is invalid if there are packets lost before the
first one received, or that the sender do not send them in sych. So I am
inclined to say that player can do it if the user can live with the degraded
user experience in the beginning. Note that the player always has to check
sychronization upon receiving  timing information in SRs.  

[tz] Now a more interesting problem is for random positioning (as you
touched upon below). It is well known that RTP-Info is required to handle
PLAY after PAUSE (see a discussion thread a few months ago in this mailing
list). Fortunately I have not seen customers asking for PAUSE in live
streaming. But others might have. I don't know.

Also without giving 
the RTP-Info TS + Range it will be impossible to present accurate 
session position information. A client will only be able to calculate 
time since media delivery started.

I think a lot of these discussion concerns issues that should be 
discussed in your streaming relay draft to achieve good performance and 
avoid these issues you are so concerned with. From a client perspective 
, I haven't seen a lot of need for clarifications. However I can look on 
how to further improve the discussion in the RTP appendix on synch. 
Otherwise I would recommend if you have specific concerns to present 
proposals for new text.

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]

_______________________________________________
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: Geetha Srikantan <[email-masked]>
Date: Wed, 07 Apr 2004 17:34:56 -0700

hi Thomas,

Thanks for the feedback and notes about client side issues.
Replying inline...

>player. Filtering by SSRC helps the player to ignore unwanted RTP packets.

This looks like a good use case for having the SSRC in the SETUP 
response's Transport header.
Thanks for providing the details.
I'm less concerned about delays caused by the SETUP response, than by 
PLAY response.

>sychronization upon receiving  timing information in SRs.  
Ok..

>streaming. But others might have. I don't know.
Live sessions can't be PAUSED, right? So this shouldn't be an issue..

geetha

---

From: Geetha Srikantan <[email-masked]>
Date: Thu, 08 Apr 2004 15:25:01 -0700

> Live sessions can't be PAUSED, right? So this shouldn't be an issue..

I meant to say - live streams can't be paused in the same sense as on-demand
streams. PAUSE for on-demand streams, implies the capability to pick up
from the PAUSE point. For live, resuming after a PAUSE will resume at 
the *current*
position in the stream and not from the PAUSE point.

geetha