Re: [AVTCORE] RTP/TFRC + FEC ?

"Ali C. Begen (abegen)" <abegen@cisco.com> Sat, 07 May 2011 18:48 UTC

Return-Path: <abegen@cisco.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE94BE06BA for <avt@ietfa.amsl.com>; Sat, 7 May 2011 11:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.403
X-Spam-Level:
X-Spam-Status: No, score=-9.403 tagged_above=-999 required=5 tests=[AWL=-1.181, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0VuYh0EabO3 for <avt@ietfa.amsl.com>; Sat, 7 May 2011 11:48:01 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB4AE069E for <avt@ietf.org>; Sat, 7 May 2011 11:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2312; q=dns/txt; s=iport; t=1304794081; x=1306003681; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=PblyVeTsgqTfnTHdHfisSgPYmzxY7uUBUbuRRW1HlSY=; b=Wnq5eM89mOCK1RxBHJTV8PzxVySQkxZ3bF3GUq8lsVCCd872B+FydMdW GGe6P5DvYj70r4ZyT2v96eP26L61F5o2chg/nMg8fHRVfgLmO26Jm3YkH xlcR+po3mrYDml2ink944qdPZxQmZAEiTuUR/qw99UZr3OplmYicnvfey 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtUCAEKTxU2rRDoG/2dsb2JhbACEUpMgjT9zaA+IcZ0ijQKQI4Eqg2CBAgSGQI1Wikw
X-IronPort-AV: E=Sophos;i="4.64,331,1301875200"; d="scan'208";a="310655096"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 07 May 2011 18:47:59 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p47IlxkY013167; Sat, 7 May 2011 18:47:59 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 May 2011 11:47:59 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Sat, 07 May 2011 11:47:07 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <1304729510.32275.29.camel@TesterTop4>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVTCORE] RTP/TFRC + FEC ?
Thread-Index: AcwMUP5s7FlApcjFTRa1joYn+cMNFAAlcRBQ
References: <1304729510.32275.29.camel@TesterTop4>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Olivier Crête <olivier.crete@collabora.co.uk>, avt@ietf.org
X-OriginalArrivalTime: 07 May 2011 18:47:59.0892 (UTC) FILETIME=[499D3540:01CC0CE7]
Subject: Re: [AVTCORE] RTP/TFRC + FEC ?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 May 2011 18:48:02 -0000


> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Olivier Crête
> Sent: Friday, May 06, 2011 8:52 PM
> To: avt@ietf.org
> Subject: [AVTCORE] RTP/TFRC + FEC ?
> 
> Hi,
> 
> I've implemented the RTP/TFRC draft and it seems to work pretty well.
> That said, it also introduces some level of packet losses. Also, with
> some wifi connections, we have a relatively high rate of non-congestion
> packet loss. For both of these cases, I'd like to implement some kind of
> FEC, since losing a single packet tends to give nasty artifacts with
> video (especially using the free video codecs).
> 
> It seems the current tendency in recent RFCs related to FEC is to send
> the FEC data as a separate stream from the main data. This seems to go

That has a lot good features. Please see the drafts in fecframe wg. The fec framework draft will also tell you that both the source and fec packets can be sent in their own RTP streams (with different SSRCs) but within the same UDP flow, if that is what you are worried about.

> against the intent of RTP/TFRC since using a second stream may
> effectively double the bandwidth share used by the video. Mixing both

Huh? It does not matter at all for the overhead whether you send the fec packets separately or in-band. Also, FEC does not need to double the bandwidth.

-acbegen

> the video packets and the FEC packets in the same stream seems like a
> better idea to me for the unicast use-case. Is anyone implementing such
> an approach? Is there any standard around that? Or am I missing
> something?
> 
> --
> Olivier Crête
> olivier.crete@collabora.co.uk