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

From: [email-masked]
Date: Fri, 11 May 2007 15:50:02 -0400

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-rfc3189bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rfc3189bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 24 May 2007 12:47:22 +0100

> 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/

---

From: "Miller, William C" <[email-masked]>
Date: Thu, 24 May 2007 14:46:24 +0000

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
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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 

instead of

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

---

From: Kobayashi Katsushi <[email-masked]>
Date: Fri, 25 May 2007 09:42:28 +0900

Colin,

Thanks for reviewing. We will update to incorporate
feedbacks.

--
Katsushi Kobayashi

On 2007/05/24, at 20:47, Colin Perkins wrote:

> 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)?
>
> 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.
>
> 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.
>

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Fri, 25 May 2007 10:20:19 +0200

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

Hi

For this one, we generally use "a semicolon separated list of
parameter=value pairs" (RFC4855).
Si I suggest
   a=fmtp:113 encode=SD-VCR/525-60; audio=none

Aurelien

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 May 2007 09:38:43 +0100

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

My mistake - you're right, of course.

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