Re: [rtcweb] Stephan Wenger's choices

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Thu, 02 January 2014 11:12 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
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 F2F471AE605 for <rtcweb@ietfa.amsl.com>; Thu, 2 Jan 2014 03:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] 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 JaGcQe9DVDBX for <rtcweb@ietfa.amsl.com>; Thu, 2 Jan 2014 03:12:54 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id CB0841AE600 for <rtcweb@ietf.org>; Thu, 2 Jan 2014 03:12:53 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s02BCfN1009023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Jan 2014 05:12:42 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s02BCdEa006474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jan 2014 12:12:40 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 2 Jan 2014 12:12:39 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Ron <ron@debian.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Stephan Wenger's choices
Thread-Index: AQHPA+475bje5FxTBkSHUp91LX7/fpppyiSAgAATXgCAAA2ZAIAAIp+AgAMWEjCAAATJgIAEIRwg
Date: Thu, 02 Jan 2014 11:12:39 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0FE716@FR712WXCHMBA11.zeu.alcatel-lucent.com>
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> <20131230204917.GO3245@audi.shelbyville.oz>
In-Reply-To: <20131230204917.GO3245@audi.shelbyville.oz>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 02 Jan 2014 11:12:58 -0000

1)	My original mail was sent "over a shitty mobile connection" but it was sent using the normal screen of my laptop, not "on a 4 inch screen". Use of mobile is dependent on circumstances of the user, and does not predicate what will be used to render to the user.

2)	You are making the assumption that communication mechanism attempted by the user is the best available, and that the way you interpret the media to be used is the best usage of the bandwidth for that purpose. When the only description supplied by the user for that media is "video", that encompasses a large range of possible use cases and it is inadvisable to assume that any video will do. The signalling does not indicate that there is a deaf person in the car with me, and therefore you should not assume the use case has to encompass that unless I explicitly say so. Until I actually explicitly signal something, my expectations could be at one extreme or the other.

I stand by my original comment.

Regards

Keith

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron
> Sent: 30 December 2013 20:49
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Stephan Wenger's choices
> 
> 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
> > > 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>