Re: [rtcweb] Stephan Wenger's choices

Ron <ron@debian.org> Mon, 30 December 2013 20:50 UTC

Return-Path: <ron@debian.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDFB1AE551 for <rtcweb@ietfa.amsl.com>; Mon, 30 Dec 2013 12:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5AQZtkbOehF for <rtcweb@ietfa.amsl.com>; Mon, 30 Dec 2013 12:50:23 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 955C51AE554 for <rtcweb@ietf.org>; Mon, 30 Dec 2013 12:50:22 -0800 (PST)
Received: from ppp118-210-34-29.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.34.29]) by ipmail07.adl2.internode.on.net with ESMTP; 31 Dec 2013 07:20:15 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 7BEFE4F8F3 for <rtcweb@ietf.org>; Tue, 31 Dec 2013 07:19:19 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id upnmPWEb87O3 for <rtcweb@ietf.org>; Tue, 31 Dec 2013 07:19:17 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id BC0124F902; Tue, 31 Dec 2013 07:19:17 +1030 (CST)
Date: Tue, 31 Dec 2013 07:19:17 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20131230204917.GO3245@audi.shelbyville.oz>
References: <52BF037D.4050706@googlemail.com> <CEE4479F.3E568%stewe@stewe.org> <20131228183148.GI3245@audi.shelbyville.oz> <CABcZeBOMEE9nOMzR2AisGQDTByrjsNms6qS4+DQvjUMUYyHCjw@mail.gmail.com> <20131228212423.GJ3245@audi.shelbyville.oz> <949EF20990823C4C85C18D59AA11AD8B0FDFAB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0FDFAB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Stephan Wenger's choices
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Dec 2013 20:50:25 -0000

On Mon, Dec 30, 2013 at 07:42:54PM +0000, DRAGE, Keith (Keith) wrote:
> A lot of this discussion seems to be predicated on the assumption that if you
> cannot have the video that you want, then any video is acceptable. 

You say that like you think "if I can't have the Ferrari that I want,
or the ability to always use it everywhere, then I'd rather you just
chop my legs off".

> Further it all seems to assume that we can have a lower order codec with more
> bandwidth, whereas when one gets down bandwidth constraints which mobile
> introduces, that does not necessarily apply.
> 
> This may be fine where one has two talking heads as a videostream, but when
> it is two doctors discussing my latest scan, where the video stream is a
> representation of that scan, it would seem to be less acceptable to the
> doctors, and indeed to me.

If you're going to a doctor, who is going to diagnose you on a 4 inch screen
over a shitty mobile connection, then you might get your first wish regardless
of which codec is used!

What you need here is a better doctor, not a better worst case fallback codec.


> So an assumption that any video will do in the absence of a higher order
> codec seems to me to be a false assumption for a number of use cases. Given
> that this is the predicate for an MTI option that would include a lower order
> codec for ensuring compatibility, the argument would seem partly flawed.

So when you've crashed your Ferrari, and there's blood spurting out of your
neck, you'd rather the people your deaf and mute passenger has called for
help would be totally blind as to what is going on and how to help you, than
to have even some image they could show them, and be able to legibly sign
the details of where you are and what help you need?

But I'm pretty sure there's lots of far less critical cases involving far
fewer doctors, where being able to see _something_ is always going to
trump being able to see nothing at all.


> I also suspect that in the two talking heads scenarios, where the bandwidth
> required for the video starts impacting the quality of the audio, then people
> will turn the video off; I know I have done this on Skype in the past.

And nobody is talking about taking that ability away from you.

We're talking about giving people the ability to make that decision for
themselves, instead of ruling it out for no better reason than commercially
tainted artificial snobbery, which considers video to be a premium product
that only users prepared to be fleeced should enjoy.

There is absolutely no technical reason that we cannot make video available
to almost everybody.  And excellent video available to the people with the
necessary means to avail themselves of upgrading to it.

There's only people saying "oh no, we can't let people have that", it
doesn't fit with Our Current Business Model.  (despite the fact we have
shipped H.261 for years in commercial products we made lots of money on)


I quite agree with Eric, that we don't need to go any lower than we do
absolutely need to.  If I thought people might agree on Theora, I'd be
talking about it - but even though Microsoft seem to be not worried at
all about its IPR status, enough to ship Theora video on Bing, I still
fear it will suffer from the same twofaced FUD that VP8 has.

So instead we are talking about the one and only codec that has both
surprisingly acceptable quality for its age, and consensus of no IPR
showstoppers.  The relative fidelity of H.261 for video far exceeds
the relative fidelity of G.711 for speech.

And nobody seems to be able to find an objective technical reason to
rule it out.  If we remember this isn't a vote, that would seem to be
the big thing that the people opposing this really need to find if
they actually want their objections to hold any weight at all.

  Ron


> > -----Original Message-----
> > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron
> > Sent: 28 December 2013 21:24
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] Stephan Wenger's choices
> > 
> > On Sat, Dec 28, 2013 at 11:20:28AM -0800, Eric Rescorla wrote:
> > > 
> > > Even if we mandate H.261, there is a reasonable chance of their 
> > > expectations being thwarted, since they might well expect that the 
> > > quality of video would be comparable, yet it will not.
> > 
> > You don't get much more thwarted than "no video for you", the 
> > only direction from there is up.  Given a device with a ~4 
> > inch screen, viewed from a foot or two away, possibly in open 
> > daylight, maybe even while bouncing around on a bus or train 
> > or while walking, maybe with a bunch of scratches on the 
> > screen or a plastic cover, there's a fair bet that a 
> > significant percentage of viewers wouldn't be able to pick 
> > the difference between it and a perfectly lossless image 
> > stream anyway.
> > 
> > Is it going to be worse than NTSC television?  How many 
> > people were happy enough to keep buying and watching those?  
> > How many still would if it was all that they could get?
> > 
> > 
> > Sure it might not look optimal on your studio monitor, or 
> > your floor to ceiling boardroom conference screen, or to eyes 
> > that have spent years picking out visual artifacts from lossy 
> > codecs.  But we're not ruling out those people being able to 
> > use state of the art codecs that have no hope at all of 
> > running on minimal devices.  We're looking for a baseline 
> > that poses the minimal challenge to everything being able to 
> > support it, for the broadest scope of interoperability.
> > 
> > Things that can will always negotiate up from that.  What is 
> > the technical reason for setting the lowest bar so high that 
> > many of the supposed target devices will never be able to 
> > reach it?  There would seem to be few real barriers to making 
> > a more inclusive choice here, so why don't we just do that 
> > and move on?
> > 
> >   Ron
> > 
> > 
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >