Re: [rtcweb] Finishing up the Video Codec document

[Peter Saint-Andre - &yet <[e-mail]>]

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?)

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.)

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.

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).

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/