RE: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00.txt

"Miller, William C" <William.C.Miller@abc.com> Thu, 24 May 2007 14:50 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEdj-0004W4-Fr; Thu, 24 May 2007 10:50:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEdi-0004Vz-9V for avt@ietf.org; Thu, 24 May 2007 10:50:06 -0400
Received: from mail12.disney.com ([192.195.66.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrEdg-0000C3-R8 for avt@ietf.org; Thu, 24 May 2007 10:50:06 -0400
Received: from imr12.disney.pvt (imr12.disney.pvt [153.6.60.115]) by mail12.disney.com with ESMTP; Thu, 24 May 2007 14:46:27 Z
Received: from sm-flor-xgw02b.wdw.disney.com (sm-flor-xgw02b.wdw.disney.com [153.6.172.148]) by imr12.disney.pvt with ESMTP; Thu, 24 May 2007 14:46:26 Z
Received: from sm-flor-xrc02.wdw.disney.com ([153.6.172.139]) by sm-flor-xgw02b.wdw.disney.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 10:46:26 -0400
Received: from sm-nyny-xrc02b.nena.wdpr.disney.com ([167.13.137.111]) by sm-flor-xrc02.wdw.disney.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 10:46:26 -0400
Received: from SM-NYNY-VXMB01B.nena.wdpr.disney.com ([167.13.137.132]) by sm-nyny-xrc02b.nena.wdpr.disney.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 10:46:25 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00.txt
Date: Thu, 24 May 2007 14:46:24 +0000
Message-Id: <13C9C98A375E9144B63166DE03B6D55E01B158AA@SM-NYNY-VXMB01B.nena.wdpr.disney.com>
In-Reply-To: <0382758C-80E3-48CE-8996-E0412290920E@csperkins.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00.txt
Thread-Index: Aced+WhjMhzOX7KFRgWdEpO6347cPAAFpcHg
From: "Miller, William C" <William.C.Miller@abc.com>
To: Colin Perkins <csp@csperkins.org>, Kobayashi Katsushi <ikob@ni.aist.go.jp>, Kazuhiro Mishima <three@sfc.wide.ad.jp>, Steve Casner <casner@acm.org>, Carsten Bormann <cabo@tzi.org>
X-OriginalArrivalTime: 24 May 2007 14:46:25.0512 (UTC) FILETIME=[4DCB5680:01C79E12]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.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: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

Colin,

I may be able to shed some light on 2.1.  It is helpful to remember that
the DV compression system was originally designed for
standard-definition interlaced TV systems and was optimized for video
cassette recorders.  It therefore has the field 1/field 2 structure of
interlace and the frame rate limitations of SMPTE 12M built into it.  

The frame structure of DV does not limit the temporal resolution of the
underlying video; rather, the video structure is mapped into the DV
frame/field structure.  All 50 or 60 (actually 59.94, but let's not
quibble) frames per second are recorded; frames within a pair are not
combined. This is clear from a reading of Clauses 3.7 and 4. 

The mapping and blocking into the original DV field structure makes it a
lot easier to use the electromechanical systems of a legacy VCR
transport for either HD or SD, progressive or interlaced.

Best regards,
Bill Miller

William C. Miller
ABC-TV

212-456-4448
212-456-2284 fax
william.c.miller@abc.com


-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
Colin Perkins
Sent: Thursday, May 24, 2007 7:47 AM
To: Kobayashi Katsushi; Kazuhiro Mishima; Steve Casner; Carsten Bormann
Cc: IETF AVT WG
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00.txt 

On 11 May 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for DV (IEC 61834) Video
> 	Author(s)	: S. Casner, et al.
> 	Filename	: draft-ietf-avt-rfc3189bis-00.txt
> 	Pages		: 16
> 	Date		: 2007-5-11
> 	
>    This document specifies the packetization scheme for encapsulating
>    the compressed digital video data streams commonly known as "DV"  
> into
>    a payload format for the Real-Time Transport Protocol (RTP).  This
>    document Obsoletes RFC 3189.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3189bis-00.txt

I've reviewed this draft, and have a number of comments (many of  
which arise because procedures have changed since RFC 3189 was  
published):

The removal of SMPTE-306M as a valid format brings backwards  
compatibility issues, and I would suggest you consider retaining, in  
addition to SMPTE-370M. Please also add some discussion of backwards  
compatibility issues.

Section 2.1: I don't understand the comment that "the frame rates in  
the 720p is 30/25Hz not 60/50Hz, because two video frames data in the  
720p are processed as one DV frame in 370M". Can you clarify why this  
is done (I would have expected this for interlaced, not progressive)?

Section 2.2 (1st paragraph): in "Any number of DIF blocks may be  
packed into one RTP packet, except that all DIF blocks in one RTP  
packet must be from the same video frame", it might be clearer if the  
last "must" is changed to "MUST".

Section 2.2 (5th paragraph): "Audio is sent in a different stream if  
desired, using a different RTP payload type as L16". The "as L16" is  
added since RFC 3189, and places an unnecessary restriction (the  
audio can be sent using an RTP payload format). Please revert to the  
RFC 3189 text.

Section 3: this would be clearer written in a style similar to other  
recent payload formats (RFC 4749 section 6.2 is a good example). An  
"offer/answer considerations" section is also needed.

Section 3: examples should use RFC3330 compliant IPv4 addresses

Section 3: there should only be a single "a=fmtp:" line for each  
payload type in the examples. That is, use:

     a=fmtp:113 encode=SD-VCR/525-60 audio=none

instead of

     a=fmtp:113 encode=SD-VCR/525-60
     a=fmtp:113 audio=none

This problem is also in RFC 3189, so it would be worth adding a note  
to warn implementers that the incorrect version is likely to be seen.

Section 5: The media type registration rules have changed since RFC  
3189 was published. Please update this section following (and  
referencing) RFC 4855.

Editorial: page length is incorrect (and missing form feeds)

No 'Intended Status' listed for the draft

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



_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt