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

[tim panton <[e-mail]>]

On 22 Dec 2013, at 22:28, Eric Rescorla <[e-mail]> wrote:
> 
> 
> To take a simple example, a number of phones do not have front-facing
> cameras 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). In that case, it might be
> reasonable to simply not offer video at all on such devices.  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?

That’s a whole set of assumptions that the browser vendor is loading on very little data.

- So just because there is no forward facing camera we assume there will be no possible webRTC
video usage ? - I disagree - it may not do for the classic f2f call, but I’ve seen plenty of show-and tell
use cases where the rear cam is the one sending video.

As for the incapable hardware example, again there are plenty of 1 way video call cases 
(think amazon mayday), the hardware may be able to decode something it can’t encode.

As I noted a while back SDP OA is clumsy at expressing these asymmetrical nuances, but I’ve
been assured it is possible.

Also I notice that the Raspberry Pi which has h264 in silicon has recently started supporting VP8
by using the GPU to accelerate some of the encode operations. - An example a device that seems not
to support a given codec, but with a firmware upgrade can.

It would be a shame if (for example) firefox on the Pi didn’t offer webRTC video just because at some
point one of the devs had had a Pi with no camera module or where VP8 was too slow.

;tldr
- We need to leave these decisions to app developers and not assume anything we don’t absolutely have to.



Tim.