Re: [codec] #18: Frame Sizes? (was: Frame Sizes)

["codec issue tracker" <[e-mail]>]

#18: Frame Sizes?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

 [JM]: As the author of CELT, I obviously agree that latency is an
 important aspect for this codec :-) That being said, I tend to say that 20
 ms is still the most widely used frame size, so we might as well optimise
 for that. This is not really a problem because as the frame size goes
 down, the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate
 becomes a bit less of an issue. For example, with 5 ms frames, we would
 already be sending 64 kb/s worth of headers (excluding the link layer), so
 we might as well spend about as many bits on the actual payload as we
 spend on the headers. And with 64 kb/s of payload, we can actually have
 high-quality full-band audio.

 [Raymond]: The way I see it, for conference bridge applications at least,
 I think it would be a big mistake for IETF to recommend a codec with a
 frame size of 20 ms or higher.  From my analysis above, by doing that we
 will be stuck with too long a delay and the associated problems.

 [Mikael]: From my point of view as a network engineer, it would be a
 mistake to recommend *fixed* frame size at all. The codec needs to be able
 to handle everything from 5ms to 250ms frame size depending on network
 conditions (please see my emails from a few months back regarding the
 reality of the Internet today).

 [JM]: I think I may have been a bit ambiguous in my previous email. I am
 totally in favor of supporting 5 ms frames. TO me, it is becoming clear
 that we want to support both 5 ms *and* 20 ms frames. I don't think it
 would be too hard to support both.

 [Koen]: Let me ask you something: how often is G.729 used with 10 ms
 packets,
 or Broadvoice with 5 ms packets?

 [Raymond]: Not very often, but that’s because previously network
 routers/switches didn’t like to handle too many packets per second, and
 the higher packet header overhead associated with a smaller packet size
 means the overall bit-rate would be higher than desired or allowed, so the
 time of small packet size for low-delay VoIP hasn’t really come yet.
 However, with the help of Moore’s Law, network routers/switches are
 becoming much faster now, and I was told that they can handle a 5 ms
 packet size without problems; furthermore, the speed of backbone networks
 and access networks keep increasing with time, so the bit-rate concern
 will also decrease with time.
 Unlike processing speed and communication speed that continuously get
 improved with time for decades, delay is one thing that will NOT get
 improved with time and Moore’s Law cannot do anything about that!
 If the IETF codec has a minimum frame size of 20 ms, we will be stuck with
 the longer overall delay associated with that, and Moore’s Law will not
 help us reduce that delay in the future.  On the other hand, in addition
 to using a 20 ms frame size for bit-rate-sensitive applications, if the
 IETF codec also has a low-delay mode that uses a 5 ms frame size, then at
 least for delay-sensitive applications, people have a choice to achieve a
 lower delay by paying the price of a higher overall bit-rate (i.e. with
 packet header counted), and this higher bit-rate will be less and less of
 a concern as the network speed keep increasing with time.

 [Raymond]: (4) Delay requirement: Due to the need for cellular codecs to
 achieve bit-rates as low as possible, they sacrificed the coding delay and
 used a 20 ms frame size, because using a 10 or 5 ms frame size would
 increase the bit-rate for a given level of speech quality.  On the other
 hand, a Bluetooth headset needs to have a low delay since its delay is
 added to the already long cell phone delay.  For the IETF codec, again it
 is up to the codec WG to decide what kind of codec delay we want, and
 again I think it makes sense to have a higher-delay, higher bit-rate
 efficiency mode for bit-rate-sensitive applications and another low-delay
 mode for delay-sensitive applications, since one size doesn't fit all.  If
 the IETF codec delay is forced to be one size, the resulting codec will be
 (potentially very) suboptimal for some applications.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/18#comment:1>
codec <http://tools.ietf.org/codec/>