IETF Logo Mail Archive

Re: [rtcweb] Comment on Straw Poll replies

Tim Panton <tim@phonefromhere.com> Tue, 14 January 2014 12:36 UTC

Return-Path: <tim@phonefromhere.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 77E351AE0BE for <rtcweb@ietfa.amsl.com>; Tue, 14 Jan 2014 04:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6CrWrgIgzOge for <rtcweb@ietfa.amsl.com>; Tue, 14 Jan 2014 04:36:41 -0800 (PST)
Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2031AE0A8 for <rtcweb@ietf.org>; Tue, 14 Jan 2014 04:36:40 -0800 (PST)
Received: (qmail 50070 invoked from network); 14 Jan 2014 12:36:28 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 6914
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 14 Jan 2014 12:36:28 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 7FA4E18A0B45; Tue, 14 Jan 2014 12:36:28 +0000 (GMT)
Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 34A5718A060D; Tue, 14 Jan 2014 12:36:28 +0000 (GMT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B114B2D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Tue, 14 Jan 2014 12:35:29 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <2521C21F-8D06-4AB1-916A-B1861FB38F2A@phonefromhere.com>
References: <CAHp8n2kq+_uG=9XwoAGtRgqYU2Asc2Fv6RZ0aCW6cJi-LnhD+A@mail.gmail.com> <10390_1389365676_52D009AC_10390_2407_1_2842AD9A45C83B44B57635FD4831E60A06CBE540@PEXCVZYM14.corporate.adroot.infra.ftgroup> <52D0222F.4010006@bbs.darktech.org> <949EF20990823C4C85C18D59AA11AD8B112238@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAHp8n2=m3i77SNPZWmJchqVdg1c2WEJCt5g-pFRfmeWA2yV5xw@mail.gmail.com> <949EF20990823C4C85C18D59AA11AD8B114B2D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1827)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Comment on Straw Poll replies
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: Tue, 14 Jan 2014 12:36:43 -0000

On 14 Jan 2014, at 10:22, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:

> In those terms, I do not believe that is what they were showing, at least according to the reports I have seen.
> 
> Further, apart from any processing power, the critical issue is the delay involved in any conversion, and I have no figures for that from this demonstration, and I suspect you do not either. Given that you must receive frames to do the conversion, my belief is that we will still be talking both decode and encode delay at the conversion point of the order of 60 - 70 ms, whatever mechanism is used. That is a significant take from the limits specified in ITU Recommendation G.114.
> 
> Regards
> 
> Keith
> 

My experience of the existing mass h264 deployments in the mobile space is that they like to split the the audio and
video media paths. (You'd need to do this in any gateway to these legacy systems). 
This means that they can get out of sync. This would be made worse by transcoding the video leg.
Although there is a counter argument that they are already unacceptable, so 70ms won't make any difference.

T.

v2.23.0 | Report a Bug | By Email