Re: [rtcweb] Finishing up the Video Codec document

[Ron <[e-mail]>]

On Sat, Dec 06, 2014 at 07:14:48PM -0700, Peter Saint-Andre - &yet wrote:
> On 12/4/14, 9:08 AM, Adam Roach wrote:
> >On 12/4/14 07:45, Peter Saint-Andre - &yet wrote:
> >>On 12/4/14, 8:00 AM, Ron wrote:
> >>>
> >>>On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet
> >>>wrote:
> >>>>
> >>>>IMHO we need to either pull out the future-oriented text entirely
> >>>>(which has
> >>>>its own problems) or significantly improve it. I would be happy to
> >>>>propose
> >>>>text for the latter.
> >>>
> >>>I'd definitely be interested in seeing proposals from you to improve
> >>>upon these things.  It seemed premature to explore this until we had
> >>>some sense of whether this kind of compromise could fly at all, but
> >>>now that it seems it can, I think these are important details for us
> >>>to clarify as best we can.
> >>
> >>OK, I'll get to work. :-)
> >
> >Awesome, thanks. I've always found your prose to be clearer and easier
> >to read than mine anyway. :)
> >
> >When you draft your text, keep in mind that what we're trying to do is
> >capture the essence of the agreement that we've formed a critical mass
> >around. The less formal (i.e., not really document-ready) version of
> >this is:
> >
> >>"WebRTC devices MUST implement both VP8 and H.264. If compelling
> >>evidence arises that one of the codecs is available for use on a
> >>royalty-free basis, such as all IPR declarations known for the codec
> >>being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change
> >>this normative statement to indicate that only that codec is required.
> >>For absolute, crystal clarity, this provision is only applicable to
> >>WebRTC devices, and not to WebRTC User Agents."
> >
> >There's nuance to be added there, for sure, but I'd encourage you not to
> >color way outside those lines. Expanding scope to discuss issues such as
> >*other* circumstances that may cause revisiting the MTI, for example,
> >are far more likely to weaken consensus than they are to strengthen it.
> 
> I see two kinds of triggers:
> 
> 1. A trigger that is specific to the alternatives we have been presented so
> far. That is: only H.264 or VP8 (or both) can be MTI. If we learn that one
> of them can be used royalty-free, then that codec will be the only MTI
> codec.
> 
> Questions:
> 
> 1a. Does this trigger fire as soon as one codec is learned to be usable
> royalty-free? So this is a first-past-the-post contest? (Let's say codec
> "c1" is learned to be usable RF and the next week or month or quarter "c2"
> is learned to be usable RF. What happens?)

This question was briefly picked at here:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13506.html


> 1b. Text along the lines of "the IETF will change this normative statement"
> does not make it clear how that will happen. Is there an automatic trigger
> (i.e., it's built into this document)? Or does the IETF need to do something
> (e.g., publish an RFC that obsoletes this one)?
> 
> (There is some interaction between 1a and 1b. If some process is needed to
> declare "c1" the only MTI, then it's possible that we might learn that "c2"
> can also be used RF before the obsoleting RFC can be published.)

My impression was that this trigger is basically only relevant up until
the point where we actually publish an RFC specifying MTI video.  Since
after that it's essentially set in stone unless or until we publish some
superseding RFC.

There were one or two voices pushing for whatever decision we make now
to somehow irrevocably bind all future decisions, but personally I think
that is pure nonsense, we couldn't do that even if we wanted to.  Any
future RFC can say anything it likes, whether made by this same group
or any other.

If the facts on the ground change after we've published, sufficiently
for us to want to do something else, then I assume that something else
will need to run the gauntlet of IETF consensus again the same way as
any proposal normally would.

If I'm wrong about any of that, I'm happy to rethink my assumptions,
but that's the datum I've been surveying things from.


> 2. A trigger that is more general and future-proof. That is: someday
> (perhaps before too much longer on the standardization timescale) we will
> have other alternatives to consider: H.265, VP9, VP10, Daala, and who knows
> what.
> 
> Another question:
> 
> 2a. There is some interaction between 1b and 2. Let's say it takes us 10
> years to learn that "c1" can be used RF. Hurray! But by that time, we might
> have "c3" and "c4" and "c5" to consider. Are we forbidden from considering
> anything but "c1" and "c2" at that time?
> 
> I *think* that the trigger you're talking about is #1. Personally I am much
> more interested in #2 because I don't think we'll really settle this issue
> in the medium term or long term until we have the video equivalent of Opus.

I think this is where the hopes of most of the people who have been
facepalming at the idea of H.264 even being considered here, except
as some sort of sick in-joke, have moved to now.  With this compromise
essentially just being a way to avoid the work of this group collapsing
completely before the IETF can do for video what it did for audio with
Opus.

What should happen with this standard once it does, is much less clear
to me at this point in time.

The obvious first step Ted reiterated again most recently here:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13722.html

 "Note as well that I, personally, have never advocated for having a
  single codec available to an app or a browser; the methods for
  negotiating are a key part of this infrastructure, and they will be
  key to it moving forward as things progress.  We worked toward a
  mandatory-to-implement to avoid interoperability failure."

So things which support a new codec will be able to negotiate it as
soon as it is available, as an essential part of this spec.

Whether we'll want to revisit making one or more of them MTI, and/or
dropping one or more of the existing MTI choices, seems like something
we can't really answer yet.

I do hope we'll have an IETF working group for video codec work soon,
how long before it completes that work and publishes is an open question
and how long after that happens before it reaches World Domination is
another.

Where RTCWEB will be at that time, I'm not sure anyone has a sufficiently
powerful crystal ball to really say.  (I mean, who would have guessed
that after all these years people are still dorking about trying to
*finish* HTML :)


I completely agree that this is the really interesting question now,
and it was one of the reasons some of us put forward the idea of having
H.261 as the MTI (if you're going to be stuck with a legacy MTI forever
it might as well be something lightweight) but that idea didn't really
get to critical mass either.

At this stage, I think we basically can only look at what options we
have and what facts we know up until the point where the video MTI
question goes to WGLC for publication of the RFC specifying it.

What happens after that is basically a clean slate again.  We can't be
constrained "normatively" by any previous decision, and it would be
stupid to want to be, since it's far more likely that things we don't
expect will change what we have to work with than things which we do.
(We might wake up tomorrow to find some company announcing that it has
essential patents on H.264 that it is refusing to licence, which could
change things we haven't specified actions for here too but that might
still spur us to action anyway)

All we can really do is work toward the world that we really want to
have, and make future decisions based on how successful we were at
that in the future.  I don't think anything we are talking about here
can or does rule out any of the interesting possibilities you're
seeing for the 'trigger 2' case though.


> Because I think we're talking about different triggers for different
> purposes, my impression is that the text we have in mind would differ
> significantly (in particular, I feel no compulsion to "stay within the
> lines" because I think those lines are not useful, and indeed are positively
> harmful, in the long term).

Unless I'm still missing (or wrong about) something, the worst case I
can see us painting ourselves into for the future is some people might
need to support whatever lands as MTI in this first iteration for a
bit longer than they otherwise would.  That Cisco folk wanted to kill
H.261 (which their devices already support) rather than make it MTI
here, seems to confirm that whatever lines we draw here today, aren't
really going to bind us forever.  If something we pick today becomes
more harmful than good in the future I don't think people are going
to feel bound to keeping it.

Video codecs are still far from being a Solved Problem, and I suspect
"both camps" can probably agree with the above.  If for no other
reason than the people who preferred VP8 are going to see better RF
alternative emerge, and the people who preferred H.264 are going to
have the patents that they hold expire eventually.


I don't mind if we explicitly say something to that effect, but it's
not clear to me that we need to for it to actually be in effect anyway.

  Cheers,
  Ron