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

[Ron <[e-mail]>]

On Sun, Dec 22, 2013 at 08:42:10PM -0500, Eric Rescorla wrote:
> 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:
> 
> >> 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.

It is indeed possible, yes.  Whether it would be wise is the question
that I think we might not have considered sufficiently in this light.


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

Which is why I think the question of complexity bound is quite relevant
for MTI fallback requirements.


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

The earlier discussion had a hard time finding any device where those
hardware engines would actually be able to be used by WebRTC applications
for a fairly broad range of reasons.  So even those devices still have
the same complexity constraints, and either they are important and we
should consider what will actually work on them - or they aren't and any
argument about what they can or can't support is irrelevant to WebRTC.

It doesn't seem unreasonable to decide that the mandatory parts of this
standard should be able to actually run on the general purpose CPUs of
the sort of devices that are expected to benefit from implementing it,
without the need for proprietary ASICs.


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

Hmm.  I had indeed read the first paragraph of the charter, which
describes audio and video as "core components", as making this a
key part of the standard.

If I'm mistaken about there being consensus on that, then yes, the
question is more open still.   And I'm going to need more popcorn.


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

Hence my question about whether the complexity requirements of both
VP8 and H.264 might actually rule them both out for fallback MTI.
I'm pretty sure we do have at least one video choice available to us
that wouldn't leave those devices completely out in the cold.


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

You'll need to define "good quality video" before we can enter that
rat hole!

Is "able to transmit legible sign language" good quality?

How big does a screen need to be before the extra quality of the high
complexity codecs actually become perceptible and of any value at all?


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

Actually, my argument here is probably closer to:

 - If we create a crap standard, that puts devices which do have video
   hardware into a ghetto if they don't have the right proprietary ASIC
   to support even the minimum requirement for video - then that would
   be our fault and it would deserve to be called a crap standard.

 - If vendors create an implementation of it that gives users of some
   device a far poorer experience than they might otherwise reasonably
   expect to have had, then yes they deserve whatever label they might
   receive for that, not us.

As you say, given the marginal value to consumers, they don't have to
claim to be WebRTC compliant in order to interop with it for audio only.

The bigger danger is allowing the creation of a general impression that
"video doesn't work with WebRTC at all on video devices".  Which would
leave us right back with the same problem that this group was chartered
to solve.

  Ron