Subject: [MMUSIC] Re: [dccp] blocking API (was: stream switching (was: Using DCCP for VoIP))

From: [email-masked]
Date: Fri, 18 Jul 2003 15:23:32 +0200

Damon Lanphear wrote:

>Philippe,
>
>Can you explain the assumptions that inform your assertion that a
>blocked write attempt is "drastic" for an A/V application?  I understand
>how this may be the case for VoIP.  But for streaming A/V I have very
>sincere doubts.
>

Let me explain, then.

   My assumption is that the most efficient existing media encoders
   are all carefully optimized to operate at maximum efficiency for a
   "known in advance" target rate. In all cases best coding
   efficiency is achieved through the maintenance of a relatively
   long context (several seconds typical). Rate control -especially
   in video- is obtained thanks to computations taking into account
   as many frames as possible so as to distribute the available
   bandwidth on many frames etc...

   Specifically I am expressing the concern that driving a modern
   codec "by the frame" i.e. by giving a number of bits for each
   frame without taking any account of analysis of the media content
   is "drastically" sub-optimal.

   Preventing -without warning- an encoder from writing out an
   encoded frame for an -a priori undetermined- amount of time looks
   even worse to me in the sense that I dont know how to drive
   *efficiently* a media encoder of recent technology in a context
   where such a desesperate thing can occur. (I say recent but was
   this not by the way the whole idea of using UDP for RTP instead of
   TCP?)

   I would propose that the idea would rather be that DCCP should
   provide *the application* (which in the case of stream switching,
   encapsulates several codecs) a target rate.

   In all cases optimal results will be obtained if rate changes are
   signaled *as soon in advance* as possible.

   And the question is: why would we not do it since DCCP can provide
   such rate information very easily anyway? (TFRC does that very nicely)

>
>I am guessing that the difference between explicitly stating the rate to
>the application and socket blocking is that DCCP is providing reaction
>time to the application for whatever adaptation the app may need to do
>to fulfill DCCPs transmission requirements.
>

   Exactly !

>I submit that an application can achieve the same ends with socket
>blocking semantics.

   That you *can* do some sort of regulation, I agree, that it is
   optimal in all cases I have to disagree.

[clipped]

>I also assume that if a codec requires lead time for rate switching,
>negotiation, etc., then its the wrong codec for this type of
>application.

   Such a codec is possibly the wrong codec for telephony or
   conferencing but I would be totally frustrated to see DCCP limited
   to this type of applications!

   BTW how are we going to convince the industry to deploy a full
   new bona fide *IP protocol* for *streaming media* if it does not
   leverage the best out of *media codecs* ?

>At the very least, the codec should not require setting up
>a new decoder in response to a dynamic switch.

   Then you will be limited by the rate range: there is simply no
   standard codec of any type (speech, music, video) that covers the
   full possible range in all cases...

   Let us reverse the argument: if the bandwidth variation requires a
   different codec one could be (I am) ready to pay that price.

>Inter-key frame time for
>video should be the longest time lag over which a switch should have to
>take place.

   Allow me to translate this as:

   "the minimum forewarning time for a video codec is an Intra frame
   period"

   and then we agree!-)

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

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

---

From: Damon Lanphear <[email-masked]>
Date: 18 Jul 2003 11:13:22 -0700

The relevance of this discussion to DCCP is such that there is an
expressed need for immediate/advanced notification of DCCP rate changes
to the application through the DCCP API.  There is also an expressed
need for an DCCP API that supports conventional socket blocking
semantics.  Both of these requirements, and their rationale should be
placed in the DCCP User Guide for future reference.

We can further discuss stream switching issues on the mmusic list.   

-- 
Damon Lanphear <[email-masked]>