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

From: Kylin Wei <[email-masked]>
Date: Fri, 26 May 2006 19:46:58 +0800

> Need to know what is advanced multi-rate codec, exactly.
> And what is the exact network set you are considering?

IMO, advance multi-rate codec is a kind of very fine granular codec and
it has also a very large bitrate range.
For example, an audience can change transport bitrate of video on-demand
from 510K to 512K to get better video quality according to current
network condition. At the same time other audience with high access
bandwidth who orders the same movie can watch video with 5M bitrate.

> Unavoidable for multiple channels, however, IMO, don't need even PLAY
if
> it is just multi-coding in the same space.

PLAY request is necessary because I insist that the user can take the
initiative to change transport bitrate.

> Can I have full SDP in your mind(better with full RTSP)? It would be
> possible and multiple SETUPs are unavoidable in advance, though.

I mean that we can avoid multiple channels in the case of multiple media
files of the same media program.

Kylin Wei 

> -----Original Message-----
> From: Jaehwan Kim [mailto:[email-masked]]
> Sent: Friday, May 26, 2006 5:36 PM
> To: Kylin Wei
> Cc: [email-masked]
> Subject: RE: [MMUSIC] Adding the control function to multi-rate in
RTSP
> 
> Kylin Wei wrote:
> > (snip) But I think there should be a
> > better plan to control conveniently multi-rate in RTSP.
> > Follow is my explanation:
> > 1. Some more advanced multi-rate coding technologies will be
presented
> > and a great deal of different bitrates can be provided within one
> media
> > file. Using current solution, you perhaps will list hundreds of
> > "m=lines" and there was a large numbers of redundancy because their
> > <media>, <port>, <transport> and <fmt list> sub-fields may be the
> same.
> > So I intend to list only one "m=line" with default bitrate for a
> > multi-rate media file. When a client inquires the bitrate range of
the
> > media file, RTSP server will respond bitrate range in Bitrate header
> > field. For example: "Bitrate: 56K, 75k, 100K, 120K.........5M".
> >
> Need to know what is advanced multi-rate codec, exactly.
> And what is the exact network set you are considering?
> > 2. If a client wants to change transport bitrate, it must detach
from
> a
> > channel and attach to another channel through SETUP/TEARDOWN. I
think
> > that is inefficient. I wish that a client can send a PLAY request
with
> > bitrate value to server, and serve then will change transport
bitrate
> as
> > client wanted.
> >
> Unavoidable for multiple channels, however, IMO, don't need even PLAY
if
> it is just multi-coding in the same space.
> 
> > 3. Sometimes we can prepare multiple media files for a media
program.
> > Every file has only one bitrate and their bitrates are different.
The
> > URI of a media file is the default URI presented to user. When a
> client
> > sends a PLAY request of changing transport bitrate, server will
> redirect
> > the client to corresponding URI.
> Can I have full SDP in your mind(better with full RTSP)? It would be
> possible and multiple SETUPs are unavoidable in advance, though.
> 
> Cheers,
> Jaehwan
> 
> > And so on.
> > Above all, to support conveniently multi-rate and accord with
> technology
> > trend, we should extend RTSP instead of using media description.
> >
> > Kylin Wei
> >
> > > -----Original Message-----
> > > From: Jaehwan Kim [mailto:[email-masked]]
> > > Sent: Friday, May 26, 2006 12:44 AM
> > > To: Kylin Wei
> > > Cc: [email-masked]
> > > Subject: RE: [MMUSIC] Adding the control function to multi-rate in
> > RTSP
> > >
> > >
> > > > 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
> > > >
> > > It has been from the beginning of RTSP. If server provides a
couple
> of
> > > channels(m= lines) in SDP, player can attach/detach the channel
> > through
> > > SETUP/TEARDOWN accordingly. All things are up to player
> > implementation.
> > > As for bitrate change and a kind of grouping purpose, 3GPP
proposed
> > SDP
> > > alternative(a=alt, you can google with '26.234').
> > >

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

---

From: "Jaehwan Kim" <[email-masked]>
Date: Fri, 26 May 2006 18:35:50 +0900

Kylin Wei wrote:
> 1. Some more advanced multi-rate coding technologies will be presented
media
same.
> multi-rate media file. When a client inquires the bitrate range of the
> 2. If a client wants to change transport bitrate, it must detach from
a
> channel and attach to another channel through SETUP/TEARDOWN. I think
> that is inefficient. I wish that a client can send a PLAY request with
> bitrate value to server, and serve then will change transport bitrate
as
> client wanted.
Unavoidable for multiple channels, however, IMO, don't need even PLAY if
it is just multi-coding in the same space.

> 3. Sometimes we can prepare multiple media files for a media program.
> Every file has only one bitrate and their bitrates are different. The
client
redirect

Cheers,
Jaehwan

technology
had
automatically
> > > transport bitrate according to network condition, so I think that
> it's
from
> > It has been from the beginning of RTSP. If server provides a couple
of
> > As for bitrate change and a kind of grouping purpose, 3GPP proposed
> SDP

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 May 2006 13:06:11 +0100

> initiative to change transport bitrate.

It's not clear why you're doing this in RTSP, rather than at the  
media transport level. I would have thought that a congestion control  
algorithm, such as you are describing, would be better implemented in  
the media channel.

Colin