On Thu, Oct 25, 2012 at 05:25:44PM -0700, Matthew Kaufman wrote:
> On 10/25/2012 5:15 PM, Ron wrote:
> >On Thu, Oct 25, 2012 at 03:26:31PM -0700, Matthew Kaufman wrote:
> >>Ok, so now that we've had one round of the usual debate that won't
> >>terminate, *how* much time on the agenda do we really want to spend
> >>debating the potential merits or flaws of codecs that some of us
> >>either will or will not use no matter what happens in the meeting?
> >If you feel that the discussion has exhausted all the rationale
> >that you have to offer, perhaps you'd like to summarise what you
> >see as the potential merits and flaws of each candidate for us?
> >
> 
> I think I made this clear in an earlier post. VP8 is not the product
> of a recognized standards body. This has negative technical
> implications and negative legal implications. I am not a lawyer, and
> this is an IETF list, so that's two reasons for me to not go into
> more detail on the latter.
> 
> As was pointed out by someone else, and quoted by me previously, the
> decision to include or not include a particular codec in a shipping
> product is not going to be made by any of the technical people on
> this list, and so discussing it here or at the meeting is pointless.
> And presenting *technical* arguments as to the superiority of one or
> another is likewise pointless.

That's a pretty good summary of the problems I'm seeing with the
arguments against VP8 indeed.  And exactly why I asked to see a
more substantial summary of them.

In the one breath you are saying "not the product of an SDO == Bad"
is your only direct argument against it.

And then you immediately follow that with "we should ignore anything
this SDO has to say about it anyway".  And then wonder why I'm more
than a little bewildered about what exactly your argument is here?

The decision of which codec should be MTI for this proposed standard
not being the product of this recognised standards body, I completely
agree would have negative technical and legal implications for it.
Serious ones at that.


It is far less clear in practice how much harm this does to a codec
that was carefully designed by experts in that field though.  It is
clear that working within the IETF process did wonderful things for
Opus -- but it is much less clear that the same people working
together in the same way would have produced total crap if the
efforts to oppose formation of the CODEC WG had been "successful"
at that and they had done their work outside of an SDO instead.

Where is the offensive patent pool against Theora that we've been
hearing about for so many years?  Or the single lawsuit against a
user of it?  What about Vorbis?  Any problems it had were neither
technical nor legal.  Can nobody at all shed any light on the
status of the mythical pool that wanted to attack VP8 which seems
to have vanished in a whimper over a year ago?  Did anyone sue
Skype for SILK?  How does the success of those compare to OOXML?


I don't really see how your argument there is coherent with either
itself or the observable reality.  But you're insisting on it very
strongly so I'm hoping you can clue us in on the missing link that
makes it actually make some sense.



> My employer happens to be a major browser vendor, has published blog
> postings that I've previously referenced on this topic, and nothing
> substantive has changed since those were posted as far as I can
> tell.

So that's the basis on which you think we should decide this?

There are two other major browser vendors contributing here,
and as I understand it, they both prefer VP8.  Since they have
the lion's share of users, why shouldn't their preference stand
if this logic is applied?

You say nothing substantive has changed since then.
The slope on this graph looks like pretty substantive change to me:
http://upload.wikimedia.org/wikipedia/commons/8/86/Usage_share_of_web_browsers_%28Source_StatCounter%29.svg

The numbers here look pretty substantive too:
http://www.w3schools.com/browsers/browsers_stats.asp


But personally I'd still much rather see us build consensus around
a clear list of agreed pros and cons, so that when people look back
and wonder "how did the RTCWeb WG make that decision" we will have
something a bit more substantive to show for it than "via a farce
where industry heavyweights had their preference rubber-stamped
without discussion or justification that held up to even the most
casual scrutiny."

I'm pretty sure this still is a technical standards group, and that
technical arguments to back up its decisions mostly aren't pointless.

  Unabashedly,
  Ron