Re: [rtcweb] Is there room for a compromise? what about no MTI?

[Ron <[e-mail]>]

On Sun, Dec 22, 2013 at 05:28:27PM -0500, Eric Rescorla wrote:
> > On 12/21/2013 9:28 PM, Justin Uberti wrote:
> >>
> >> I hope that it will be even simpler than that; merely a statement
> >> indicating that devices that can't send or receive a given media type
> >> need not concern themselves with the MTI codecs of that type.

[snipped]

> I don't think that's what Justin is suggesting.
> 
> Rather, I think he's suggesting is that if you don't do video, for
> instance, you need not do the video MTI codec.

I didn't think that this was exactly what he was suggesting either.
The crucial difference being "can't" vs "don't".

If you don't have a camera, or a screen, then it's pretty obvious
to any user of that device that they can't expect any type of video.


This elaboration however is a somewhat different slippery slope:

> To take a simple example, a number of phones do not have front-facing
> cameras

If they have a screen, they can still receive it, and might well expect
to do so.  For that matter, they might even be prepared to stand in front
of a mirror to send it :)

> and also have processors that are incapable of doing an
> adequate video call (especially if we select a codec for which they
> don't have adequate hardware support).

This would seem to be yet another argument for having a low complexity
codec as the fallback MTI.  Given we've established almost no current
device has adequate specialised hardware for any codec and will all
need to be able to do it on its application processor anyway.

Is there anything with a camera that doesn't have processing resources
far greater than were used for video 20 years ago?

What proportion of devices would struggle with VP8 or H.264 on their
application CPU?


> In that case, it might be reasonable to simply not offer video at all
> on such devices.

Which would be a surprising outcome for anyone expecting a device that
can play them cat videos should also be able to give them video from a
webrtc application as advertised.


> In such a case, would it really make sense to call such devices
> non-compliant for not implementing an MTI video codec that they
> wouldn't negotiate in any case?

Yes, it would.  Choosing not to provide video support where video is
an integral part of the standard and something supported by the device
is deliberate non-compliance.

That's quite different from just not doing the obviously impossible
on obviously primitive devices.

People have suggested that if we let the market decide, parts of it
might well decide on only H.265, this would effectively rule out *all*
current mobile devices for lack of processing power.  If concern for
those devices is in scope here, then we definitely do need to mandate
something with an acceptable complexity bound to ensure that won't
be a problem.


> This seems like an orthogonal question to whether devices that do
> video MUST do a given video codec.

It doesn't seem like a very complicated question.  Justin's suggestion
was an eminently sensible statement of the obvious.  If your device
obviously can't ever do video at all, nobody is going to be surprised
if the code for that doesn't happen to be there either.

That's not in any way practically different from you not giving consent
to enable the camera, and simply turning off your screen backlight.
If you wanted those things you'd have bought a device with a screen and
a camera.


But that's very different from having a device which does have a camera
and/or screen and finding that its claim to support webrtc came with a
big caveat emptor.  I don't think we should be supporting a backdoor
"No MTI" or "let the market decide" outcome through a loophole like this.

  Ron