Subject: [codec] Updated codec guidelines and requirements drafts

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 07 Oct 2009 13:15:31 -0400

Hi everyone,

We just updated the guidelines and requirements drafts to take into account 
the feedback received so far. The updated drafts are at:

http://tools.ietf.org/html/draft-valin-codec-guidelines-01
http://tools.ietf.org/html/draft-valin-codec-requirements-01

Please sent comments on these drafts to the codec at ietf.org list and let 
us know if we missed anything. Let's try to get these drafts as complete as 
possible before the BoF.

Cheers,

	Jean-Marc

---

From: Alexander Chemeris <[email-masked]>
Date: Wed, 7 Oct 2009 22:30:52 +0400

Hi Jean-Marc,

Is there any IETF web-based tool for seeing differences between draft
versions?

On Wed, Oct 7, 2009 at 21:15, Jean-Marc Valin
<[email-masked]> wrote:
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Oct 2009 12:37:49 -0600

> Is there any IETF web-based tool for seeing differences between draft

You can click the "Diff" links at the top of those pages. So for instance:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-valin-codec-guidelines-01.txt
http://tools.ietf.org/rfcdiff?url2=draft-valin-codec-guidelines-01.txt

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-valin-codec-requirements-01.txt
http://tools.ietf.org/rfcdiff?url2=draft-valin-codec-requirements-01.txt

/psa

---

From: Alexander Chemeris <[email-masked]>
Date: Wed, 7 Oct 2009 23:22:03 +0400

Thanks!

On Wed, Oct 7, 2009 at 22:37, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrM3/0ACgkQNL8k5A2w/vyR1gCgnqtv3uHkHIqijYpNo26i/KLb
> Fd4AoMBc+JUWg7yJQ0vNasBuiCQhEQ61
> =YWhv
> -----END PGP SIGNATURE-----
>

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 07 Oct 2009 23:34:32 -0400

Hi David,

> Having implemented many codecs, I really like the idea of 16 bit, fixed
> point, bit exact reference implementation.  Bit exact implementations
> just make life so much easier for implementation.  

I agree that being bit-exact with the reference implementation is
probably the easiest way to port the codec and the intent wasn't to
prevent anyone from doing that.

> I can't think of any
> architectures where 16 bit/fixed point won't implement cleanly.  In many
> cases you would just need to cross-compile and you are done with a
> port. 

Probably the best example of architectures where you wouldn't want to be
bit-exact is when you want floating point code (which is faster than
fixed-point on many machines). Another example is for fractional 32x16
multiplications, for which the ITU-T has funny operators (based on older
DSPs that didn't have a signed-unsigned multiplier). I'm sure there are
other examples where you could gain performance by not being "bit-exact"
with the reference implementation.

> In other words I can't see any risk in a "bias" towards a 16 bit fixed
> point architecture.  I can however see a lot of risk allowing a "close
> enough" implementation.  Making the codec easy to implement will mean
> faster acceptance.  Get two vendors arguing over whose implementation is
> correct and the opposite will be true.
> 
> One option would be to specify the algorithm is a bit exact form, then
> allow implementers to do a "close enough" implementation if they wish.

This is exactly the intent of the drafts. In saying that close enough is
OK, it's implied that "exact" is also OK. We can probably make that
clearer. Please feel free to suggest some changes here.

> 2/ In Section 6 what does this mean
> 
>      *  Purely wireless applications will not be considered
> 
> Does it exclude Wifi?  Maybe an example would clarify.....

Wifi is definitely within the scope here. I agree that "purely wireless"
is not a great description. My personal view (we haven't discussed this
in great details) is that we would rule out applications such as ham
radio and cell phones (unless you're doing VoIP on that mobile), but
include "IP over wireless links". Again, a better wording would be
welcome if anyone can suggest one.

> 3/ Section 2.1:
> 
>         Also, the codec should be robust to noise (produce intelligible
>         speech) even at lower bit-rates.
>        
> I suggest tightening this a bit to something similar to the requirement
> for music "the codec should be robust to noise (produce intelligible
> speech and no annoying artifacts) even at lower bit-rates."  

You mean you would like to add "and no annoying artifacts" to the text?

> We will
> also need a way to measure this, e.g. samples corrupted by various noise
> sources.  Samples with periodic background noise (like a vehicle engine)
> can be challenging.

Agreed.

> 4/ Section 2.2:
> 
> Some great ideas in this section, but I suggest changing:
>         To make it easier to determine which streams have to be mixed
>         (and which are noise/silence), it must be possible to measure
>         (or estimate) the level of the audio in a packet
> to:
>         To make it easier to determine which streams have to be mixed (and
>         which are noise/silence), it must be possible to measure (or estimate)
>         voice activity
> 
> By voice activity I mean a bit or test that says "this packet is not just
> background noise".

Agreed that we can be more precise here. VAD without decode was really
the intent, though I'm thinking that the information could be useful for
other purposes as well.

> 5/ Section 2.2:
> 
> I challenge the need for special low-delay requirements, e.g. 10ms.  My
> ping time to the US west coast is 300ms, so any Internet codec delays
> will be trivial compared to the propagation time of the packet.  I guess
> it could make a difference if you are having a teleconference between
> two east-coast US cities, but the Internet is a big place......

The Internet is indeed a big place and the dalays can vary a lot. That
being said, there are many cases where you are communicating either in
the same city, or to a nearby city. I have standard cable connection and
my ping time (that I just measured non-scientifically) is around 10 ms
within the city and 12 ms to Sherbrooke (200 km away). In thoses cases,
a low-delay codec *can* make a difference on the perceptibility of
acoustic echo. That being said, the intent is to make sure not to
penalise the people who do not need this (e.g. making calls from AU to US).

> 6/ Section 2.6, these are interesting apps but how much special effort
> (e.g. a very tight delay requirement) do we want to put in for such a
> rare use of the codec?  I guess if we get the low delay "for free" it's
> OK.  Or am I missing something and live music etc are likely to be a
> major future use of the codec?

Well, the intend is to get this mostly for free. This could either be
through defining a low-delay mode for the codec (if possible), or by
creating a separate codec. All these requirements do not have to be
fulfilled by a single codec (though of course we don't want one codec
per application).

> Most (>99%?) of today's music apps are delay insensitive, e.g.
> streaming.

Keep in mind that a codec that we are developing now would (if
successful) likely still be in use in 10 years, so we need to look into
the future.

> Perhaps I am suggesting that requirements be weighted in proportion to
> projected use, for example applications 2.1, 2,2, and 2.5 would probably
> cover 99% of all instances of the codec.

See above. Let me restate that the intent is not to penalise the "high"
delay case at all.

> 7/ Section 3 (e.g. discussion of prediction etc) reads like suggestions
> for implementation rather than a requirements document.  They are good
> suggestions BTW, but a requirement is more like (x % degradation under a
> y % packet error rate, or x ms to resynchronise).  If some one achieves
> that in an unexpected way we don't really care.

Section 3 is mostly meant to explain how the Internet impacts the
requirements of the next section.

> 8/ Section 3.1.  Paragraph 1: The worst case CPU should be specified as
> a number.

This part of the complexity discussion is only about security (i.e.
making sure we don't get exposed to DoS). I'm not sure what's the best
way to quantify this. Obviously, if the worst case is 100x more complex
than the average, it's not good, but where exactly would you put the limit?

> 8/ Section 4.2.  g729 should be one of the reference codecs as it is
> ubiquitous on today's Internet.  This new codec will be it's likely
> successor. We should aim for a codec that is >= g729 and IPR free.

I don't actually think g729 is really what we want to target. We are
mostly looking at a wideband codec, with narrowband being mostly useful
for "legacy compatibility". Even the 8 kbps bit-rate isn't that useful
considering that we're usually sending 16 kbps worth of headers (RTP
with 20 ms packetization time). Also, G.729 is not exactly what I would
describe as an easily distributable audio codec.

Cheers,

	Jean-Marc

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Oct 2009 14:39:12 -0600

> welcome if anyone can suggest one.

How about this?

"Wireless applications that do not communicate over the Internet
Protocol (e.g., radio) will not be considered"

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 16 Oct 2009 16:44:33 -0400

> Protocol (e.g., radio) will not be considered"

I think that's a very good way to put it.

    Jean-Marc