Subject: [MMUSIC] Adding the control function to multi-rate in RTSP

From: Kylin Wei <[email-masked]>
Date: Thu, 25 May 2006 13:42:47 +0800

Dear mmusic experts,

I would like to request some feedback about adding the control function
to multi-rate in RTSP.
Now, multi-rate coding technology and scalable coding technology had
been widely used.  Multiple bitrates can be provided within one media
file. Because there are some disadvantages on changing automatically
transport bitrate according to network condition, so I think that it's
necessary to provide a way that an audience can change transport bitrate
on his own. A client can inquire bitrate range of a media file from RTSP
server and then change transport bitrate before the playing of a movie
or during the playing of that.

Kylin Wei 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 May 2006 10:13:11 +0200

> or during the playing of that.

If you have a file with multiple bit-rate representation there is not 
much needed to do the bit-rate switching based on network feedback.

1. Ensure that the SDP you present is valid for all alternatives. This 
may require the use of multiple payload formats to indicate different 
configurations if the span is very big.

2. Switch between the representation during runtime in a seamless way. 
This is supported in for example the ISO base media file format through 
synchronization points and other constructs.

The real issue that arises is not in the transport or the setup 
signalling. It is in the capability exchange. If one does not know which 
capabilities the client has, offering the full SDP in the DESCRIBE may 
result in a failure due to that the SDP extends beyond the client's 
capabilities. In 3GPP PSS (TS 26.234) this is resolved using UAProf in 
the DESCRIBE request to indicate the capabilities of the terminal.

There may also be interest from the client to indicate which alternative 
is the most suitable to start with. The simplest way is probably having 
the client send the bandwidth header to the server. 3GPP made a bit more 
advanced solution where the client can actually use the URIs to indicate 
which alternative bit-rate it like to start with. See 3GPP TS 26.234 for 
more information on that.

Cheers

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]

---

From: Kylin Wei <[email-masked]>
Date: Mon, 29 May 2006 19:58:31 +0800

> synchronization points and other constructs.

Thank you and Colin for your advices. I see what you mean. But I have an
integrated solution for multiple bit-rates. For example, it includes not
only inquiring and changing transport bit-rate but also increasing
access bandwidth and applying for bandwidth reservation by RSVP
according to fine granular bit-rate range. I think that it's necessary
to implement that as a whole in RTSP. Of course, it may be faulty. I
want to discuss it carefully with someone who is interested in it at
66th meeting if possible.

Kylin Wei