Re: [AVT] Comments on the major open issue of draft-ietf-avt-rtp-svc-07.txt, cross layer decoding order dependency

"Jonathan Lennox" <jonathan@vidyo.com> Mon, 11 February 2008 22:57 UTC

Return-Path: <avt-bounces@ietf.org>
X-Original-To: ietfarch-avt-archive@core3.amsl.com
Delivered-To: ietfarch-avt-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBEC928C8F3; Mon, 11 Feb 2008 14:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.742
X-Spam-Level:
X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK9N7MwEwSNN; Mon, 11 Feb 2008 14:57:42 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FED128C2C2; Mon, 11 Feb 2008 14:57:42 -0800 (PST)
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2691028C26F for <avt@core3.amsl.com>; Mon, 11 Feb 2008 14:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOoEielVnKDn for <avt@core3.amsl.com>; Mon, 11 Feb 2008 14:57:40 -0800 (PST)
Received: from mX1.myoutlookoNline.com (mx1.MyOutlookOnline.com [69.25.74.51]) by core3.amsl.com (Postfix) with ESMTP id 4BBA73A6CFB for <avt@ietf.org>; Mon, 11 Feb 2008 14:57:40 -0800 (PST)
Received: from be150.mail.lan ([10.109.208.150]) by mX1.myoutlookoNline.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Feb 2008 17:58:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 11 Feb 2008 17:58:36 -0500
Message-ID: <6B55710E7F51AD4B93F336052113B85F1258A8@be150.mail.lan>
In-Reply-To: <683204CAF7155443BC14CEAEC009FCA603711DC8@E03MVY1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on the major open issue of draft-ietf-avt-rtp-svc-07.txt, cross layer decoding order dependency
Thread-Index: AchcWBOtdxYRnl/ZQLy/J+Tiv/W/DQAlHItQAAlDlhADVn7D0AAB7tTgAKLF7EA=
References: <683204CAF7155443BC14CEAEC009FCA603711DC8@E03MVY1-UKDY.domain1.systemhost.net>
From: Jonathan Lennox <jonathan@vidyo.com>
To: avt@ietf.org
X-OriginalArrivalTime: 11 Feb 2008 22:58:52.0839 (UTC) FILETIME=[AC03E370:01C86D01]
Cc: mike.nilsson@bt.com
Subject: Re: [AVT] Comments on the major open issue of draft-ietf-avt-rtp-svc-07.txt, cross layer decoding order dependency
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

mike.nilsson@bt.com writes:
> The major weakness of the CL-DON method is that it is not backwards
compatible with the single NAL unit mode of RFC 3984.

Another weakness of the CL-DON method is that it does not support NAL
unit fragmentation in mode 1.  RFC 3984 FU-A packets cannot include a
CL-DON, since mixing aggregation and fragmentation isn't allowed.

Though it's better to avoid it if you can, there are scenarios where
fragmentation is needed, i.e. video being transmitted over a network
with an MTU lower than the video encoder expected.  If retransmission or
FEC is in use, RTP-layer fragmentation is hugely preferable to IP-layer
fragmentation of the RTP packet.


More architecturally, I wonder if cross-layer decoding is a question
that should be addressed in a generic manner rather than per-media.
Several drafts have been presented recently for audio codecs which do
session multiplexing in a very similar way to H.264/SVC, and they also
need to be able to indicate a global decoding order.  Should this be
addressed as a generic problem?

-- 
Jonathan Lennox
Vidyo, Inc (formerly Layered Media)
jonathan@vidyo.com

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
http://www.ietf.org/mailman/listinfo/avt