RTP Payload Format for VP8 Video
RFC 7741

Note: This ballot was opened for revision 08 and is now closed.

(Richard Barnes) (was Yes) Discuss

Discuss (2013-07-18 for -09)
Holding pending resolution of late LC comments.

(Ben Campbell) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2014-08-13 for -12)
No email
send info
I would prefer clearly listing the name of the references section as "Normative References", to make clear that all the references are required for understanding/implementation.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Stewart Bryant) No Objection

Comment (2013-07-16 for -09)
No email
send info
I am entering no objection on the basis of a short review which indicated no impact on the routing system.

(Gonzalo Camarillo) No Objection

Comment (2013-07-18 for -09)
No email
send info
Richard will hold this document until all comments have been addressed.

(Benoît Claise) (was Discuss) No Objection

Alissa Cooper No Objection

Comment (2015-09-15)
No email
send info
-- 4.2: Little confused as to why the I and L behavior is specified twice, e.g.:

"I: PictureID present.  When set to one, the PictureID MUST be present
      after the extension bit field and specified as below.  Otherwise,
      PictureID MUST NOT be present."

and

"The PictureID extension:  If the I bit is set to one, the PictureID
      extension field MUST be present, and MUST NOT be present
      otherwise."
      
-- 4.2: Why would the index values TL0PICIDX and KEYIDX start at random values?

-- 6.1: Seconding Pete's old comment that the normative requirements on use of max-fs and max-fr should appear somewhere other than the media type definition.

(Spencer Dawkins) (was Discuss) No Objection

Comment (2014-10-16 for -13)
No email
send info
I'm clearing because my first Discuss point about PID fields was addressed, and that was my major concern, but I didn't see any response via e-mail or changed text about my second DIscuss point on wrapping versus restarting at 0. 

It's not worth holding the document up for my second Discuss point, but if you meant to either tell me the Discuss point wasn't a problem or change text to address it, I missed that. 

Which could have happened, of course. 

For reference, that was as follows:

   TL0PICIDX:  8 bits temporal level zero index.  The field MUST be
      present if the L bit is equal to 1, and MUST NOT be present
      otherwise.  TL0PICIDX is a running index for the temporal base
      layer frames, i.e., the frames with TID set to 0.  If TID is
      larger than 0, TL0PICIDX indicates which base layer frame the
      current image depends on.  TL0PICIDX MUST be incremented when TID
      is 0.  The index SHOULD start on a random number, and MUST restart
      at 0 after reaching the maximum number 255.

   KEYIDX:  5 bits temporal key frame index.  The TID/KEYIDX octet MUST
      be present when either the T bit or the K bit or both are equal to
      1, and MUST NOT be present otherwise.  The KEYIDX field MUST be
      ignored by the receiver when the K bit is set equal to 0.  The
      KEYIDX field is a running index for key frames.  KEYIDX MAY start
      on a random number, and MUST restart at 0 after reaching the
      maximum number 31.

I'm not quite sure why PictureID says "MUST wrap" and TL0PICIDX and KEYIDX say
"MUST restart at 0". Are these the same thing (I would have thought so, but I'm
not the codec guy). If they are the same, and you could consider using one term
or the other in the document, that would be great. If they aren't the same,
please say more about that.

(Adrian Farrel) No Objection

Comment (2013-07-17 for -09)
No email
send info
Supporting Barry's Discuss

(Stephen Farrell) No Objection

Comment (2013-07-17 for -09)
No email
send info
I agree with the other discusses and comments. I also
got the impression this either hadn't been that
thoroughly reviewed or else had been so controversial
that folks maybe concentrated only on the difficult
parts and not on ovrerall clarity. I think it'd be
very good to get someone to do a pass over the whole
thing to improve clarity. If there weren't so many
other discusses I think this would have been one.

- section 3: where do I find out how to set up a
reference hierarchy?

- 4.1: "PID MUST NOT be larger than" 7 surely? Also
given the "SHOULD increment" doesn't that mean I can
send PIDs 0,3 and 7 only and that's ok? Do you want
that?

- 4.1: " If the X bit is 0, the extension bit field
MUST NOT be present, and all bits below MUST be
implicitly interpreted as 0." If X=0 then these
octets are not sent so the various flags are not
"bits" really. Suggest s/bits/values/ or similar.

- 4.1: I assume TL0PICIDX etc are defined somewhere.
Where?  Adding some references would seem to be
needed.

- 4.5: Why is this an example? That's confusing.  So
is the structure of 4.5 then 4.5.1.

- Please see the secdir review [1] which raises a
couple more minor issues.

[1] http://www.ietf.org/mail-archive/web/secdir/current/msg04030.html

(Brian Haberman) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2015-06-18 for -16)
No email
send info
Thanks very much for addressing all my comments.

The downref to RFC 6386 was not called out in the Last Call message; that's required in order to support a downref, unless the referenced document is in the downref registry (which 6386 isn't).  That means we'd need to re-run a two-week last call for that.  I'll leave it to the responsible AD to decide whether to do that or not.  No further blocking from me on the point.

(Ted Lemon) No Objection

Comment (2013-07-17 for -09)
No email
send info
In 4.1, in the caption for figure 1:
   The VP8 payload descriptor and VP8 payload header will be described
   in the sequel.  OPTIONAL RTP padding MUST NOT be included unless the
   P bit is set.

What does "will be described in the sequel" mean?   I looked for an antecedent earlier in the document, and was unable to locate one, and the word "sequel" never appears elsewhere in the document.   I presume this is referring to some follow-on document or later section in the current document, but that isn't clear from the text.   If by sequel you mean "sections 4.2 and 4.3" then you should just say that.   If you are using xml2rfc you can reference a section as described here: http://xml.resource.org/xml2rfcFAQ.html#anchor17

If you are using something other than xml2rfc, I would just say "is described in the following two sections" or else refer to the sections by title.

Also in 4.1:
   Timestamp:  The RTP timestamp indicates the time when the frame was
      sampled at a clock rate of 90 kHz.

Is the frame sometimes sampled at other clock rates?   I suspect you mean something like this:

   Timestamp:  The RTP timestamp indicates the time when the frame was
      sampled.   The granularity of the clock is 90 kHz, so a value of 1 represents
      1/90,000 of a second.

Also, the definition of timestamp doesn't say what the timestamp is relative to.  I think this would prevent interoperation, since absent any additional specification I can think of at least three times it could be relative to: the time the first packet was sent, the time since the beginning of the video at which the current frame occurs, or the time at which the preceding packet was sent.   I was going to make this a DISCUSS, but on reading section 4.5, it looks like this is the time of the frame relative to the beginning of the video, and I suspect implementors will figure this out.   However, I still think you ought to say explicitly.

Also:
   Sequence number:  The sequence numbers are monotonically increasing
      and set as packets are sent.

Do you mean "set in the order that packets are sent"?

At the beginning of 4.3:
   The beginning of an encoded VP8 frame is referred to as an
   "uncompressed data chunk" in [RFC6386], and co-serve as payload
   header in this RTP format.

I guess Barry already hassled you about this; I found it equally puzzling.

From 5.1:
   pictures.  The positive feedback method is useful for VP8 used as
   unicast.  The use of RPSI for VP8 is preferably combined with a

I almost think I know what "VP8 used as unicast" means, but I'm probably wrong.   Could you clarify this sentence?

   Here, First is the macroblock address (in scan order) of the first
   lost block and Number is the number of lost blocks.  PictureID is the
   six least significant bits of the codec-specific picture identifier
   in which the loss or corruption has occurred.  For VP8, this codec-
   specific identifier is naturally the PictureID of the current frame,

What is a macroblock address?   I suspect that this is a VP8-specific term, but it would help to say where the reader could find out more.   Also, searching back through the document I notice that the second paragraph of the introduction talks about "decomposition of frames into square sub-blocks of pixels" and subsequently mentions macroblocks; are macroblocks these square sub-blocks of pixels?   If so, you should say "square sub-blocks of pixels, called macroblocks," so that the reader can clearly see the connection, rather than having to infer it and be uncertain whether the inference is correct.

In section 7:
   Integrity of the RTP packets through suitable
   cryptographic integrity protection mechanism. 

Where is the verb?

Thanks for documenting this!

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-09-16)
No email
send info
Why is this a SHOULD:
Applications SHOULD use one or more appropriate strong security mechanisms.

Wouldn't it be more helpful to point out why you would use specific security mechanisms for security considerations?

(Pete Resnick) No Objection

Comment (2013-07-17 for -09)
No email
send info
4.1:

   Sequence number:  The sequence numbers are monotonically increasing
      and set as packets are sent.
      
I think you mean "strictly increasing". "Monotonically increasing" can (in some circles) mean "nondecreasing".

6.1:

      max-fr, max-fs  These parameters MAY be used to signal the
         capabilities of a receiver implementation.  These parameters
         MUST NOT be used for any other purpose.

Putting MAY and MUST NOT like directives *inside* of the media type registration is a way to get them lost. They should be part of the spec. I suggest just moving the above to somewhere else in section 6.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection

Comment (2013-07-18 for -09)
No email
send info
In support of Barry's discuss.

(Joel Jaeggli) Abstain

Comment (2013-07-16 for -09)
No email
send info
This document would probably be fine were it not for the obvious problems citied in the genart review and the other discusses. imho I have nothing more to add, I wouldn't object to the document were it actually  ready.