Subject: [codec] Format for the codec specification

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Sep 2010 15:09:11 -0400

One of the open issues we need to close on - and document in the 
guidelines specification - is what the format of our codec specification 
deliverable will be.

Firstly - one thing is clear - whatever the format is (code or textual 
descriptions) - it needs to be in an RFC. Including source code into an 
RFC is not ideal, but for purposes of IETF process that is the only 
thing we can officially produce. Participants can of course place that 
code in any repository they like, and we can even include a link to it 
in the RFC. However, the formal normative specification of the codec 
must be within a standards track RFC.

In terms of whether the specification is code, text, or both - we need 
to gain consensus on this. It is my understanding that source code is 
ultimately the most exact way to specify the codec. A detailed 
description is also included, and in case of conflict, the code would 
win. In IETF terms this means that the code is actually the normative 
specification.

iLBC includes the code itself in an appendix. As such, it would seem to 
make sense to follow this precedent. Thus, our deliverable would be a 
single document, containing a reasonably detailed codec description, 
along with an appendix containing the actual code.

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    Mobile: +1 (732) 766-2496
Skype                                          SkypeIn: +1 (408) 465-0361
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 24 Sep 2010 14:13:45 -0500

> along with an appendix containing the actual code.

This makes sense to me; my only reservation would be that we can't allow
the situation with iLBC licensing to exist with this codec. Even though
the iLBC source code is present in the RFC, usage of it is covered by
license agreements with GIPS, in spite of the fact that the code in the
RFC contains no copyright statements by or other references to GIPS.
It's murky and inconvenient, so let's not let that happen again :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 24 Sep 2010 12:33:45 -0700

I also think we should make the code normative, as the speech codec people
commonly do for their bit-exact encoder/decoder specs.  However, someone
will have to explain to me how this can be done without requiring
bit-exactness.

If we were deciding to use code as the normative description, then I would
prefer to have that code ONLY in a single document.  It may be worthwhile to
consider zipping the source code directory, coding it in BASE64, and then
copy-pasting it into the RFC.  This way we could overcome many of the
shortcomings of putting a large software project into a printout format.  We
should check with the AD and the RFC editor first, how they view such a
submission.

Finally, it should be clear that the code RFC (as all RFCs) falls under the
IETF's copyright and patent policies.  As for the copyright part, people
should be aware that the IETF does not allow any other copyright notices but
its own in such an RFC.  In other words, if the code maintainers want to
make the code available also under a non-IETF license (one of the open
source licenses, for example), they a) have to make sure that this license
allows for such dual licensing (GPL, for example, does IMO not), and b)
remove the statements of this license from the code provided to the IETF,
and c) (depending on that license) remove the IETF license text from the
code provided to the open source repository.  Tedious, but doable, I think.

Stephan

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 24 Sep 2010 16:37:56 -0400

> will have to explain to me how this can be done without requiring

There is no need to mandate bit-exactness. Many codecs are actually 
specified in floating-point. For example, if I'm not mistaken, the 
following codecs have a floating-point reference: MP3, EVRC-A/B, G.719 
(probably others). As far as I know, the spec says how much you can 
deviate from the float reference (not to mention that it's impossible to 
always be bit-exact with a float reference in the first place).

> should check with the AD and the RFC editor first, how they view such a

I'm not against base64 encoding if the IETF will allow it. We could even 
have a C version of the base64 decoder to make sure that the RFC is 
"self-contained".

> allows for such dual licensing (GPL, for example, does IMO not),

The BSD license is compatible with the GPL, which means that it is OK, 
to take BSD code, modify it, and then slap a GPL license on top of the 
modified version (without removing the existing BSD license). In 
general, there are many cases of dual licensing involving the GPL. Also, 
note that the code we're talking about has been available under the BSD 
(and not the GPL) right from the start.

	Jean-Marc

> and b)
> On 9.24.2010 12:09 , "Jonathan Rosenberg"<[email-masked]>  wrote:
>
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 24 Sep 2010 14:42:44 -0600

> (and not the GPL) right from the start.

Right, the current IETF copyright notices states:

   Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

So IMHO there's no need to jump through any hoops here.

Peter

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

---

From: "Roni Even" <[email-masked]>
Date: Sat, 25 Sep 2010 00:06:56 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jean-Marc Valin
> Sent: Friday, September 24, 2010 10:38 PM
> To: Stephan Wenger
> Cc: [email-masked]
> Subject: Re: [codec] Format for the codec specification
> 

Section 6.5 from ITU-T G.719

6.5 Description of the codec
The description of the coding algorithm of this Recommendation is made in
terms of bit-exact
fixed-point mathematical operations. The ANSI-C code indicated in clause 10,
which constitutes an
integral part of this Recommendation, reflects this bit-exact, fixed-point
descriptive approach. The
mathematical descriptions of the encoder and decoder can be implemented in
other fashions,
possibly leading to a codec implementation which does not comply with this
Recommendation.
Therefore, the algorithm description of the ANSI-C code of clause 10 shall
take precedence over the
mathematical descriptions whenever discrepancies are found. A set of test
signals, which can be
used together with the ANSI-C code in order to verify bit-exactness, is
available as an electronic
attachment to this Recommendation.

Roni Even

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 24 Sep 2010 19:21:44 -0400

Hi Roni,

Thanks for the correction on the case of G.719. Despite that, my point 
still stands: there *are* codecs for which the decoder is standardized 
without a bit-exact definition. As long as we define the amount of 
deviation permitted, then there is no problem.

Oh, and I do agree that the C code should take precedence over the 
mathematical description.

Cheers,

	Jean-Marc

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 24 Sep 2010 17:52:38 -0700

I forgot that you are currently working under the BSD license.  Keep it that
way, and I have no concerns on the licensing front, as IETF code components
are under essentially the same license.
Stephan

---

From: Riccardo Bernardini <[email-masked]>
Date: Sat, 25 Sep 2010 10:55:23 +0200

Quoting Jean-Marc Valin <[email-masked]>:

> Hi Roni,
>
> Thanks for the correction on the case of G.719. Despite that, my  
> point still stands: there *are* codecs for which the decoder is  
> standardized without a bit-exact definition. As long as we define  
> the amount of deviation permitted, then there is no problem.
>

A question just came to my mind: what about bugs in the C code?   
Suppose, for example, that the algorithm requires the computation of a  
DCT of a block of samples and that there is some typo in the constants  
used in the C code, so that what the C code computes is not the DCT,  
but something similar and the difference is such that it really does  
not matter in most cases, but causes very bad performances (when  
compared with theoretical description) in others.  In this case, the  
precedence would go to the "wrong" description.

I agree that the example above is somehow  weak (I just invented it  
"on the spot"), but I hope that spirit is clear: it could happen that  
despite of all attention we could pay, some subtle but important bugs  
could find their way to the C code.  Also I agree that we can always  
publish an errata or an RFC that obsolete the old one.

Another doubt about having a C code as a normative reference: could  
portability issues make the code "ambiguous"?  For example, a code  
could use the assumption that int is _exactly_ 32 bits long and short  
is _exactly_ 16 bits.  If the same code is run on a processor that  
uses, say, 64 bits for int and 32 for shorts, maybe the results could  
be different.  Of course, you can solve this _specific_ issue by  
including stdint.h (not available everywhere, though) and using types  
like int16_t, but what I want to point out is that we must pay  
attention to this type of portability issues, if we want the meaning  
of the C code being non-ambiguous.  Another example, much more subtle,  
could be

   int foo[3];
   int goo, foo=3;
   int *pt;

   pt  = (int*) foo;
   goo = (int) pt;  /* Is really pt==foo? */

As far as I know (but I am not a C language-lawyer), the standard  
grants that conversion pointer-to-integer-to-pointer will give the  
original pointer back, but nothing is said about the case above  
(imagine an architecture where addresses can be only even).  Although  
the code above would work on a typical x86 architecture, I would not  
use it in a code that should play the role of a reference.

By the way, I agree that the code above is quite silly, but I seen  
things like this used, for example, in multi-thread applications where  
the programmer wanted to pass an integer by using a function that  
expected a pointer.

What about using some other language with less portability issues,  
such as Ada or Java?  Better yet, some language with a semantic  
formally defined? (I do not know any, but maybe someone does)

[Oh, by the way, I *do not want* to start a flame war about which  
language to use.  Rather than fighting over it, I would go with C.  I  
just wanted to share with you some doubts of mine.]

Although I agree that errors and ambiguities could creep in the  
mathematical description, maybe it is easier to write a correct and  
unambiguous mathematical description rather than a program code (in  
whatever language is written).

-- 
Riccardo Bernardini
DIEGM -- University of Udine
via delle Scienze 208
33100 Udine
Tel: +39-0432-55-8271
Fax: +39-0432-55-8251

----------------------------------------------------------------------
SEMEL (SErvizio di Messaging ELettronico) - CSIT -Universita' di Udine

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 25 Sep 2010 10:23:38 -0400

On 10-09-25 04:55 AM, Riccardo Bernardini wrote:
> A question just came to my mind: what about bugs in the C code? Suppose,
> for example, that the algorithm requires the computation of a DCT of a
> block of samples and that there is some typo in the constants used in
> the C code, so that what the C code computes is not the DCT, but
> something similar and the difference is such that it really does not
> matter in most cases, but causes very bad performances (when compared
> with theoretical description) in others. In this case, the precedence
> would go to the "wrong" description.

Judging from the bugs I have had in CELT over the development, these 
tend to be a lot more subtle than what you describe above, like corner 
cases that likely would not be covered by the text description either. 
In any case, should an error be found in the source code, the best would 
be to simply publish an updated version.

> portability issues make the code "ambiguous"? For example, a code could
> use the assumption that int is _exactly_ 32 bits long and short is
> _exactly_ 16 bits. If the same code is run on a processor that uses,
> say, 64 bits for int and 32 for shorts, maybe the results could be
> different. Of course, you can solve this _specific_ issue by including
> stdint.h (not available everywhere, though) and using types like
> int16_t, but what I want to point out is that we must pay attention to
> this type of portability issues, if we want the meaning of the C code
> being non-ambiguous. Another example, much more subtle, could be

That's already how the CELT and SILK source code are written. There are 
typedefs for integers with exactly 16 bits or exactly 32 bits.

> As far as I know (but I am not a C language-lawyer), the standard grants
> that conversion pointer-to-integer-to-pointer will give the original
> pointer back, but nothing is said about the case above (imagine an
> architecture where addresses can be only even). Although the code above
> would work on a typical x86 architecture, I would not use it in a code
> that should play the role of a reference.

Assuming that pointers can be stored in integers is bad and we just have 
to make sure not to have any of that in the reference source code. 
There's no need for it in a codec anyway.

> whatever language is written).

Quite the other way around. Writing a correct and unambiguous 
mathematical description for thousands of line of code is nearly 
impossible. Either you write it in plain English and get all the 
ambiguities of natural language, or you write *everything* with 
equations, in which case what you have is the equivalent of pseudo-code. 
Also, a C reference has the advantage that you can verify it simply by 
compiling it.

Cheers,

	Jean-Marc

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 25 Sep 2010 15:52:14 -0400

On Sep 24, 2010, at 4:37 PM, Jean-Marc Valin wrote:

> There is no need to mandate bit-exactness. Many codecs are actually specified in floating-point. For example, if I'm not mistaken, the following codecs have a floating-point reference: MP3, EVRC-A/B, G.719 (probably others). As far as I know, the spec says how much you can deviate from the float reference (not to mention that it's impossible to always be bit-exact with a float reference in the first place).
> 
> I'm not against base64 encoding if the IETF will allow it. We could even have a C version of the base64 decoder to make sure that the RFC is "self-contained".
> 
>> IETF's copyright and patent policies.

Correct.

>>  As for the copyright part, people
>> its own in such an RFC.

Correct

>>  In other words, if the code maintainers want to
> The BSD license is compatible with the GPL, which means that it is OK, to take BSD code, modify it, and then slap a GPL license on top of the modified version (without removing the existing BSD license). In general, there are many cases of dual licensing involving the GPL. Also, note that the code we're talking about has been available under the BSD (and not the GPL) right from the start.

You are certainly free to do that on your own, but under the current Trust Legal Provisions

http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf

the code on published RFCs has to have the BSD license.

Regards
Marshall

---

From: Jonas Svedberg <[email-masked]>
Date: Tue, 28 Sep 2010 15:00:47 +0200

Hi all

 If I understand Marshall's point correctly, the Trust Legal Provisions indicates something regarding publishing,   which is not completely clear in the current guidelines draft.

In the proposed guidelines <http://www.ietf.org/id/draft-valin-codec-guidelines-06.txt> page 10, it is now stated:

"  5.  In accordance with BCP 78 [TRUST], the source code for the
       reference implementation must be made available under a BSD-style
       license (or whatever license is defined as acceptable by the IETF
       Trust when the Internet-Draft defining the reference
       implementation is published)."

To me it seems as the final point Marshall made:
   "the code on published RFCs has to have the BSD license."

,is a clearer and stricter wording than what is present in the current proposed guidelines, which uses the looser term "BSD-style", and further leaves other options open (in the parenthesis), and therefore makes the publishing directions in the guidelines quite unclear, to the developers. 
 
With this observation in mind it seems as the Guidelines publishing related section should be updated. 

--
 
With regard to  formats and publishing in general, 
  is there any precedence in IETF of having, the WG output split into several entities/specs ? 
   (e.g sending side/receiving side or impl.A-fix/impl.B-Float)  

   e.g. One could imagine having the receiving side definitions specified in one RFC, and the sending side definitions as another RFC, 
   or even leave the sending side unspecified within IETF(e.g. as  a separate open source project, which would then mainly take care of sending side code maintenance, assuming that maintenance issues on the sending side are much more frequent than on the receiving side).  

//BR Jonas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
Sent: den 25 september 2010 21:52
To: Jean-Marc Valin
Cc: [email-masked]
Subject: Re: [codec] Format for the codec specification

On Sep 24, 2010, at 4:37 PM, Jean-Marc Valin wrote:

>> I also think we should make the code normative, as the speech codec 
>> people commonly do for their bit-exact encoder/decoder specs.  
>> However, someone will have to explain to me how this can be done 
>> without requiring bit-exactness.
> 
>> If we were deciding to use code as the normative description, then I 
>> would prefer to have that code ONLY in a single document.  It may be 
>> worthwhile to consider zipping the source code directory, coding it 
>> in BASE64, and then copy-pasting it into the RFC.  This way we could 
>> overcome many of the shortcomings of putting a large software project 
>> into a printout format.  We should check with the AD and the RFC 
>> editor first, how they view such a submission.
> 
>> Finally, it should be clear that the code RFC (as all RFCs) falls 
>> under the IETF's copyright and patent policies.

Correct.

>> should be aware that the IETF does not allow any other copyright 
>> notices but its own in such an RFC.

Correct

>>  In other words, if the code maintainers want to make the code 
>> available also under a non-IETF license (one of the open source 
>> licenses, for example), they a) have to make sure that this license 

Regards
Marshall

> 
> 	Jean-Marc
> 
>> and b)
>> remove the statements of this license from the code provided to the 
>> IETF, and c) (depending on that license) remove the IETF license text 
>> from the code provided to the open source repository.  Tedious, but doable, I think.
>> 
>> Stephan
>> 
>> 
>> 
>> 
>> 
>> 
>>> guidelines specification - is what the format of our codec 
>>> specification deliverable will be.
>>> 
>>> descriptions) - it needs to be in an RFC. Including source code into 
>>> an RFC is not ideal, but for purposes of IETF process that is the 
>>> only thing we can officially produce. Participants can of course 
>>> place that code in any repository they like, and we can even include 
>>> a link to it in the RFC. However, the formal normative specification 
>>> of the codec must be within a standards track RFC.
>>> 
>>> In terms of whether the specification is code, text, or both - we 
>>> need to gain consensus on this. It is my understanding that source 
>>> code is ultimately the most exact way to specify the codec. A 
>>> detailed description is also included, and in case of conflict, the 
>>> code would win. In IETF terms this means that the code is actually 
>>> the normative specification.
>>> 
>>> iLBC includes the code itself in an appendix. As such, it would seem 
>>> to make sense to follow this precedent. Thus, our deliverable would 
>>> be a single document, containing a reasonably detailed codec 
>>> description, along with an appendix containing the actual code.
>>> 
>>> Comments?
>>> 
>>> -Jonathan R.
>> 
>>

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 28 Sep 2010 20:51:57 -0400

On 10-09-28 09:00 AM, Jonas Svedberg wrote:
> Trust when the Internet-Draft defining the reference implementation
> is published)."
>
> To me it seems as the final point Marshall made: "the code on
> published RFCs has to have the BSD license."
>
> ,is a clearer and stricter wording than what is present in the
> current proposed guidelines, which uses the looser term "BSD-style",
> and further leaves other options open (in the parenthesis), and
> therefore makes the publishing directions in the guidelines quite
> unclear, to the developers.

I believe the current wording is based on Stephen Wenger's argument 
about "what if BCP78 were to specify a different license?" I don't have 
a strong opinion on this detail, you two can sort this out :-)

> With regard to  formats and publishing in general, is there any
> precedence in IETF of having, the WG output split into several
> entities/specs ? (e.g sending side/receiving side or
> impl.A-fix/impl.B-Float)
>
> e.g. One could imagine having the receiving side definitions
> specified in one RFC, and the sending side definitions as another
> RFC, or even leave the sending side unspecified within IETF(e.g. as
> a separate open source project, which would then mainly take care of
> sending side code maintenance, assuming that maintenance issues on
> the sending side are much more frequent than on the receiving side).

Normally, the decoder should be normative, which the encoder should not 
be. Technically, the RFC could contain only the decoder, though 
practically we need an encoder reference implementation. Since the 
encoder would likely not be normative, it would probably not be 
necessary to update the RFC for encoder-side improvements and the 
decoder is unlikely to change too much. Also, note that there's quite a 
bit of code that is shared between the encoder and decoder, fixed-point 
and floating point, so it would seem logical/simpler to have a single 
document here. But again, I don't have a strong opinion at this point.

Cheers,

	Jean-Marc

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 28 Sep 2010 22:28:21 -0400

be.
I think this is an assumption on your part.  Some groups in other SDOs make
the encoder normative as well.

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.  That
seems logical, since if there are relatively few encoders, it is easier to
solve any quality problems, and the content providers have very strong
financial incentives to do so.

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.

Regards
Stephen Botzko

On Tue, Sep 28, 2010 at 8:51 PM, Jean-Marc Valin <
[email-masked]> wrote:

> I believe the current wording is based on Stephen Wenger's argument about
> "what if BCP78 were to specify a different license?" I don't have a strong
> opinion on this detail, you two can sort this out :-)
>
>
> Normally, the decoder should be normative, which the encoder should not be.
> Technically, the RFC could contain only the decoder, though practically we
> need an encoder reference implementation. Since the encoder would likely not
> be normative, it would probably not be necessary to update the RFC for
> encoder-side improvements and the decoder is unlikely to change too much.
> Also, note that there's quite a bit of code that is shared between the
> encoder and decoder, fixed-point and floating point, so it would seem
> logical/simpler to have a single document here. But again, I don't have a
> strong opinion at this point.
>
> Cheers,
>
>        Jean-Marc
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 28 Sep 2010 22:46:00 -0400

On 10-09-28 10:28 PM, Stephen Botzko wrote:
> 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

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 28 Sep 2010 22:03:55 -0700

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

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 29 Sep 2010 06:56:03 -0400

Hi Stephen,

> standardize the bitstream and the decoder operation on it.

Actually, to the best of my knowledge, MPEG does *not* specify the 
decoder in a bit-exact way. IIRC the spec has a floating-point decoder 
and then says by how much the output is allowed to deviate from the 
reference decoder. The same strategy is used in EVRB (A and B). This 
makes sense. Otherwise, we can argue for years over how exactly to 
define a multiplication (e.g. whether to round and how) because there's 
about a dozen different ways you can define some of these basic operations.

	Jean-Marc

On 10-09-29 01:03 AM, Stephan Wenger wrote:
> On 9.28.2010 19:46 , "Jean-Marc Valin"<[email-masked]>
> wrote:
>

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Wed, 29 Sep 2010 10:04:42 -0400

On 09/29/2010 01:03 AM, Stephan Wenger wrote:
>  As a result, a non bit-exact

Surely the converse logic also applies.  A non-bitexact decoder can more
easily be modified to dodge any unexpected patent claims brought against
it, because its designers are not restricted to alterations that do not
affect the output.

Personally, I favor the following:  We should produce a fixed-point
reference decoder, specified bit-exactly in code and text.  We should
indicate that implementors who require a guaranteed level of service
should follow this bit-exact specification.  We should _not_ set any
limits on the deviation of other decoders from this bit-exact specification.

Reasoning:
We should provide a bit-exact decoder specification because otherwise it
is unclear how to optimize the encoder later.

A codec with no licensing restrictions has no gatekeeper, so any
restrictions on performance would be unenforceable in practice.  The lack
of restrictions also means that the codec can easily be extremely widely
implemented, enabling commodity competition between different
implementors.  Competition can keep quality high.

Large single-vendor deployments, without internal competition, are likely
to have a contractually required level of service, in which case the RFC
would direct the implementor to remain bit-exact.

One option we have would be to specify the decoder under two different
names: "$CODEC" and "Bit-Exact $CODEC".

--Ben