Re: [codec] possible issues to track

[Michael Knappe <[e-mail]>]

Thanks Jean-Marc, guess I misunderstood your preference on joint coding
during our discussion, thanks Ben for calling that out.

So, in putting together our 'must-have' vs 'nice-to-have' requirements list,
we'll put joint coding down as a 'nice-to-have'?

Mike


On 3/25/10 3:19 PM, "Jean-Marc Valin" <[e-mail]> wrote:

> Michael Knappe wrote:
>>> - clarify requirement about bit-exactness
>> [MEK] we will need to specify whether our final reference code is fully bit
>> exact, or whether some or all elements can be bit compatible. We should also
>> specify whether any portions of said algorithms could be 'upgradeable' (e.g.
>> Having a stock PLC algorithm that could be replaced with a better PLC in the
>> future)
> 
> There is already some text addressing that, but it's part of the guidelines
> rather than the requirements. I guess it's possible to move it to the
> requirements, but I'm undecided as to whether it's a good idea or not.
> See section 4 of the guidelines draft: "Requirements Conformance" in
> http://tools.ietf.org/html/draft-valin-codec-guidelines-04
> 
> It addresses bit-exactness, PLC, future improvements, ... Let me know what
> you think.
> 
>>> - mention DTMF in requirements
>> [MEK] some simple talk-off tests should be done to determine if in-band DTMF
>> (and potentially other call progress tones) are carried in-band without
>> sufficient degradation as to cause a DTMF detector misread.
> 
> Definitely agree here; that was an omission from the current draft. More
> precisely, we should probably select a minimum bit-rate after which DTMF
> should be handled. I'm not sure we want to mandate that DTMF work down to 6
> kb/s, but at 20 kb/s it should definitely work. Where we put the bar is an
> open question.
> 
>> - multi-channel carriage: not sure if we mentioned this during the WG
>> session, but we need to decide if we will support any kind of joint channel
>> coding (current consensus so far is to keep all channels separable). We also
>> should also reference multi-channel packing within RTP (RFC 3551 sec 4.1).
> 
> Well, any codec always has the option of doing independent channels
> (provided that the RTP payload format supports it). On top of that, I tend
> to think that "joint coding" is a nice-to-have feature -- as long as it
> improves the coding efficiency of course.
> 
> Cheers,
> 
> Jean-Marc