Re: [rtcweb] revisiting MTI

[Gaelle Martin-Cocher <[e-mail]>]

From: Eric Rescorla [mailto:[e-mail]]
Sent: Tuesday, December 16, 2014 2:59 PM
To: Gaelle Martin-Cocher
Cc: John Leslie; [e-mail]
Subject: Re: [rtcweb] revisiting MTI



On Tue, Dec 16, 2014 at 11:56 AM, Gaelle Martin-Cocher <[e-mail]<mailto:[e-mail]>> wrote:
I am not sure on what you are basing your opinion.

As I said, the purpose of an MTI is to provide basic interop.

That point is clear to all.  Sorry I was referring to “I would not imagine that we
would define a new required codec unless it was not just technically
superior but also definitively RF in the sense contemplated by Adam's
text.”
And I am not sure that holds true.

Waiting for an RF technically superior codec might not be pragmatic and can indeed prevent any evolution of WebRTC codec for a long time.
Deprecating MTI can be done in steps (e.g. become SHOULD, then MAY)

If this MTI text prevents codec evolution, this is a serious issue.

It doesn't prevent codec evolution. That's why we have negotiation. Browsers
are free to implement non-MTI codecs and I would anticipate that they
will do so.
And non-browser as well, but the spec will let us stuck for ever with low performing codec.

Gaëlle

-Ekr





Gaëlle


From: Eric Rescorla [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, December 16, 2014 2:38 PM
To: Gaelle Martin-Cocher
Cc: John Leslie; [e-mail]<mailto:[e-mail]>

Subject: Re: [rtcweb] revisiting MTI



On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Cocher <[e-mail]<mailto:[e-mail]>> wrote:
I have little confidence that the choice between H265 and VP9 will be easier than it is today between VP8 and H264.
Are we going to multiply similarly performing codecs  going forward (in the spec or in practice) or be stuck with mandatory low performing codecs because we cannot make better decision?

It's important to remember that the requirement for an MTI codec
is to guarantee basic interoperability. I would not imagine that we
would define a new required codec unless it was not just technically
superior but also definitively RF in the sense contemplated by Adam's
text.

-Ekr



Time frame for H265 / VP9  is up to two years from now
And possibly the timeframe for H.266/Dalaa is four years from now

This is one more drawback of the proposed text for MTI, not only it multiplies encoders and decoders to be supported but  can prevent the evolution of webrtc toward more advances codecs. (assuming we will not require 4 or 6 encoders and 4 or 6 decoders to be supported by every single endpoints. Two MTI seems largely enough, no?).

Gaëlle

From: rtcweb [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Eric Rescorla
Sent: Tuesday, December 16, 2014 11:53 AM
To: John Leslie
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] revisiting MTI

On Tue, Dec 16, 2014 at 8:25 AM, John Leslie <[e-mail]<mailto:[e-mail]>> wrote:
Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:
> On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <[e-mail]<mailto:[e-mail]>> wrote:
> Needless to say, having WG consensus on the substance and letting the
> editor wordsmith the text is totally normal IETF process.

   In some cases, yes. IMHO, this is not one of them. YMMV...

Indeed it does, since I have *never* heard of such a case where
the editor had no discretion to change the text in purely editorial
ways (subject to WG consensus of course). Feel free to cite one
if you have one.


> I haven't heard anyone who was at HNL and in favor of the text on the
> slides object that Adam's text in the draft doesn't reflect those
> slides.

   Probably you haven't...

To the best of my knowledge it hasn't happened. Can you cite anyone
who has so objected.



> Besides, Eric isn't the WGC calling consensus.
>
> No, the chairs did here:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html
]
] From: Sean Turner <turners at ieca.com<http://ieca.com>>
] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion
] about codecs, which I dubbed "the great codec compromise."
] The compromise text that was discussed appears in slides 12-14 at [4]
] (which is a slight editorial variation of the text proposed at [2]).
]
] This message serves to confirm the sense of the room.

   Actually, as I read this more carefully, that isn't a consensus call.
Sean goes on to dismiss the objections he heard in the room:

He's addressing them. What exactly is the problem with this?


] 3) Trigger:
] Objection: The "trigger" sentence [3] is all kinds of wrong because
] it's promising that the future IETF will update this specification.
] Response: Like any IETF proposal, an RFC that documents the current
] proposal can be changed through the consensus process at any other time.

   Sean is specifically saying the "trigger" should be discussed
on-list.

I don't read this this way at all, Rather he's saying that in the future we
can update the RFC. But yes, we can discuss the trigger on-list. Do you
have some substantive objection that wasn't raised in HNL and/or
hasn't been discussed to death here?


] After the discussion, some clarifying questions about the hums, and
] typing the hum questions on the screen, there was rough consensus in
] the room to add (aka "shove") the proposed text into
] draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming
] this consensus call on the list.

   This _is_ calling for consensus.

   But Sean omitted saying _what_ text; and agreed that the exact text
may not have been clear to those in the room.

Huh? The "proposed text" that was discussed in HNL is on the slide and
that's what's being referred to here. Adam edited text which is substantially
the same into the draft.



] If anyone has any other issues that they would like to raise please do
] by December 19th.

   (And folks have been doing so.)

   I have asked on-list for the exact text before raising my issues,
since my issues relate to the text, not the choosing to have two MTIs.

As I pointed out in my original message, that text is in Adam's draft.

Again, it's totally procedurally regular to have rough consensus on text in
the WG meeting and on the list and then have the editor edit in substantively
the same text to the draft. If you think there is some respect in which those
two blocks of text are not in fact the same, please point to it. Otherwise,
this is just dilatory.


> And this message clearly points to the slides above.

   I don't find it helpful to attack the people who raise issues. YMMV.

   But what EKR thinks really doesn't matter. He is not a WGC.

Ironic that you would complain about "attack"s in a thread where you
started out by attacking Adam Roach and here say "what EKR thinks
really doesn't matter"

-Ekr