Subject: Re: [MMUSIC] RTSP: Speed and Scale overview text

From: "Burklin Helmut" <[email-masked]>
Date: Wed, 3 Dec 2008 13:25:41 +0100

Magnus,
I apologize to have jumped in a bit hurriedly, I probably have
missed some prior agreements. Nevertheless let me ask a
question on your answer:

> 
> > I am also wondering if it would make sense to add to the 
> > Speed chapter a sentence like:
> > "Note that the data rate on the transmission medium is 
> > proportional to the Speed factor, e.g. a content delivered 
> > with Speed=2 will use twice the data rate as the same content 
> > delivered with Speed=1."
> 
> That is what I am coming at in the end. Yes, that will be 
> true for a naive implementation. But for this to work in 
> reality this can't be universally true. It can only be true 
> in cases where the network path between server and client can 
> support this. Otherwise the server will have to adopt the 
> media to fit within the available resources.
> 
> Thus as that is not true I don't want to add such a sentence.
> 

So, in case the network path doesn't support the load, what will happen?
You say the server will "adapt the media" (typo corrected) - isn't this
reserved to the Scale case only ? 
So do you think that the server that declares not to be able to scale, 
but only to speed, shall scale anyway ?
You guess that I don't think this is a good idea (but as I said, I came
in late to this discussion)

Thank you for clarification

Helmut Bürklin

			Helmut Bürklin
			Senior technical advisor
			Thomson R&D France
			Technology group
			1, Avenue Belle-Fontaine - CS17616
			35576 Cesson-Sévigné, FRANCE
			Tel : +33 (0) 2 99 27 36 27
			Fax : +33 (0) 2 99 27 35 58
			E-mail : [email-masked] 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Dec 2008 15:18:36 +0100

> reserved to the Scale case only ? 

No, that is one the cases I want to stress here. Speed affects the
amount of playback time that is delivered per wall clock time. In a
naive implementation using a speed value that is larger than one will
increase the bandwidth. However, the point I am making is that you can't
do a naive implementation of this because it affects how your fulfill
the congestion control requirement.

When streaming media over the Internet you do need to be a good citizen
and thus adopt the media stream to the available resource. This is
independent if Speed is used or not. So when speed is used on has to
take into consideration that the server will attempt to increase the
bandwidth in relation to the speed value. However, if that isn't
available the server needs to keep the bandwidth with the available
resources. As I see it it can do this two ways:

1. Reduce the bits per playback time, i.e. reduce the quality of the
media encoding, without changing the actual speed ratio.

2. Reduce the speed ratio down to what is supportable as Imed proposed.

So one comes to the question of what should be immutable in this case.
For 1 it is the selected speed value. I see that appropriate if one does
local scale operations. In 2 one tries to make the quality immutable
which is more suitable if one does opportunistic buffer filling.
However, the quality isn't immutable, because if the network path can't
support Speed=1.0 either then the quality have to go down.

So the question remains, what usage are there for speed out there?

> but only to speed, shall scale anyway ?

No, but be able to do bit-rate adaptation. The most common solution to
this is after all bit-stream switching. The server have several version
of the encoding of the same content and is able to switch between the
bit-rates at regular points in the media stream. There are more advanced
solutions but they usually requires on the fly transcoding which is
quite resource demanding.

> in late to this discussion)

I will not comment on this until we are certain which the problem is,
scaling or bit-rate adaptation.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic