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

[Kobayashi Katsushi <[e-mail]>]

Colin,

Thanks for reviewing. We will update to incorporate
feedbacks.

--
Katsushi Kobayashi



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

> 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