Re: [rtcweb] Stephan Wenger's choices

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 30 December 2013 19:43 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 126E61AE21E for <rtcweb@ietfa.amsl.com>; Mon, 30 Dec 2013 11:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VmrpIKFCKc_I for <rtcweb@ietfa.amsl.com>; Mon, 30 Dec 2013 11:43:09 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 820621AE2D7 for <rtcweb@ietf.org>; Mon, 30 Dec 2013 11:43:09 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id rBUJgv17027027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Dec 2013 13:42:58 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBUJgtet017369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Dec 2013 20:42:55 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 30 Dec 2013 20:42:55 +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+AgAMWEjA=
Date: Mon, 30 Dec 2013 19:42:54 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0FDFAB@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>
In-Reply-To: <20131228212423.GJ3245@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: Mon, 30 Dec 2013 19:43:12 -0000

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. 

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.

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.

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.

Keith

> -----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
>