IETF Logo Mail Archive

Re: [AVTCORE] RTP/TFRC + FEC ?

"Ali C. Begen (abegen)" <abegen@cisco.com> Mon, 09 May 2011 16:58 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 C83ACE07F4 for <avt@ietfa.amsl.com>; Mon, 9 May 2011 09:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.047
X-Spam-Level:
X-Spam-Status: No, score=-9.047 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 lQwo+0FPPVnr for <avt@ietfa.amsl.com>; Mon, 9 May 2011 09:57:59 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id C7678E07F1 for <avt@ietf.org>; Mon, 9 May 2011 09:57:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2535; q=dns/txt; s=iport; t=1304960279; x=1306169879; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5LQ3f7coP8O9GylPVWqFrJdwDy/E6SHdN0ZRaC9PmxA=; b=bwlt8QSoNghGUjTJIFmMCH3iRi5oMOpeda+vcUhdSxC0JOMZ6+qY/vpu 0628N7rAsXXLT0Qq2U+j1lD9QOhqOGVTW3wHd4xHArHRNGzO5JRfD4Mzc Wgt4clwfExAHNBKWKNumVRzzz17HhixfCe6fiTKbiZc+9YoetxbM5Cm6b E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AooCAAYcyE2rRDoI/2dsb2JhbACXUo4uaA+IcaBNnX+GDASGQI1Wikw
X-IronPort-AV: E=Sophos;i="4.64,341,1301875200"; d="scan'208";a="353314577"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 09 May 2011 16:57:59 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p49Gvx49010496; Mon, 9 May 2011 16:57:59 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 09:57: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="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 09 May 2011 09:57:26 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EF518CE@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <1304951671.5654.12.camel@TesterBox.tester.ca>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVTCORE] RTP/TFRC + FEC ?
Thread-Index: AcwOVkrzKM1X2idiSAeRo8JaobjuXQAE3gZA
References: <1304729510.32275.29.camel@TesterTop4> <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com> <1304951671.5654.12.camel@TesterBox.tester.ca>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Olivier Crête <olivier.crete@collabora.co.uk>
X-OriginalArrivalTime: 09 May 2011 16:57:59.0480 (UTC) FILETIME=[4049C380:01CC0E6A]
Cc: avt@ietf.org
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: Mon, 09 May 2011 16:58:00 -0000

> -----Original Message-----
> From: Olivier Crête [mailto:olivier.crete@collabora.co.uk]
> Sent: Monday, May 09, 2011 10:34 AM
> To: Ali C. Begen (abegen)
> Cc: avt@ietf.org
> Subject: RE: [AVTCORE] RTP/TFRC + FEC ?
> 
> On Sat, 2011-05-07 at 11:47 -0700, Ali C. Begen (abegen) wrote:
> > > 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.
> 
> I saw vague allusions to using different SSRCs, but I couldn't find
> anything to signal that using SIP/SDP ?

RFC 5576 will help with that.
 
> > > 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.
> 
> It's not about overhead, it's about the fact that it will be two
> streams, each with its own TFRC state. And with TFRC I would assume that

Yeah but I'd imagine you would want to optimize your source and FEC bitrates somewhat jointly anyway. If your source rate is untouchable, then only your FEC rate will be variable. 

> two streams would get roughly twice the bandwidth of one stream (and I
> guess that's not appropriate).

You are right that it is not appropriate but I don't see why TFRC would get roughly twice the bw of one stream if you use two TFRC states. You can easily apply the TFRC limit on the source+FEC, and then try to allocate that bw between the source and FEC.

-acbegen

> 
> --
> Olivier Crête
> olivier.crete@collabora.co.uk
> Collabora Ltd

v2.23.0 | Report a Bug | By Email