Re: [rtcweb] confirming sense of the room: mti codec

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

On 12/13/14, 5:58 PM, Iñaki Baz Castillo wrote:
> 2014-12-13 17:36 GMT+01:00 Sean Turner <[e-mail]>:
>> Just to be clear:  "No plan" does not mean that the requirement is
>> immutable forever, just that we don't have a plan right now.  MTI
>> requirements in IETF documents can always be updated, and they very
>> frequently are.
>
> That sounds good, but I'm still waiting for a response to my
> question made yesterday:
>
>>> The rationale here is browser accommodation for very constrained
>>> "WebRTC compatible" devices, which will most typically be
>>> concerned with browser interoperation. The example that's been
>>> tossed around in this space is the "WebRTC doorbell" -- when
>>> someone rings the bell, you navigate to its interface using
>>> WebRTC, and stream an image from a small, embedded camera. In
>>> these kinds of very-low-cost devices, you're going to likely see
>>> hardware video encoding (e.g. do a web search for NVS2200), which
>>> will likely be one codec or another, but not both.
>>>
>>> The goal is continued browser support for such devices in
>>> perpetuity.
>
>> May I know where in the WG chapter is that goal defined please?
>
>
> If the above is a real goal of this WG (is it?) then that means that
> future revisions should respect it ad aternum. This is: even if in
> the future a new *good* video codec 100% RF appears, implementations
> MUST still include both VP8 and H264 (and deal with patent/licensing
> issues, which is a show stopper for certain players in the web
> ecosystem).

The IETF can *always* obsolete one RFC (e.g., one that says "dual-MTI 
for H.264 and VP8") with another RFC (e.g., one that says "no more 
dual-MTI for H.264 and VP8, we have much better options now"). That's a 
core aspect of the Internet Standards Process.

Peter

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