Re: [rtcweb] Finishing up the Video Codec document

[Harald Alvestrand <[e-mail]>]

Personal opinions....

On 12/07/2014 03:14 AM, 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?)

I think it was Adam who said "that's a problem I'd love to have".......


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

When drafting this statement, it became abundantly clear that we
couldn't make a mechanistic trigger. Some human would have to decide
that the trigger conditions had been achieved.

So the IETF needs to do something - at minimum, a declaration by
somebody that the trigger conditions were achieved.

Publishing a new RFC obsoleting -video- would also be appropriate.

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

There are two variants of "consider c3 and c4 and c5": One is adding
c3/4/5 to the MTI set; the other one is removing c1/2 from the MTI set
and putting c3/4/5 into the MTI set instead.

The tendency for new codecs is that they are more complex than the old
ones. So the savings (in code lines or square millimeters of silicon) of
removing a codec from the MTI set is perhaps not so great.
My personal opinion is that removing things from the MTI set only makes
sense if it makes an IPR difference.

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


-- 
Surveillance is pervasive. Go Dark.