Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution?

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Dec 2003 13:25:33 -0500

Magnus

You saw the message from Henning on the effect of slow start on
conferencing applications didn't you?  What makes you think
the video is any different?

In a conference application, streams come and go as different speakers
come and go.  Even in a centrally mixed conference, which is not
as demanding as an end-system mixed conference, most participants
are not talking, and not sending video.  When they start talking,
the start sending media, voice and video.  To send media all the
time unnecessarily uses bandwidth; a lot of it.

We don't do this now, we are end system mixed.

Even your basic assumption that coarse video is acceptable for
a while is not true; it looks very poor.

Actually, I'm not aware of any conferencing video systems that ramp
bandwidth.  The reason is that the codecs are parameterized for a given
quality level/bandwidth, and you can't smoothly change the parameters -
you set them and restart the codec.  I suspect that you could design
a codec to smoothly ramp, but that's not what we have available to us
now.  What you do see sometimes is a codec which has a fixed bandwidth
but the algorithm itself sends coarse image more often than fine image,
and you see that effect on startup.  That is very undesirable, but
it exists.

Brian

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, December 08, 2003 12:07 PM
> To: [email-masked]
> Cc: Rosen, Brian; 'Eddie Kohler'; [email-masked]; [email-masked]
> Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media
> dis tribution?
> 
> 
> Hi,
> 
> > And, I'd still love to hear from others as to whether this 
> "instant-on"
> > is a requirement across the board or whether you're a special case.
> 
> Okay, my view on this topic about the instant-on is the following.
> 
> Streaming applications, i.e. with buffers, should do reasonably well 
> with a slow start as it will most likely only effect the initial 
> buffering delay.
> 
> When it comes to interactive real-time applications, i.e. without 
> buffers, I think the Brian's view is mostly correct. All 
> applications in 
> this area does need to try to transmit at there lowest supported 
> bit-rate initially. Then the question is what the lowest 
> bit-rate is. It 
> is not 4 mbit as somebody claimed for a high-rate conferencing 
> application. Because in that case there exist techniques that 
> will allow 
> one to use a slow starting type of performance, which trades initial 
> video quality against bandwidth during the slow start. For the 4 mbit 
> video stream the initial bit-rate may be 256-512 kbits or 
> possibly even 
> lower. This will be a very coarse quality. but as one continues to 
> transmit during the slow start and discover more bit-rate one can 
> increase the quality. And I don't see this as having the same user 
> problems as bit-rate switching is claimed to have. I think 
> that any user 
> of a circuit switched video telephony client are rather used to this 
> behaviour, when major changes in video happens.
> 
> It will be a bigger problem for certain high quality audio 
> codecs that 
> are used. If the codec does not support to do bit-rate/quality 
> trade-offs then it probably not very suitable for usage in these best 
> effort networks. There exist codecs that will allow 
> reasonable bit-rate 
> steps to be used.
> 
> I think that the realistic thing in this environment is to be 
> reasonable 
> in both directions. I think that one has to understand that 
> one a best 
> effort network the media apps can't continue to behave 
> irresponsible and 
> simply blast away with UDP. It is better to start accept the 
> fact that 
> there will be need for a trade off. Then, if one needs to blast away, 
> then one needs to develop more solutions or use resource reservation.
> 
> 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]
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Dec 2003 09:49:09 +0100

Hi Brian,

> the video is any different?

I wasn't thinking of conferencing. I was more thinking of single 
conversational cases. I agree that the leg from a new sender to the 
conference focus will be problematic, and every switch would need to do 
the slow start which would effect the media badly.

The reason I think video is different from other media like audio is: at 
least in a conference application, the amount of bandwidth. You can get 
high quality voice using for example AMR-WB with a source bit rate of 
23.35 kbit/s + IP/UDP/RTP overhead giving a total around 40 kbit/s. 
While 40 kbit/s video gives either a very small picture or very bad 
quality. To get a comparable quality in the video with a least a CIF 
size screen you must go much higher.
> time unnecessarily uses bandwidth; a lot of it.
I agree that sending all the time is stupid.

> a while is not true; it looks very poor.

Yes, my point was not that it would not look bad initially, my point is 
that is that it is possible to make the video codec go from a very bad 
initial quality up to as good as you have bandwidth. In an application 
that keeps on sending the bad quality is only in the initial start-up.

> and you see that effect on startup.  That is very undesirable, but

I am not surprised that there is no system that does this. As I said in 
my previous mail it is time for media application developers to leave 
their heaven of no congestion awareness and start developing things.

Regarding the video codecs and their parameter sets. I know that if you 
need to switch parameter sets it can create problems in some codecs. 
However I know of least one codec, H.264, that is design and supports 
the use of multiple parameter sets. Also within a parameter sets the 
video has rather large differences in possible bit-rates. Even if no 
person has been using a video codec in the fashion of frequently turning 
on the bit-rate limit to the control, it is possible.

Still the main point I would like to make is: For best effort services, 
we and the users will probably need to accept that quality can vary or 
be changed during a session, due to congestion. If one can't accept 
this, then one must start using resource reservation.

Then media applications can encourage the network and congestion people 
to continue develop solutions that can get rid of slow start to be able 
to improve quality in the future.

I also liked the proposal from Eddie about the speeded up slow start 
that will lower the media impact.

Is someone keeping track of the different applications that will have 
problem and the different proposed solutions.

Best Regards

Magnus Westerlund