Re: [video-codec] Charter issues from BoF

[Jean-Marc Valin <[e-mail]>]

On 11/06/2012 11:26 AM, Timothy B. Terriberry wrote:
>> 2. Be clear about "optimized for the internet"
> 
> We can certainly list some of these examples in the charter, but I think
> it's somewhat premature to say those are the only things we're going to
> do, or even that we're going to do all of them. There was some criticism
> that "optimized for the internet" was ill-defined for Opus, but if you
> look at the actual result, you can see that it informed a lot of
> decisions, resulting in a codec that operates quite a bit differently
> from most audio codecs:
> <http://www.ietf.org/mail-archive/web/rtcweb/current/msg05205.html>.

I think "optimized for the internet" is a process more than a feature.
When writing a codec, you make hundreds small (and not so small)
decisions that can have an impact on how well the codec will work in a
particular situation. In this case, what we're saying is that we'll try
to optimize these decisions for use on the Internet. So I think the
charter should only have "optimized for the Internet" and then have the
requirements specify higher-level Internet-related features we're going
to aim for.

>> 4. Sort out preferred licensing terms early.
> 
> We (Xiph.Org/Mozilla) obviously have some strong preferences here. You
> can look at our Opus disclosures to see what they are. Given the strong
> reactions against discussing such issues on the list with Opus, I'm
> hesitant to specify what those terms should be in the charter.

I agree with sorting out the licensing terms as early as possible,
though as Tim points out, this shouldn't be part of the charter itself.

>> 5. Be clear about targets for coding efficiency.
> 
> Speaking personally, as long as we have a significant advantage over
> existing royalty-free options (e.g., Theora and VP8), then it is
> worthwhile publishing the result. Some people think we should strive for
> much more (i.e., significantly better than HEVC), and I think that's
> great, but if we were merely "competitive" with HEVC, I wouldn't count
> this as a failure. Greg Maxwell has language to this effect in his
> requirements draft. Should there be similar language in the charter as
> well?

The "goal" is certainly to have a codec that's as good as possible,
ideally being better than HEVC. But this codec would be useful even if
it's "only" better than VP8 and Theora. This is similar to Opus, where
having "better than Speex" as a requirement didn't prevent us from
ending up better than even non-real-time encumbered codecs.

>> 7. Have a strategy for achieving RF.
> 
> The most important part of this strategy is already specified in the
> charter, namely that the codec be developed "Under the IPR rules of the
> IETF." I discussed that in a little bit more detail at the BoF.

I really think that "Under the IPR rules of the IETF" is the only thing
that should go in the charter. The rest we should adapt and optimize as
we go along (even though several strategies have already been discussed).

>> 8. Be clear if the WG is creating new technology or selecting existing
>> technology.
> 
> Given the existing technology I'm aware of, I have no problem saying
> we're going to be creating something new here. That might preclude the
> possibility of the JCTVC offering the world HEVC royalty-free via the
> IETF, but that proposition seems so vanishingly unlikely that it won't
> keep me up at night.

Yeah, I don't really mind leaving the option, but realistically what
we're going to end up doing is creating something new.

>> 9. Use signaling to have fine grained enablement of features.
> 
> Regardless of any IPR implications, this feels like a technical
> discussion. I.e., there are implications about interoperability,
> profiling, and testing here. You don't want more than 8...10 of these,
> or you add an enormous burden if you want to test all combinations
> exhaustively. I'm not saying this is a bad idea, just that there's a lot
> of details to work through (beyond the obvious "what features should the
> flags affect?"). If someone has an idea of something useful we can say
> in the charter on this subject, I'm all ears.

Agree with Tim, that's a technical discussion we need to have at some
point. That point is probably late in the process when we can actually
evaluate the impact it would have on the actual codec.

>> 10. Have a clear idea how to get test results to inform WG decisions.
> 
> Fortunately, we're in a much better position with video than we were
> with audio. The objective metrics are more useful... everyone knows
> they're still flawed in various ways, but you can still make a lot of
> progress relying on such metrics (see the various ITU/MEPG efforts that
> rely on them exclusively). PSNR measured on a single, short clip
> comparing mostly similar algorithms actually correlate with human
> observer ratings pretty well [1]. Most comparisons between different
> codecs rely on them, too.

Speaking from experience with Opus, I don't think that was a big issue.
Not having an advantage in getting as much IPR in as possible regardless
of quality meant that we were usually able to come pretty quickly to an
agreement over what was useful. In the end, there is quality, but also
complexity, simplicity, robustness, IPR and so on to keep in mind, so
trying to have fixed rules is more complicated than actually making the
decisions on a rough consensus basis.

Cheers,

	Jean-Marc