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

[Colin Perkins <[e-mail]>]

On 11 May 2007, at 20:50, [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt