Subject: Re: [codec] Comments on draft-valin-codec-guidelines-05.txt

From: Michael Knappe <[email-masked]>
Date: Fri, 10 Sep 2010 08:51:47 -0700

Everyone,

If you haven't already, please review Jean-Marc's latest version of the
guidelines (draft-valin-codec-guidelines-06) which can be found at:

http://datatracker.ietf.org/doc/draft-valin-codec-guidelines/

Please reply to the mailing list with any comments you have on this
iteration, let's get this one ready to bring in as a WG -00.

Cheers,

Mike

On 8/24/10 3:06 PM, "Jean-Marc Valin" <[email-masked]> wrote:

> Hi Stephen, everyone,
> 
> On 10-08-24 02:39 PM, Stephan Wenger wrote:
>>> These were the subject of some debate at the previous meeting, so I'm
>>> not addressing it right now.
>> 
>> That's fine and the right approach.  However, I believe we need to come to a
>> consensus of some form of a working assumption for all three questions
>> before it makes sense to accept the draft as a WG document.
> 
> We need consensus on everything before going to WGLC, but I don't see why
> we need it for having this as a WG item.
> 
>> Here, and also later, I use the term "technology draft" or "technology RFC"
>> for the textual description of the final codec; it's called "Specification
>> of a codec" in the charter.  The charter currently does not reflect directly
>> the (perceived?) need for a permanent document covering the reference
>> implementation.  I'm in favor of such a document (std track or informational
>> RFC), and I'm in favor of putting the code into its own, code-only document
>> and not into a section of the specification RFC, for size reasons (one never
>> knows--perhaps there will be a FPO and an integer reference implementation
>> at some point, or more than one specifictaion covering different operation
>> points, and so on).
> 
> We definitely need a place to put the reference implementation. I also
> agree that having the entire code in the appendix of an RFC is a bit
> inconvenient. Now the question is where should that code live? Does the
> IETF have a more convenient way to hold source code than 72-column ASCII?
> Any suggestion on where to put the reference implementation? There's also
> the question of what the reference implementation should look like. Should
> it be just floating point, just fixed-point, both? Should it be reasonably
> optimised (without anything platform-specific) or should the code be
> optimised for readability rather than speed?
> 
>>>>    14. 4. Requirements..., third paragraph, ³normative². ³normative
>>>>        requirements² is wrong here. What we are talking here are neither
>>>>        requirements, nor are they normative. Tightening up the language
>>>>        is left an an exercise to the reader. :-)
>>> 
>>> I'm talking about minimizing the number of MUSTs required to be
>>> compliant with the standard. How would you phrase that?
>> 
>> Perhaps out of content, but that is what I think we could say: "It is the
>> intention of the group to allow the greatest possible choice of freedom in
>> implementing the specification.  Accordingly, the number of binding RFC2119
>> keywords is going to be the minimum still allowing for interopable
>> implementations."
> 
> Thanks for the suggestion. I've added it as is.
> 
>> You know that you are binding your hands with such a formulation?  In a
>> highly contested area, all kinds of political compromises end up in deals
>> such as "if you MUST implement my patent, then I MUST implement yours" and
>> so on.  (Although the opposite case--removing MUST requirements in favor of
>> unmotivated SHOULD or MAY is much more the norm.)
> 
> The reasoning for having as little binding keywords is mainly technical. It
> will allow future encoders to produce better quality audio than what the
> reference encoder will do. MP3 is a good example of that. Current encoders
> are *much* better than the original ones (which were already much better
> than the really bad reference implementation).
> 
>>> 
>>>>    15. 4. Requirements..., fourth paragraph: I don¹t think we have
>>>>        consensus re bit-exact decoders (or lack thereof). There is a
>>>>        whole can of licensing worms attached to non-bit-exact decoders.
>>>>        Suggest to strike this paragraph, or, at least, document the lack
>>>>        of WG consensus before accepting this as WG item (alternatively,
>>>>        force consensus now, but I don¹t think all the facts are on the
>>>>        table and sufficiently discussed yet).
>>> 
>>> IIRC most WG participants agreed that we didn't need to "force"
>>> implementers to be bit-exact as long as they had bit-exactness as an
>>> option to simplify implementation. After all, forcing bit exactness
>>> means one can never use floating-point.
>> 
>> Up to the chairs to make a consensus call.
> 
> Well, that's in the minutes anyway. I remember people saying that
> bit-exactness can be *useful* and I agree. The current text just says that
> that you don't *have* to be bit-exact to be conformant, it doesn't say you
> can't be if you want to save time on testing.
> 
>>> Already saying "Unless a particular profile is defined", not that there
>>> will be profiles. I don't think we've ever discussed whether profiles
>>> are acceptable or not, so I'm leaving this hear. That being said, the
>>> codec we proposed does not have profiles.
>> 
>> I don't care about your proposal, nor should you as the editor of this
>> draft.  This is one of the problems we have with the composition of this
>> WG...
>> That said, on the subject matter, I'm fairly neutral, and I should have
>> expressed myself.  What I aimed to say was that I don't think we have any
>> consensus in this area yet.
> 
> Exactly. Which is why the current wording does not say whether profiles are
> good or bad. And even if/when we decide on having profiles or not having
> them, I don't think that belongs to the guidelines.
> 
>> Let me give it a stab:
>> 
>> I believe the business intention is not to require error concealment at all.
>> Accordingly, there cannot be a conformance test for error concealment.  It
>> can be subject to characterization tests, though...
>> 
>> So this is what could go in 4.4:
>> To ensure freedom of implementation, decoder-side only error concealment
>> does not need to be specified, although an informal description of the
>> reference implementation's PLC algorithm, if any, is desirable.  Obviously,
>> any information signaled in the bitstream intended to aid PLC needs to be
>> specified.
> 
> Used your suggestion again, though I changed the first sentence to:
> 
> To ensure freedom of implementation, decoder-side only error concealment
> does not need to be specified, although the reference implementation should
> include the same PLC algorithm as used in the testing phase.
> 
> Just like the reference implementation needs to contain a working encoder
> (even though the encoder would not be strictly specified), I also think the
> PLC should be part of the reference implementation (not just an informal
> description).
> 
>> And move the sentence about minimum requirements of PLC efficiency to an
>> appropriate place in section 3.
> 
> Left it in that section because it's still talking about normative issues,
> not really about testing to decide whether we did a good job with the codec.
> 
> Cheers,
> 
> Jean-Marc
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec