Subject: Re: [MMUSIC] stream switching

From: [email-masked]
Date: Thu, 12 Jun 2003 14:35:10 +0200

Andreas Kassler wrote:

> [erased lines]
>I think there are three main issues:
>- stream switching is end-to-end and can be seen as a reaction to congestion
>    --> congestion control

Good !

> [erased lines]
>- frame skipping at the sender does only lead to
>temporal scalability and limits the choices of user QoS
>scalability to the temporal domain. In contrast, when using
>stream switching, quality scalability or even spatial scalbility
>may be achieved.

Yes!

I think this is a key issue that I should have stressed more
to attrack attention, for example what is being done in 3GPP right now
concerns MPEG-4 video SP@L0 for which these issues are simply out of scope
(you keep the same codec, same image size etc)

I would like to have a much more powerful tool in terms
of bit rate range and codec choice etc.

>But this is up to the video provider, who has to
>encode the alternative streams in a proper way. However, the
>disadvantage of stream switching is the need for more resources
>at the server, as each video alternative consumes disc space.

This is a well understood disavantage, the feedback we have from
customers today is (in short) that it is "worth it".

It is also only a "compromise" issue: if you have more
disk you do (a little) better, the *principle* remains.

Also we are talking about audio AND video usually
and by playing around with the sum (audio+video)
you can create up to #audio*#video different rates,
which is a rapidly growing number!

=> disk size = proprotional to #Audio+#Video
=> number of different rates = #Audio*#Video

> [erased lines]
>> * Can we say that there is a concensus that Stream Switching is a good
>> candidate for rate and congestion control in streaming (i.e. in the
>context of RFC3448) ?
>
>I would say it is a candidate, but I doubt you can do it in a TCP friendly
>way, unless you
>have very fine granular bandwidth steps between the alternative streams.

We had some rather good surprises here when going from theory to practice !-)

Actually the way TCP behave is, when going down, to divide the rate by 2:
you dont need *that* many alternate streams to do that !

Example (in kb/s): 50,25,12,6

Now if the question is "is this TCP friendly ?"
then I would say that the issue is NOT the number of different rates you use
but rather the issue is that your rate at a given moment
should be SMALLER than the rate computed using TFRC!

i.e. if RFRC3438 says "use 37.8 kb/s" then I would use 25 kb/s
and this is "better" than TCP friendly right?

regards,

Philippe Gentric
http://www.platform4.philips.com

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