Re: [codec] Suggested summary...

[stephen botzko <[e-mail]>]

I am ok with identifying starting points for discussion.  From the thread
context it (the reference to Cullen, etc) it sounded like you were
attempting to summarize consensus.  Sorry if I misunderstood.

I understand the 256 sample size (I did the math also!), though it is
perfectly straightforward to adapt transforms to other sizes.  G.719 for
instance uses a 960 sample DCT transform for 20 ms frame size.  There are
many other examples that could be named.  I don't think the sound card
argument is all that relevant, since that is a normal place to put a buffer
anyway, and there is no reason why that buffer needs to be related to the
frame size.

Perhaps more importantly, I do not think it is appropriate to work backwards
from technology contributions to create the requirements.  The normal way in
the IETF is to work forward from use cases and problem statements.  IMHO
working forward is much more likely to get good results, and it is fair to
all (past and future) contributors.

BTW, personally I do not place a very high priority on distributed internet
music ensemble performances.  While I am ok if that happens to fall out of
the design, it possibly has a lot of other implications beyond delay.  I
would happily trade outstanding packet loss performance for music ensembles
if it came down to it, and I suspect many other VOIP folks would concur.  Is
there a more compelling  (maybe less fun) use case you can reference in the
low-delay requirement?

Stephen Botzko



2010/7/2 Christian Hoene <[e-mail]>

>  So, I am not saying that there is a consensus on the claims I made.
>
> I am just saying that this might be first starting point to discuss it
> further.
>
>
>
> To explain the figures:
>
> a)      5+1/3 ms was selected because at a sampling rate of 48000 Hz, it
> is has a size of 256 samples. 256 samples is good for sound cards and good
> for DFFT. In addition, it covers the codec contribution of Broadcom and
> Xiph.org.
>
> b)      The complexity of AMR-WB is mentioned because both the Broadcom
> and the Skype codecs are faster.
>
>
>
> If you want other figures, please bring them on the table.
>
>
>
> Christian
>
>
>
>
>
> ---------------------------------------------------------------
>
> Dr.-Ing. Christian Hoene
>
> Interactive Communication Systems (ICS), University of Tübingen
>
> Sand 13, 72076 Tübingen, Germany, Phone [phone]
>
> http://www.net.uni-tuebingen.de/
>
>
>
> *From:* Herve Taddei [mailto:[e-mail]]
> *Sent:* Friday, July 02, 2010 2:18 PM
> *To:* 'stephen botzko'; 'Christian Hoene'
> *Cc:* [e-mail]
> *Subject:* RE: [codec] Suggested summary...
>
>
>
> I think I have the same opinion as Stephen, this does not really represent
> a consensus as it never came on the table. This is exactly what I was asking
> in my email by end of May when you wrote there was consensus, what is the
> consensus?
>
>
>
> The 5 1/3 ms is quite precise, why this value? The AMR-WB codec complexity
> as reference, for which reason?
>
>
>
> Kind regards
>
>
>
> Herve Taddei
>
>
>   ------------------------------
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *stephen botzko
> *Sent:* Friday, July 02, 2010 1:14 PM
> *To:* Christian Hoene
> *Cc:* [e-mail]
> *Subject:* Re: [codec] Suggested summary...
>
>
>
> Maybe I somehow missed it, but i do not see any discussions on the list
> that support your consensus claim.  While perhaps they are reasonable
> suggestions that we can discuss further, for me consensus means that the
> specifics were expressly discussed and generally agreed.
>
> There seem to be details here that I do not find on the list.  For
> instance, a general support for a complexity ceiling of AMR-WB, and a 5 1/3
> ceiling on low-delay frame size.
>
> Regards
> Stephen Botzko
>
>  2010/7/2 Christian Hoene <[e-mail]>
>
> Hello,
>
> taking Cullen advise, I would like to suggest the following summary.
>
> > 1) low delay mode
>
> The codec shall be able to operated at a mode having an algorithmic delay
> of 8ms or less while having a frame duration of 5 1/3 ms or less. This is
> require to support ensemble performances over the Internet and other highly
> interactive conversational tasks.
>
> > 2) low complexity mode (whatever this means)
>
> The codec shall be able to operate at a low complexity mode while requiring
> less computational resources than a AMR-WB codec
> (< 38 WMOPS if measured with ITU-T STL2005 BaseOP (ITU-T G.192)).
>
> > 3) technical understanding on how latency sums up on different platforms
>
> Standard ITU-T G.114 (05/00 and 05/03) describes how different system
> components contribute to the one-way transmission delay. It states that the
> processing time of the codec contributes with an additional delay as large
> as the frame duration.
>
> However, it is common consensus that plenty computational resources will be
> available most of the time. Then, the codec processing will be much faster
> than one frame duration. Typical values are range from a factor faster of
> 100 (smart phones) to 1000 (PCs). A device working at full load is a rare
> case.
>
> Any suggestion to improve it?
>
> With best regards,
>
>  Christian
>
>
>
> ---------------------------------------------------------------
> Dr.-Ing. Christian Hoene
> Interactive Communication Systems (ICS), University of Tübingen
> Sand 13, 72076 Tübingen, Germany, Phone [phone]
> http://www.net.uni-tuebingen.de/
>
>
> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: Monday, June 21, 2010 7:21 PM
> To: Christian Hoene
> Cc: [e-mail]
> Subject: Re: [codec] #16: Multicast?
>
>
> On May 27, 2010, at 9:48 AM, Christian Hoene wrote:
>
> > So, we have consensus on
> > 1) low delay mode
> > 2) low complexity mode (whatever this means)
> > 3) technical understanding on how latency sums up on different platforms
>
> From a Chair point of view, I don't think the Chairs could summarize or
> call consensus on these three - however, I'm not sure that matters. If you
> think a key piece of consensus has come out of this conversation and that it
> needs to captured in the archive, can you summarize what you think it is
> folks agree with and then the chairs can make some sort of consensus call.
>
> Thanks, Cullen <with my chair hat on>
>  =
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>
>
>