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

[Eric Rescorla <[e-mail]>]

On Sun, Dec 22, 2013 at 8:22 PM, Ron <[e-mail]> wrote:
> On Sun, Dec 22, 2013 at 05:28:27PM -0500, Eric Rescorla wrote:
>> 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.

It is quite possible we will not standardize such a codec.


>  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?

It's actually extremely expensive on low-end phones.


>> 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.

You will note that many such devices use H.264 for precisely this reason.
I.e., they have hardware codecs.


>> 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.

What we are debating here is precisely whether video is or is not a
compliance requirement. You seem to be assuming that, I don't,
and as far as I know the specification language doesn't require
it. Can you please point to the relevant part of the specification
which requires implementations to offer to accept and/or send
video?


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

"Obvious" is a difficult term here. Have you actually tried doing
VP8 video on low-end smartphones? I actually have and I can't
even tell you definitively which ones could eventually be made
to do acceptable video and which ones could not. How, exactly,
is that supposed to be "obvious" to the average consumer?



>> 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.

I don't see any material difference between not having a screen and
not having enough CPU to do provide good quality video. And of
course since nearly all devices have some screen, we're now stuck
debating exactly what flavor of a device has a big enough screen
that it can support video. A watch? An ipod nano? A featurephone?


> 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.

I don't find this very persuasive. If I'm the manufacturer of a device which
has a hard time doing acceptable video conferencing, I have three
choices:

1. Don't offer WebRTC at all.
2. Offer WebRTC audio only.
3. Offer WebRTC with lousy video;

You seem to want to argue that we should label anyone who does #2 as
noncompliant. I fail to see how that serves any useful interest, especially
given the extremely marginal value of "compliant" versus "noncompliant"
to the average consumer.

-Ekr