Re: [rtcweb] revisiting MTI

[Eric Rescorla <[e-mail]>]

On Tue, Dec 16, 2014 at 11:56 AM, Gaelle Martin-Cocher <
[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.


 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.

-Ekr





 Gaëlle
>
>
>
>
>
> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* Tuesday, December 16, 2014 2:38 PM
> *To:* Gaelle Martin-Cocher
> *Cc:* John Leslie; [e-mail]
>
> *Subject:* Re: [rtcweb] revisiting MTI
>
>
>
>
>
>
>
> On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Cocher <
> [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]] *On Behalf Of *Eric
> Rescorla
> *Sent:* Tuesday, December 16, 2014 11:53 AM
> *To:* John Leslie
> *Cc:* [e-mail]
> *Subject:* Re: [rtcweb] revisiting MTI
>
>
>
> On Tue, Dec 16, 2014 at 8:25 AM, John Leslie <[e-mail]> wrote:
>
> Eric Rescorla <[e-mail]> wrote:
> > On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <[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>
> ] 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
>
>