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

On Fri, Dec 20, 2013 at 10:02:20PM +0000, 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.

The p64 implementation of H.261 (this being the one that is deliberately
not highly optimised for anything at all except correctness and ease of
verification) fits into ...  wait for it.   64kB.

And that includes all of the effusive help text, diagnostic and error
strings ...

So given we've already established that almost no device will actually be
able to use its potential hardware-offloading for this, and will almost
certainly need to carry a software implementation - this certainly looks
like a very attractive choice for the constrained devices that worry you!

How much memory does the Skype logo image take ;?

  Ron

> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ron [ron@debian.org]
> Sent: Friday, December 20, 2013 10:29 AM
> To: rtcweb@ietf.org
> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb