Re: [rtcweb] Is there room for a compromise?

[cowwoc <[e-mail]>]

I have news for you: WebRTC will not run on all devices known to man.

If I had to choose between interoperability for 95% of today's use-cases 
(browsers, smartphones) versus supporting WebRTC on my iToliet, I guess 
I'd have to forgo the iToliet.

Gili

On 20/12/2013 5:02 PM, Matthew Kaufman (SKYPE) wrote:
> On resource-constrained devices, there will barely be room for one highly-optimized (potentially hardware-offloaded) video codec. Carrying software implementations of others, no matter how "simple", will simply not fit in available memory.
>
> Matthew Kaufman
> ________________________________________
> From: rtcweb [[e-mail]] on behalf of Ron [[e-mail]]
> Sent: Friday, December 20, 2013 10:29 AM
> To: [e-mail]
> Subject: Re: [rtcweb] Is there room for a compromise?
>
> Sticking with the truth-in-advertising theme:
>
> On Fri, Dec 20, 2013 at 06:36:31AM -0500, John Leslie wrote:
>>     We have seen strenuous objections to re-compiling 20-year old code
>> for H.261 (and needing to maintain it).
> "strenuous" seems a little tenuous, as is the part about anybody actually
> needing to use 20 year old or unmaintained code to have support for this.
>
> The only "20 year old code" that's been referenced here is a reference
> implementation, that's interesting for IPR assurance reasons, but much
> less so as a production code base (though on a modern machine, even its
> 'not optimised for performance' state might still be faster than some or
> all H.264 encoders, and give you better battery life to boot!).
>
> And that code probably took me nearly all of 15 minutes to resurrect,
> and I could have stopped after the first 5 (with a trivial 3 line patch)
> but I spent a few more to make it warning free and able to cross compile,
> just because my coffee pot wasn't done percolating yet.
>
>
> Or you know, I could have just downloaded a modern lib, that's currently
> maintained and working and suitable for production use.
>
>
>> It _is_ reasonable to think that maintaining code for _two_ obsolete
>> codecs will deserve twice as much objection.
> Yes, 2 x epsilon seems about right to me too.
>
>
>>     We don't _need_ to specify a MTI video codec -- with or without
>> a MTI codec specified, _some_ browser will support the market demand.
> Corollary:
>
>   We don't _need_ to specify a WebRTC standard -- with or without a
>   WebRTC standard specified, _some_ product will support the market demand.
>
>
> Except the charter says that's exactly the problem we're supposed to be
> working on fixing:
>
>   There are a number of proprietary implementations that provide direct
>   interactive rich communication using audio, video, collaboration,
>   games, etc. between two peers' web-browsers. These are not interoperable,
>   as they require non-standard extensions or plugins to work.  There is a
>   desire to standardize the basis for such communication ...
>
>
> So yeah, we could give up on that, and tell everybody to go use Skype,
> or their mobile phone, or whatever the proprietary flavour of the day is
> today.  Or we could be good engineers and actually find a real working
> compromise to solve this problem.  One which calls an artificial blockage
> caused by a wooden shoe exactly what it is.
>
>    Ron
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb