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
- [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00.txt Internet-Drafts
- Re: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00… Colin Perkins
- RE: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00… Miller, William C
- Re: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00… Kobayashi Katsushi
- RE: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00… SOLLAUD Aurelien RD-TECH-LAN
- Re: [AVT] I-D ACTION:draft-ietf-avt-rfc3189bis-00… Colin Perkins