|
Hi,
I have just read this document and have
some minor comments, hope it is not late to be taken into account.
1. Section 1:
[Qin]: It looks this version extends
RFC3189 to support some new features.
However I can not see any dependency to RFC3189 in the introduction section until I read the last section in this document, is it more straigtforward and clear to merge the section 7,8 to the introduction section and clarify how this document is different from RFC3189. 2. Section 3.1.1
"
3.1.1. Media Type Registration for DV Video
Type name: video Subtype name: DV
Required parameters:
encode: type of DV format.
Permissible values for encode
are
SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). "
[Qin]: In section 7, you claim you have
removed SMPTE 306M, since it is covered by SMPTE 314M format.
However in section 3.1.2, the value for SMPTE 306M is still kept in the encode list. So the question is where do you remove SMPTE 306M in this document? Why SMPTE 306M in the media type registration is still kept? Does this conflict with what you said in the section 7? The same comment applies in any place
of this document where SMPTE 306M is still kept.
3. Section 3.1.1
"
Optional parameters:
audio: whether the DV stream includes
audio data or not.
Permissible values for audio are bundled and none. Defaults to none. Encoding considerations:
DV video can be
transmitted with RTP as specified in
RFCXXXX
(This document). Other transport methods are not specified. Security considerations:
See Section 4 of RFCXXXX
(This document).
Interoperability considerations: NONE
"
[Qin]: Is it real that there is
no interoperability consideration since
Interoperability with Previous Implementations is discussed in the section 8 of this document? 4. Section 3.2.1
"
Note that the examples in RFC3189 (older version of this document) provides incorrect SDP "a=fmtp" attribute usage. "
[Qin]: I believe it is not appropriate
to spell this note out when this document is published but you may put
it as errata or in the section 7. 5. Section 3.2.1
"
The required parameter <DV-video encoding> specifies
which type of DV
format is used. The DV format name will be one of the following:
SD-VCR/525-60
SD-VCR/625-50 HD-VCR/1125-60 HD-VCR/1250-50 SDL-VCR/525-60 SDL-VCR/625-50 314M-25/525-60 314M-25/625-50 314M-50/525-60 314M-50/625-50 370M/1080-60i 370M/1080-50i 370M/720-60p 370M/720-50p 306M/525-60 (for backward compatibility) 306M/625-50 (for backward compatibility) "
[Qin]: Why you need to repeat the same
text in the section 3.1, why not just simply reference it described in the
section 3.1.
6. Section 3.2.1
"
In order to show whether the audio data is bundled into the DV
stream
or not, a format specific parameter is defined as below: "
[Qin]: s/ a format specifc parameter/ a
format of specific parameter
7. Section 3.2.1
" The optional parameter
<audio bundled> will be one of the following:
"
[Qin] s/one of the following/one
of the following value.
One question is: How do you distinguish between required parameter or optional parameter in the a=fmtp line? 8. Section 3.2.2
"
3.2.2. Usage with the SDP Offer/Answer Model
The following considerations apply when using SDP
offer-answer
procedures [RFC3264] to negotiate the use of DV payload in RTP: o The "encode" parameter can be used for sendrecv,
sendonly and
recvonly streams. Each encode type MUST use a separate payload type number. "
[Qin]: When you are talking about encode, you are using "encoding type","DV-video encoding", "type of DV format" in the section 3.2, and using "encode type" in section 3.2.2, should they be the same thing? why not use the same terminology for consistency? 9. Section 3.2.2
"
In an offer for unbundled streams, in order to associate the
related
audio and video, the group attribute as defined in the Session Description Protocol (SDP) Grouping Framework [RFC5888] can be used. "
[Qin]: Does it worth a exmaple to
expain how SDP Grouping Framework can be used to correlate audio with video data
in the section 3.3.1?
10. Section 3.3.1
"
When
this is done, SDP carries several m=?? lines, one for each media
type of the session (see RFC 4566). "
[Qin]: What do you mean "when this is done"? It is not clear to me from the context. Regards!
-Qin
----- Original Message -----
The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for DV (IEC 61834) Video' <draft-ietf-payload-rfc3189bis-02.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2011-09-26. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/ No IPR declarations have been submitted directly on this I-D. |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf