Re: [codec] Format for the codec specification

[Stephan Wenger <[e-mail]>]

Hi all, especially Jean-Marc and Stephen,

I think you are both thinking too technical on this question.  My
understanding is that the speech codecs from the ITU and from 3GPP and 3GPP2
are/have been mostly telco driven developments.  In many legislations,
Telcos have to offer their customers a guaranteed quality level.  It is
easier for them to ensure that level to be achieved by disallowing vendor
differentiation in quality.

Personally, I believe that a codec targeted for a best effort network is
best designed without a strict encoder specification.

That said, I continue to argue that we will be better off with a bit-exact
decoder design.  Again, the reason is not technical, but (patent-) licensing
related.  While it is comparatively easy, in a bit-exact decoder design, to
determine whether a given patent claim is essential to practice the
standard, this is not the case for a design that is based on bitstream
syntax, aspects of the decoder operation, and minimum performance
requirements (which, I believe, is roughly where some people are heading).

Note that it is even more important for a royalty-free codec development to
have a clear understanding about which claims are essential, than for a RAND
codec.  The reason is simple: in the RF case, the development has to stay
clear of any and all claims that may not be available under "exotic" (in
this industry) RF terms, whereas for a RAND codec, people only have to worry
about the inclusion of claims that may not be available for RAND licensing
at all (which are very few in this industry).  As a result, a non bit-exact
decoder design has to be much more conservative in exercising technology (as
more claims may be swept in by advanced designs) than a bit exact decoder
design, neutralizing, IMO, most of the positive effects a non bit-exact
design may have from a performance viewpoint.

In summary, I continue to argue in favor of the MPEG model: (bit-exactly)
standardize the bitstream and the decoder operation on it.

A test-model level encoder design document is desirable as well, as could be
minimum performance specs for the encoder, but, IMO, neither need to be
normative.

Regards,
Stephan





On 9.28.2010 19:46 , "Jean-Marc Valin" <[e-mail]>
wrote:

> On 10-09-28 10:28 PM, Stephen Botzko wrote:
>> Though I've never heard clear reasons, it seems to me that the
>> "decoder-only" folks are mostly focused on applications with a massive
>> encoder/decoder imbalance, while the "encoder and decoder" folks tend to
>> be focused on applications with equal numbers of encoder and decoders.
> 
> I think the main logic here is that when your codec leaves very few
> degrees of freedom to the encoder (the extreme case being an ADPCM
> codec, but CELP generally falls into that as well), then it's fine to
> have the encoder being normative. Voice codecs have typically fallen
> into that category because they were smaller than music codecs. Where I
> think it makes sense to *not* have a normative encoder is when the
> encoder has a lot of freedom. For example, an MP3 encoder has the
> freedom to define it's own psycho acoustic model, decide when to use
> short windows, and so on. And we have seen just how much MP3 encoders
> have improved over the years. This would have been impossible if the
> encoder had been specified normatively.
> 
> I would say that the current codec we have here is closer to MP3 than it
> is to (e.g.) G.729. There is a *lot* of freedom in the encoder. Not only
> in how to switch between its three main modes (SILK, CELT, hybrid), but
> within each of these modes. Because of that, I believe that encoders
> will continue to evolve and get better over time, just like they did for
> MP3.
> 
>> So I am thinking that making the encoder normative makes sense, given
>> that this application is centered on VOIP, so we want to ensure
>> consistent quality in all endpoints.
> 
> I don't really see a problem with quality. Most implementors will likely
> end up using either the reference encoder, or improvement that got made
> over time. I don't think anyone will complain with having better quality
> than the standard specified.
> 
> Cheers,
> 
> Jean-Marc
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec