Re: [AVT] Cross-layer decoding order

Colin Perkins <csp@csperkins.org> Tue, 19 February 2008 23:02 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 798D53A6B18; Tue, 19 Feb 2008 15:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.016
X-Spam-Level:
X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=-0.579, 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 LJ7olJKfVz+o; Tue, 19 Feb 2008 15:02:44 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8975A28C437; Tue, 19 Feb 2008 15:02:44 -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 9C02C3A6B91 for <avt@core3.amsl.com>; Tue, 19 Feb 2008 15:02:42 -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 Yav-znkvm0iG for <avt@core3.amsl.com>; Tue, 19 Feb 2008 15:02:41 -0800 (PST)
Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id F2CB628C4D9 for <avt@ietf.org>; Tue, 19 Feb 2008 15:01:40 -0800 (PST)
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62424 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1JRbSx-00073B-G3; Tue, 19 Feb 2008 23:01:35 +0000
In-Reply-To: <44C96BEE548AC8429828A3762315034742E9F1@vaebe101.NOE.Nokia.com>
References: <683204CAF7155443BC14CEAEC009FCA603711DC8@E03MVY1-UKDY.domain1.systemhost.net><6B55710E7F51AD4B93F336052113B85F1258A8@be150.mail.lan> <C83593C8-7E19-48CE-A3A2-AB7F8C5813A4@csperkins.org> <44C96BEE548AC8429828A3762315034742E9F1@vaebe101.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <BB980C49-6E9F-45DE-A282-56453CC3217E@csperkins.org>
From: Colin Perkins <csp@csperkins.org>
Date: Tue, 19 Feb 2008 23:01:34 +0000
To: Ye-Kui.Wang@nokia.com
X-Mailer: Apple Mail (2.753)
Cc: mike.nilsson@bt.com, jonathan@vidyo.com, avt@ietf.org
Subject: Re: [AVT] Cross-layer decoding order
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

On 16 Feb 2008, at 22:18, <Ye-Kui.Wang@nokia.com> wrote:
>>> 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?
>>
>> That's an interesting idea. If there are sufficient
>> commonalities between the different payload formats, it makes
>> sense to use a common mechanism if such a thing is possible
>> (perhaps either an extension to the RTP header, or a common
>> building block used in different payload headers).
>
> There are at least three existing drafts (the SVC payload draft,  
> the MVC
> payload draft, and the EVBR payload draft) that are common in this
> regard.
>
> Having an extension to the RTP header is what Mike has proposed  
> earlier.
> If this is viable, it would be the cleanest solution in the long run,
> and it will reduce a lot the document complexity for scalable codec's
> RTP payload drafts. The only problem is when an RFC for this can be
> available to enable SVC deployment.

We've had a requirement since RFC 1889 that the header extension be  
ignorable without affecting correctness, so I don't think we can use  
it for this role (although I understand the desire to do so).

> Having a common block used in different payload headers is not easy or
> impossible to achieve, because the SVC and MVC draft are both based on
> RFC 3984 and are required to be backward compatible to RFC 3984. If  
> all
> the scalable codecs are, like the EVBR codec, developped from scratch
> and not based an existing codec, then a common buidling block in  
> payload
> headers is then easy to achieve.

I'm less concerned with the format of the bits in the header, than in  
the semantics. Having common semantics across formats would be  
incredibly useful - the exact syntax of the bits is less important.

-- 
Colin Perkins
http://csperkins.org/


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