RTP Payload Format for ITU-T Rec. H.263 Video
RFC 4629
Yes
No Objection
Recuse
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert No Objection
page 13: "Monotonically increasing (modulo 16) 4 bit number" - is this really what is required, or do they require the stronger "increasing consecutive integers?" Maybe Magnus as the reviewer can clarify? (I just had a different draft where this mattered, may not matter here.)
(Cullen Jennings; former steering group member) Yes
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) (was Discuss) No Objection
From Gen-ART review by Michael Patton: In the beginning of Section 3 it refers to the "payload header" definition being in Section 3. I believe this was meant to refer to Section 5. ... Immediately after the confused reference to Section 3, that I above note probably meant to be 5, it talks about "the usage of the RTP fixed header" being in "this section", which I take to be a reference to the whole of section 3, but following after the previous confusion, the referent is just not clear. The second bullet item in Section 4 has a "should" that probably meant to be a "SHOULD". A casual search through the document shows other places where 2119 words are used in the 2119 sense, but not capitalized. The first paragraph of Section 5 refers to "the basic payload header". But that's the only occurrence of the word "basic" in the document. I think it meant to refer to the "General" header described in 5.1. If so, replace the word "basic" with "general" and add "defined in 5.1" after it. In section 8.1.1 discussing parameters for indicating Annex support, "FIJT" can indicate "not supported" either by not being present or by explicitly as (for example) "F=0". For consistency, I would suggest allowing "KNP" to also use "=0" to indicate "not supported". Specifying 29.97 as the default for CPCF seems odd given that all the rest of the spec tries so hard at being non-preferential, but that clearly makes it prefer NTSC to PAL or film or anything else... But, I guess you had to pick some default. the only unbiased choice is to make it required which you can't... There are occurrences of both "RFCxxxx" and "RFC yyy" which are, I expect, meant to be self referential. There should have been a "Note to RFC Editor" about this. (And it would have been nice if they'd all been the same, making the RFCed search-and-replace only once.) ---------------------------------------------------------------- The following editorial issues are noted for the convenience of possible copy editors but are not part of the technical review. Clarity ------- Since both the 1998 and 2000 versions of H.263 are referred to, shouldn't they both appear in the references? Typos ----- In Abstract: "document also describe" => "document also describes" In 3.1: "those timing information" => "that timing information" In 4: "in such cases in which" => "in cases in which" Which is still pretty stilted language and a somewhat more extended rewording might be called for. In 5.2: "damage of individual frame" => "damage to an individual frame" In 5.2 the picture for the VRC layout has a shifted header. In 8.1.1 (six times): "Permissible value are" => "Permissible values are" it was also hard for me to parse the descriptions, perhaps the addition of parens could help, i.e. "maximum frame rate of 29.97/ the specified value frames per second." => "maximum frame rate of (29.97 / the specified value) frames per second." In 8.1.1: "A system that support a" => "A system that supports a" In 8.1.1: "specify it support" => "specify its support" In 8.1.1: "than the stream" => "then the stream" In 8.1.1: "a number fro 1 to 4" => "a number from 1 to 4" In 8.1.1: 'SHALL have the values "1"' => 'SHALL have the value "1"' In 8.1.2, the def for INTERLACE appears to either have extra words or missing words, or maybe just missing punctuation. In any case, I couldn't parse it into meaningful English...although from experience I know what it means to say... In 8.2.1: "when send in a" => "when sent in a" In 8.2.1: "support a profile" => "supports a profile" In 8.2.1: "is able of" => "is capable of" (I think)
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Title speaks about 1998 version and H.263+, but introduction indicates 2000 version and H.263++ are also supported. It might have been more informative to put both of these into the title. But its quite long already, so maybe you already considered this idea and dismissed it. Related to IANA's comments in the tracker: I do not understand why Section 8.2 is under IANA considerations. It does not appear to make any IANA registrations or create new namespaces. It simply talks about the negotiation of this codec over SDP. For instance, there's a discussion of allowed clock rate values, picture sizes, etc. Move elsewhere? Or if there are SDP namespace additions, they should be made clearer. > The document also describe the syntax and semantics of the SDP s/describe/describes/ > 3. Mandate the usage of RFC2429 for all H.263. RFC2190 payload > format should be used only to interact with legacy systems. I did not understand the first statement. Did you mean that you will mandate this new specification for all H.263?
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sam Hartman; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
(Magnus Westerlund; former steering group member) Recuse