Re: [rtcweb] Making both VP8 and H264 MTI

[Ron <[e-mail]>]

On Tue, Nov 05, 2013 at 01:06:19PM -0500, cowwoc wrote:
>     In light of the fact that vendors are highly polarized on this
> topic, I'd like to suggest the following voting order:

I don't think it's really all that relevant for rough consensus if
'vendors are highly polarised' on the question at all.

If you make that a consideration, I'm sure you can find some vendors
(who may or may not be present here) who strongly wish that WebRTC
will never exist at all in the form that this group's charter has
envisaged, since its success would pose a very real threat to their
current business monopolies.  That doesn't give them a right of veto
to this work, though their input, like everyone else's, still merits
consideration for its technical contribution to best achieving the
charter's aims.

Having a favourite horse in a race is fine.  Having that horse be the
fittest to win is a far more objective measurement.


The question of choosing a MTI codec hinges on interoperability, and
we have established consensus that having a viable MTI codec is quite
crucial for this.

Right now we have 2 proposed candidates.  So the important questions
are:

 - Are either of those candidates suitable?
 - Is one clearly more suitable than the other?

And the present question has been framed by the WG chairs as:

 - Are there reasons that people could not possibly use either choice?


The reasons that people cannot possibly use H.264 are well established.
Its licencing simply does not permit people to use it in all the varied
ways that implementors and users of WebRTC would require.

The Cisco announcement was clearly an attempt to mitigate this fatal
constraint for their preferred choice, and while it goes some way toward
doing that - and is certainly a bold and perceptive step for them to
take to maintain the value of their existing investment - they are still
constrained by these same licencing terms to only be able to offer a
very limited solution, of limited use, to a limited number of people.
And they still can't offer the sort of indemnity that the H.264 camp
has demanded from VP8 in draft-dbenham-webrtc-videomti-02, and they
aren't even offering a licence to _all_ of the known IPR covering H.264,
only to that covered by the MPEG LA pool - which the Nokia portfolio,
some of which was already disclosed, is notably outside of.


The reasons that people cannot possibly use VP8 are far less clear.
None of the objections beyond "we don't want to" so far have any
grounding in reality.  The "but but submarine IPR!!" argument applies
equally to *anything* that any WG might chose to do or use.

Nokia tried to pull some out of their hat, but they lost in court.
If they couldn't torpedo this, then the chances of anyone else being
able to seem significantly diminished.  But the validity of their
claims over H.264 are not challenged at all, and remain a clear and
present danger for anyone using H.264.  Perhaps even more so now
than ever, given their current financial situation and being the
subject of a takeover bid.


This is why I believe that although we have 2 proposals, only one
of them can seriously stand up to scrutiny for being an acceptable
choice that passes the muster of rough consensus.

"We don't want to" is not a blocker for consensus.

"The licence of this does not permit us to" is a very real blocker.


Given we have consensus for picking an MTI codec, the only reason
not to pick that remaining choice would be if someone springs yet
another last minute surprise which would delay that decision again.

If that actually happens, then maybe we can once again have the
H.261 vs Theora debate - but if it doesn't, then VP8 is still the
no-brainer choice that can stand up to the full test of having
rough consensus and working code that meets the goals of this WG.



Re this suggestion:

> 1. Should *both* H.264 and VP8 be MTI?
> 
> If there is a consensus for yes, stop here.
> 
> 2a. Should *only* H.264 be MTI? or,
> 2b. Should *only* VP8 be MTI?
> 
> If there is a consensus for either one, stop here.
> 
> 3a. Should *only* H.261 be MTI? or,
> 3b. Should no codec be MTI? (this implies transcoding)
> 
>     Given the final choice (H.261 or no MTI) I suspect many vendors
> would choose H.261 and upgrade to H.264/VP8 at runtime. No one
> really wants to go back to the days of transcoding.

You might want to review the list archives.  This question has already
been debated, and I thought the result of that was conclusive, and why
we have only the current proposals that we do today.

  Cheers,
  Ron