Subject: Re: [codec] Suggested summary...

From: Michael Knappe <[email-masked]>
Date: Fri, 2 Jul 2010 08:22:18 -0700

Herve,

I wasn't specifically suggesting AMR-WB (that came from Christian's email). I was simply saying that popular named codecs are often used as informal benchmarks by the industry at large.

Mike

----- Original Message -----
From: Herve Taddei <[email-masked]>
To: Michael Knappe; 'stephen botzko' <[email-masked]>; 'Christian Hoene' <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Fri Jul 02 09:16:47 2010
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:[email-masked]]
> Sent: Friday, July 02, 2010 2:54 PM
> To: Herve Taddei; 'stephen botzko'; 'Christian Hoene'
> Cc: [email-masked]
> 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" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> stephen botzko
> Sent: Friday, July 02, 2010 1:14 PM
> To: Christian Hoene
> Cc: [email-masked]
> 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 <[email-masked]>
> 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:[email-masked]]
> Sent: Monday, June 21, 2010 7:21 PM
> To: Christian Hoene
> Cc: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: Herve Taddei <[email-masked]>
Date: Fri, 02 Jul 2010 17:52:54 +0200

Codecs as G.722 (10 MIPS), G.722.1 (about 5 WMOPS), G.722.1C (about 11
WMOPS) and G.719 (about 21 WMOPS) are usually considered as low complexity
codecs for WB, SWB and FB bandwidths. 

Other codecs as G.711 and its newly extensions have also very low complexity
versions with G.711.0 (less than 2 WMOPS), G.711.1 (about 9 WMOPS) and very
soon G.722/G.711.1 SWB.

So 38 WMOPS is not really in the range of low complexity.

Herve Taddei

> Sent: Friday, July 02, 2010 5:22 PM
> To: [email-masked]; [email-masked]; hoene@uni-
> tuebingen.de
> Cc: [email-masked]
> I wasn't specifically suggesting AMR-WB (that came from Christian's
email). I was
> simply saying that popular named codecs are often used as informal
benchmarks
> by the industry at large.
> 
> Mike
> 
> To: Michael Knappe; 'stephen botzko' <[email-masked]>;
'Christian
> Hoene' <[email-masked]>