Re: [codec] Suggested summary...

[Michael Knappe <[e-mail]>]

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" <[e-mail]> 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: [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