Re: [codec] Updated Opus draft

Hi Jean-Marc,

I would consider the baselines the codecs that were proposed as starting point for the prototype codecs. If no improvement can be shown above these references it looks like a rubberstamping of these codecs. If, as you say, they have both improved significantly then there is no need for debate. Let's put them in the test just to verify it. 

Best regards,
Erik  

> -----Original Message-----
> From: Jean-Marc Valin [mailto:jmvalin@jmvalin.ca] 
> Sent: den 4 mars 2011 13:31
> To: Erik Norvell
> Cc: Koen Vos; codec@ietf.org
> Subject: Re: [codec] Updated Opus draft
> 
> Hi Erik,
> 
> Keep in mind that including all three modes is necessary to 
> fulfill the requirements we have 
> (http://tools.ietf.org/html/draft-ietf-codec-requirements-02).
>  These requirements also include baseline codecs to compare 
> with (e.g. Speex, iLBC, ...).
> 
> Also, I may be misinterpreting here, but you seem to include 
> SILK and CELT in the list of "baseline codecs we must beat". 
> If SILK and CELT were already standardized codecs then I 
> might agree, but since it's not the case I don't think it 
> makes sense. It would essentially by saying "your codec must 
> be better than itself to be standardized". While it happens 
> that both have improved significantly since this effort 
> started, I do not see how this matters here.
> 
> Cheers,
> 
> 	Jean-Marc
> 
> On 11-03-04 03:00 AM, Erik Norvell wrote:
> > Hi Koen,
> >
> > I appreciate the work being done on extending the codec 
> functionality. 
> > However, I am not sure that it comes for free since the more 
> > technology is included the higher the risk of including third party 
> > IPR. If the codec functionality is already too wide to be 
> covered by a 
> > listening test then the IPR analysis might also be lagging behind.
> >
> > Seamless switching between a wide range of operating points is a 
> > desirable feature, but the primary goal in the charter is still to 
> > produce an unencumbered codec. If the additional modes does not 
> > produce value over already existing codecs, it would be 
> safer to leave 
> > them out.
> >
> > Best regards, Erik
> >
> >
> >> -----Original Message----- From: Koen Vos 
> [mailto:koen.vos@skype.net] 
> >> Sent: den 3 mars 2011 15:57 To: Erik Norvell Cc: codec@ietf.org; 
> >> Gregory Maxwell; Anisse Taleb; Jean-Marc Valin Subject: 
> Re: [codec] 
> >> Updated Opus draft
> >>
> >> Hi Erik,
> >>
> >>> This supports standardization of the hybrid mode, which
> >> represents 4 out of the 32 modes. It seems reasonable that the 
> >> remaining 28 modes are also checked against their corresponding 
> >> baseline at the same rate/bandwidth.
> >>
> >> Are you suggesting that to be added to a standard, each 
> mode has to 
> >> outperform (or perhaps be now worse than) its 
> corresponding baseline?  
> >> I think such requirement is too strong, for multiple reasons.
> >>
> >> 1. The 28 non-hybrid modes enhance the standard, regardless of how 
> >> they compare to their baselines: - The non-hybrid modes greatly 
> >> expand the useful operating range and flexibility. - The 
> non-hybrid 
> >> modes come virtually for free.
> >>
> >> 2. The seamless switching between the modes, which 
> everyone seems to 
> >> agree is important, is made possible by having all modes in one 
> >> codec.
> >>
> >> 3. It ignores improvements beyond rate/bandwidth/quality, 
> such as the 
> >> code size and complexity optimizations we did for SILK.
> >>
> >> Checking modes against their baselines is of course a good sanity 
> >> check during development, and we've been doing such tests 
> >> extensively.  I welcome anyone to do more of them. 
> However, the sheer 
> >> amount of listening necessary to compare all 28 non-hybrid modes 
> >> against their baselines with sufficient statistical 
> significance is 
> >> large compared to the value it brings.
> >>
> >> best, koen.
> >>
> >>
> >> ----- Original Message ----- From: "Erik 
> >> Norvell"<erik.norvell@ericsson.com> To: "Gregory 
> >> Maxwell"<gmaxwell@juniper.net>, "Anisse Taleb"
> >> <anisse.taleb@huawei.com>, "Jean-Marc Valin"
> >> <jean-marc.valin@octasic.com> Cc: codec@ietf.org Sent: Thursday, 
> >> March 3, 2011 12:36:52 AM Subject: Re: [codec] Updated Opus draft
> >>
> >> Hi Greg,
> >>
> >>>
> >>> It's fairly trivial to demonstrate that Opus is superior to
> >> either the
> >>> transform mode or the LP mode alone (or those modes prior
> >> to the work
> >>> done as part of the WG process)- E.g. at low rates the 
> silk/hybrid 
> >>> modes are _obviously_ better (esp for speech) than the transform 
> >>> mode,  and at high rates the
> >> transform mode
> >>> is clearly better (and can achieve lower latencies too).   The
> >>> presentation of IETF-78 shows the hybrid outperforming 
> SILK and CELT 
> >>> alone (http://tools.ietf.org/agenda/78/slides/codec-0.pdf)
> >>> at some rate. Though the transform mode's performance at 
> low rates 
> >>> was
> >> subsequently
> >>> improved, the differences at low rate are still pretty stark.
> >>>
> >>> If you only pick a single given rate the performance 
> might only be 
> >>> equal to one of SILK/CELT alone (well, ignoring the fact 
> that both 
> >>> modes have been improved as part of the process here) if
> >> you've picked
> >>> a rate where one or the other technique is inapplicable.   So
> >>> rather than "at a given bitrate" if you say "at some relevant 
> >>> bitrates" it would be a more practical requirement.
> >>>
> >>
> >> This supports standardization of the hybrid mode, which represents
> >> 4 out of the 32 modes. It seems reasonable that the remaining 28 
> >> modes are also checked against their corresponding baseline at the 
> >> same rate/bandwidth.
> >>
> >> The listening test from IETF78 has been referenced a few times. We 
> >> should remember that it was presented with a disclaimer that the 
> >> results were not that reliable and that the test should be 
> seen more 
> >> as an example of how it could be conducted.
> >>
> >> Best regards, Erik _______________________________________________
> >> codec mailing list codec@ietf.org
> >> https://www.ietf.org/mailman/listinfo/codec
> >>
> > _______________________________________________ codec mailing list 
> > codec@ietf.org https://www.ietf.org/mailman/listinfo/codec
> >
> >
> 