Subject: [payload] FW: WGLC on draft-ietf-payload-rfc3189bis-00 - askin for reviews!!!!

From: Roni Even <[email-masked]>
Date: Sat, 28 May 2011 09:02:59 +0300

Hi,

I have not seen any feedback in the list.

Please find some time and review the draft

Thanks

Roni Even

Payload co-chair

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roni Even
Sent: Wednesday, May 11, 2011 10:56 AM
To: [email-masked]
Subject: [payload] WGLC on draft-ietf-payload-rfc3189bis-00

Hi,

I would like to start a Working Group Last Call on
draft-ietf-payload-rfc3189bis-00
<http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-00> , RTP Payload
Format for DV (IEC 61834) Video.

The WGLC will end on May 30, 2011

Please review the draft and send comments to the list.

Note that section 7 discusses the changes from RFC3189.

Roni Even

Payload co-chair

---

From: Glen Zorn <[email-masked]>
Date: Sat, 28 May 2011 17:27:54 +0700

A number of acronyms are neither expanded upon first usage nor listed in
a separate terminology section.  Examples: DV, DCT, PCM, DIF...

Section 1 says:

   This document specifies payload formats for encapsulating both
   consumer- and professional use DV format data streams into the Real-
   time Transport Protocol (RTP) [RFC3550].

I think that either the hyphen after the word "consumer" should be
removed or one should be appended to the word "professional".

Section 2.2 says:

   Timestamp: 32-bit 90 kHz timestamp representing the time at which the
   first data in the frame was sampled.  All RTP packets within the same
   video frame MUST have the same timestamp.  The timestamp SHOULD
   increment by a multiple of the nominal interval for one DV frame
   time, as given in the following table:

   +----------+----------------+---------------------------------------+
   |   Mode   |   Frame rate   |   Increase of one DV frame in 90kHz   |
   |          |      (Hz)      |               timestamp               |
   +----------+----------------+---------------------------------------+

One assumes that the term "nominal interval for one DV frame time" maps
to the table heading "Increase of one DV frame in 90kHz timestamp" but
this is by no means clear.

In the table itself, the last two lines include the construct "(*)"
which I would expect to refer to a note marked with "*":

   |  720-60p |      59.94     |                3003(*)                |
   |  720-50p |       50       |                3600(*)                |

However, there are no further occurrences of "*" in the document.  There
is the following, which might be divined to be associated with the table
entries mentioned above:

   Note that even in the 720-line DV system, the data in two video
   frames shall be processed within one DV frame duration of the 1080-
   line system.  Audio data and subcode data in the 720-line system are
   processed in the same way as the 1080-line system.  Therefore in the
   720-line system, the increase of one DV frame corresponds two video
   frames time.

What does the last sentence mean?

s/Marker bit (M): The marker bit of the RTP fixed header is set to one
on the last packet of a video frame, and otherwise, must be zero./Marker
bit (M): The marker bit of the RTP fixed header is set to one on the
last packet of a video frame, and otherwise, MUST be zero.

In Section 2.3, paragraph 2, cannot parse "sending DIF- sequence header
and subcode DIF blocks".

I'm a little confused by the "Optional parameters" part of the Media
Type Registration for DV Audio (Section 3.1.2).  It says:

   Optional parameters:

      audio:  whether the DV stream includes audio data or not.
         Permissible values for audio are bundled and none.  Defaults to
         none.

Since the media type is audio, how can no audio data be present?

Section 6 says:

   This document updates RFC3189 (older version of this document),

but the front page header says "Obsoletes: 3189 (if approved)".  Which
is it?  Further, this phrase doesn't make a lot of sense to me:

   and some registration forms are just updated by this document.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 28 May 2011 15:50:16 +0200

> a separate terminology section.  Examples: DV, DCT, PCM, DIF...

Yes, it is probably worthwhile to add an abbreviations section.

> removed or one should be appended to the word "professional".

Probably the latter.

>   time, as given in the following table:

(It's kind of clear if you have read RFC 3551.)
Maybe we should reword table head to

Increase of 90kHz timestamp per DV frame

> What does the last sentence mean?

Maybe it should be rephrased:

  Therefore in the
  720-line system, the timestamp increase given in the third column corresponds to two video
  frames time.

> last packet of a video frame, and otherwise, MUST be zero.

Yes.

> In Section 2.3, paragraph 2, cannot parse "sending DIF- sequence header

s/DIF- /DIF-/

The intent is:
When you unbundle, you send these special DIF blocks with the video half, not with the audio half.

So, maybe we should rephrase:

When unbundled audio and video streams are sent, any DIF-sequence header
and subcode DIF blocks to be sent MUST be included in the video stream.

> Since the media type is audio, how can no audio data be present?

Indeed, the audio format parameter should be on video streams only.

>   and some registration forms are just updated by this document.

No, this replaces ("obsoletes") 3189; we need to fix the "updates" wording.

Thanks, Glen, for this attentive review!

Gruesse, Carsten

---

From: Glen Zorn <[email-masked]>
Date: Sun, 29 May 2011 10:12:31 +0700

On 5/28/2011 8:50 PM, Carsten Bormann wrote:

...

> (It's kind of clear if you have read RFC 3551.)

Maybe to you...

> Increase of 90kHz timestamp per DV frame

Sorry, I guess that my comments may have lacked clarity: what I'm saying
is that it would be much clearer if the text and table heading matched:
either change "nominal interval for one DV frame time" to "increase of
the 90kHz timestamp per DV frame" or vice versa.  Basically, I want to
be able to think less about a table than the surrounding text, but in
this case I had to think more about it.

...

>   720-line system, the timestamp increase given in the third column corresponds to two video

That's better, I think.

...

> and subcode DIF blocks to be sent MUST be included in the video stream.

Much better, I think!

...

---

From: Katsushi Kobayashi <[email-masked]>
Date: Mon, 30 May 2011 00:20:23 +0900

Glen,

Thank you for your clarification. We will update our draft.

> this case I had to think more about it.

----
Katsushi Kobayashi