RE: [AVT] New draft-ietf-avt-mpeg4-simple-07

Franceschini Guido <Guido.Franceschini@TILAB.COM> Wed, 26 February 2003 10:40 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00357 for <avt-archive@odin.ietf.org>; Wed, 26 Feb 2003 05:40:21 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QAnnM29668 for avt-archive@odin.ietf.org; Wed, 26 Feb 2003 05:49:49 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAdrp29072; Wed, 26 Feb 2003 05:39:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAWRp28099 for <avt@optimus.ietf.org>; Wed, 26 Feb 2003 05:32:27 -0500
Received: from dns1.tilab.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00007; Wed, 26 Feb 2003 05:22:26 -0500 (EST)
Received: from iowa.cselt.it (iowa.cselt.it [163.162.4.49]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HAW00J0WVLHUA@dns1.cselt.it>; Wed, 26 Feb 2003 11:24:53 +0100 (MET)
Received: from iowa.cselt.it ([163.162.4.49]) by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 11:27:11 +0100
Received: from EXC2K05A.cselt.it ([163.162.36.101]) by iowa.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 11:27:11 +0100
Date: Wed, 26 Feb 2003 11:27:11 +0100
From: Franceschini Guido <Guido.Franceschini@TILAB.COM>
Subject: RE: [AVT] New draft-ietf-avt-mpeg4-simple-07
To: jan.vandermeer@philips.com, avt@ietf.org
Cc: avt-admin@ietf.org
Message-id: <3737D9839ED3D3408C73611BDA907A0419ED0A@EXC2K05A.cselt.it>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C2DD81.9F544291"
Content-transfer-encoding: 7bit
Importance: normal
Priority: normal
Thread-Topic: [AVT] New draft-ietf-avt-mpeg4-simple-07
Thread-Index: AcLdQyA9gY5bsFJuTrGFzCQg3ykaPgAPUOSQ
content-class: urn:content-classes:message
X-OriginalArrivalTime: 26 Feb 2003 10:27:11.0717 (UTC) FILETIME=[9F8D9150:01C2DD81]
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>

Jan,
 
unfortunately I have to disagree with the text you modified with respect to Colin's text.
I am fine with supporting early implementations, but the wording used is, IMHO, not suitable. More specifically you wrote:
 
   If the "constantDuration" parameter is not present, then Access 
   Units are assumed to have a variable duration, unless the AU-Index 
   is present and coded with the value 0 in each RTP packet. 
 
How can a receiver implement the rule above? Should it observe 1, 10, 1000 or infinite packets before determining that the "AU-Index is present and coded with the value 0 in each RTP packet" ?
 
What is the exact legacy that you want to support ? Maybe there is a different mechanism to support it. For example, a specific mode definition might IMPLY a specific "constantDuration" value, without writing this explicitely in the SDP.
Best regards

Guido Franceschini 

TILAB - Multimedia Division 
Via G.Reiss Romoli 274 
I-10148 Torino, Italy 
tel + 39 011 228 6137 
fax + 39 011 228 6299 

-----Original Message-----
From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com]
Sent: Wednesday, February 26, 2003 3:03 AM
To: avt@ietf.org
Cc: avt-admin@ietf.org
Subject: [AVT] New draft-ietf-avt-mpeg4-simple-07



Dear all, 

This is to let you know that I just submitted draft-ietf-avt-mpeg4-simple-07 for upload to the IETF. For your convenience I attached the draft to this email. 

Compared to -06 there are several editorial improvements. In addition, all comments provided by Colin are incorporated with one small difference. Colin suggested the following text on interleaving in 3.2.3.2 (page 17): 

    If the "constantDuration" parameter is not present, then Access Units
   are assumed to have a variable duration. In this case, the transmitter
   MUST use the AU-Index to encode the index information required for
   re-ordering, and the receiver MUST use that value to determine the
   index of the first AU in the RTP packet. ... 

I changed this to the following text, in order to accomodate "early implementations" that do not use the constantDuration parameter when transmitting constant duration AUs. 

   If the "constantDuration" parameter is not present, then Access 
   Units are assumed to have a variable duration, unless the AU-Index 
   is present and coded with the value 0 in each RTP packet. When 
   transmitting Access Units of variable duration, then the 
   "constantDuration" parameter MUST NOT be present, and the 
   transmitter MUST use the AU-Index to encode the index information 
   required for re-ordering, and the receiver MUST use that value to 
   determine the index of each AU in the RTP packet. ... 

From my perspective the document is ready now. All known comments are incorporated (Colin and Steve thanks for your help !) and therefore I think we are done, unless any further issues are identified. 

Best regards / Groeten,

Jan 



-----------------------------------------------------------
Jan van der Meer
Philips - MP4Net
Prof Holstlaan 4
Building WDB-1
P.O. Box 80021
5600 JZ Eindhoven
The Netherlands
Phone +31 402 735 774
Fax +31 402 735 545




====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to MailAdmin@tilab.com. Thank you
====================================================================