Subject: [AVT] RE: [dccp] Re: DCCP Media Guide

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 26 Nov 2003 08:24:49 -0500

Hi Phillipe,

[snipped]
> The other idea I have been trying to advocate for a while 
> because I believe it is another key to the problem
> is that media does not need to be constant bit rate, nor 
> constant packet rate, nor constant packet size.

I'm glad you brought this up.  There have been a lot of comments on this
thread about the difficulties in the human perception of rate-shifting, and,
in general, I'd have to say the comments are pretty accurate, especially
given the current state of the art in codec design.  However, I can think of
at least two instances where rate shifting is either workable or better than
the current practice.

One case involves audio codecs such as G.711 and changing the packetization
interval.  G.711 with 10ms packetization is about 96K IP bps on the wire.
40ms packetization gives about 72K bps.  I think that changing between these
two rates is often close to imperceptible.  A similar thing can be done with
G.729A (although I'm not sure the standard allows it), giving more variation
in the bit rate - 10ms packetization is about 38.4K bps and 40ms is 14.4K.

Another case involves video transmission.  As you change between a high and
low encoding rate the image the user sees is likely to change back and forth
between clear and grainy, and this is likely to be annoying.  But I imagine
it's less annoying than the current practice of freezing the video (and
continuing the audio) when there's insufficient bandwidth for the high-res
video.  I imagine that layered encoding techniques like Gerard Babonneua
mentioned can fit this mode of operation nicely.

Given that there are these low-hanging-fruit stream shifting methods, I
wonder what others are available if we put our minds to it?

Tom Phelan

> These 3 things (delay, reliability, variable rate/packaging) 
> should give some slack
> for the design of a solution with added value no?
> 
> regards,
> 
> 
> Philippe Gentric
> Chief Architect
> Philips Software
> [email-masked]
> http://www.software.philips.com
> 
> 
> 
> _______________________________________________
> dccp IETF mailing list: [email-masked]
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
> 

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

---

From: "Vinay Sathe" <[email-masked]>
Date: Wed, 26 Nov 2003 06:31:22 -0800

This comment is not really related to DCCP. However, the issue of rate
variability of video has been brought up during the discussions. I concur
with the comments regarding video rates below. While it may be true that
"traditional" video codec (MPEG-1 MPEG-2) may have undesirable artifacts due
to transport rate changes (that were unknown to the rate control loop when
the video was encoded), several standards-based and proprietary video codec
exist that minimize visual degradation through severe video rate
changes/dropouts. (M-JPEG2000 is one example).

Best regards,
Vinay 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phelan,
Tom
Sent: Wednesday, November 26, 2003 5:25 AM
To: [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: [AVT] RE: [dccp] Re: DCCP Media Guide

Hi Phillipe,

[snipped]

Tom Phelan

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Nov 2003 09:09:44 -0500

> in the bit rate - 10ms packetization is about 38.4K bps and 40ms is 14.4K.

While this is numerically accurate, it seems largely pointless. If I'm 
below the perceptible delay threshold (say 150 ms one-way), there is no 
reason to transmit at 10 ms packetization interval since the user 
experience will not improve noticeably. Indeed, very few systems 
transmit at 10 ms packetization today. In addition, at the access links 
where congestion is most likely, IP/UDP/RTP header compression reduces 
the difference in bit rates to much smaller values, further reducing the 
utility of doing variable packetization. (From our experiments, a 
packetization interval of roughly 30-40 ms also appears to work best 
with FEC.)

> mentioned can fit this mode of operation nicely.

Again, like Brian pointed out, this assumes that you're aiming for a 
low-quality hey-it's-free experience.

> wonder what others are available if we put our minds to it?

Unfortunately, the first is unlikely to be productive and the second has 
very limited applicability.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Nov 2003 09:09:44 -0500