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

["Matthew Kaufman (SKYPE)" <[e-mail]>]

Mandating H.264 *and* VP8 isn't going to change what browsers support.

Mandating H.261 isn't going to change what embedded devices support.

So why are we bothering to mandate what manufacturers will ignore?

Matthew Kaufman

(Sent from my iPhone)

> On Dec 20, 2013, at 12:52 PM, "cowwoc" <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb