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

From: Kylin Wei <[email-masked]>
Date: Fri, 26 May 2006 15:33:12 +0800

Hi Jaehwan,
Thank you for your feedback very much. 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".

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.

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. 
And so on.
Above all, to support conveniently multi-rate and accord with technology
trend, we should extend RTSP instead of using media description.

> 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').
>

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').
> 
> Jaehwan Kim
> Principal Engineer / Streaming Development Manager
> Vidiator (Korea) Inc.
> 7th Fl. AnnJay BLDG 718-2
> YeokSam-Dong, KangNam-Gu, 135-920, Seoul
> www.vidiator.com
> [email-masked]
> 
> 
> media in motion
> This e-mail message (including any attachment) is intended only for
the
> personal use of the recipient(s) named above. This message is
> confidential and may be legally privileged. If you are not an intended
> recipient, you may not review, copy or distribute this message. If you
> have received this communication in error, please notify us
immediately
> by e-mail and delete the original message. Any views or opinions
> expressed in this message are those of the author only. Furthermore,
> this message including any attachment does not create any legally
> binding rights or obligations whatsoever, which may only be created by
> the exchange of hard copy documents signed by a duly authorized
> representative of Vidiator Technology (US) Inc.

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

---

From: "Jaehwan Kim" <[email-masked]>
Date: Fri, 26 May 2006 01:44:24 +0900

function
> been widely used.  Multiple bitrates can be provided within one media
> transport bitrate according to network condition, so I think that it's
bitrate
RTSP
> server and then change transport bitrate before the playing of a movie
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').

Jaehwan Kim

media in motion
This e-mail message (including any attachment) is intended only for the
personal use of the recipient(s) named above. This message is
confidential and may be legally privileged. If you are not an intended
recipient, you may not review, copy or distribute From [email-masked] Fri May 26 07:51:54 2006
Subject: RE: [MMUSIC] Adding the control function to multi-rate in RTSP
Date: Fri, 26 May 2006 18:35:50 +0900
From: "Jaehwan Kim" <[email-masked]>
To: "Kylin Wei" <[email-masked]>
Cc: [email-masked]

Kylin Wei wrote:
> (snip) But I think there should be a
Need to know what is advanced multi-rate codec, exactly.
And what is the exact network set you are considering?
> bitrate value to server, and serve then will change transport bitrate
as
Unavoidable for multiple channels, however, IMO, don't need even PLAY if
it is just multi-coding in the same space.

> 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

> > > been widely used.  Multiple bitrates can be provithis message. If you
have received this communication in error, please notify us immediately

ded within one