Re: [codec] Suggested summary...

Hello Herve,

If I understand you correctly, you are not suggesting G.722.1 as reference. You just say that AMR-WB is not known as low-complexity.

So, a better wording would say

"The IWAC codec MUST be able to operate at a mode that requires less computational resources than the AMR-WB codec at 12.65 kbit/s. 
Thus, the complexity of the IWAC codec MUST be less than 38 WMOPS if measured with the ITU-T STL2005 BaseOP library."

Fine?

 Christian

-----Original Message-----
From: Herve Taddei [mailto:herve.taddei@huawei.com] 
Sent: Friday, July 02, 2010 3:17 PM
To: 'Michael Knappe'; 'stephen botzko'; 'Christian Hoene'
Cc: codec@ietf.org
Subject: RE: [codec] Suggested summary...

Hi Mike,

Actually if you ask me to name a low complexity codec (by the way at which
bandwidth?) I don't think I would name AMR-WB. G.722.1 is a good example of
a low complexity codec for WB services. 

Best regards

Herve 

> -----Original Message-----
> From: Michael Knappe [mailto:mknappe@juniper.net]
> Sent: Friday, July 02, 2010 2:54 PM
> To: Herve Taddei; 'stephen botzko'; 'Christian Hoene'
> Cc: codec@ietf.org
> Subject: Re: [codec] Suggested summary...
> 
> On codec complexity benchmarking, there is certainly industry precedence
for
> using an existing codec as a rough relative complexity guide (G.729A comes
to
> mind for narrowband codec comparisons), but some form of generalized fixed
point
> / floating point instruction count rating would hopefully be less
algorithm specific.
> Herve, Stephen, any suggestion(s) for codec complexity ratings?
> 
> Mike
> 
> 
> On 7/2/10 5:18 AM, "Herve Taddei" <herve.taddei@huawei.com> wrote:
> 
> 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: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of
> stephen botzko
> Sent: Friday, July 02, 2010 1:14 PM
> To: Christian Hoene
> Cc: codec@ietf.org
> 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 <hoene@uni-tuebingen.de>
> 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 +49 7071 2970532
> http://www.net.uni-tuebingen.de/
> 
> 
> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, June 21, 2010 7:21 PM
> To: Christian Hoene
> Cc: codec@ietf.org
> 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
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
> 