Re: [rtcweb] revisiting MTI

[Daniel-Constantin Mierla <[e-mail]>]

On 15/12/14 23:18, Peter Saint-Andre - &yet wrote:
> On 12/15/14, 3:03 PM, Ted Hardie wrote:
>> On Mon, Dec 15, 2014 at 1:37 PM, Peter Saint-Andre - &yet
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Not as far as I can see.
>>
>>     Ten years ago if we'd had this discussion, H.261 might have been
>>     MTI. Ten years from now, H.264 will seem ancient, too.
>>
>>     I fully expect that someone in the IETF (perhaps not us) will
>>     revisit the MTI decision once we have better alternatives.
>>
>>     Peter
>>
>>
>> ​The nice thing is that our current model allows us to have nice things
>> right away; as soon as they are in common, they may be selected by
>> negotiation.  What the MTI gives us is a way to avoid interoperability
>> failure.  So the key question isn't really "Is there something better?"
>> but "Is the current MTI so bad that folks aren't willing to use it, so
>> we are once again at risk of interoperability failure?".
>
> Some folks have expressed a concern that whatever we choose as an MTI
> codec now must always be an MTI codec. I'm trying to allay that
> concern by saying that yes, indeed, we can change our MTI codec(s) in
> the future if we please (naturally, keeping interoperability in mind
> at that future time).
>
Perhaps that concern was created by the phrasing of the current
proposal/draft that MTI is not going to be revisited for browsers.

On the other hand, if this is going to be adopted (not to be
misinterpreted, I don't agree with this proposal), is a quite "ugly"
compromise, probably the most unclean rough consensus so far, nothing
that is backed up with technical merits. I find it more fair to make it
explicit that this was a "last resort" compromise, with a trigger for
revisiting. It will accelerate the process for a RF codec, when having a
clear benefit out of it -- what interest would be to push money on a new
RF codec when you have to implement a paid one anyhow.

Moreover, IETF has an affinity of stating backward compatibility (see
RFC3261/SIP doing that for RFC2543), there will be always enough people
asking for that to get in the same kind of debate like here.

Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda