RE: [AVT] VC1 payload last call

> We need a MIME review, and soon.  However, some of our comments
pertain to
> the MIME subject; therefore, I would suggest not to ask for it right
now.

It seems that as soon as a WG Last Call starts, Magnus usually sends a
message to the ietf-types list to request a review of the Media Type
definition.  (Apparently this is a new formality that was introduced
fairly recently.)  But in this case, Magnus must have left for Christmas
vacation without sending the request.  In his absence, could Colin send
this request to the ietf-types list?

I understand that Nokia has at least one comment on the Media Type
registration section, but I think that does not mean that we must
postpone the review on the ietf-types mailing list.

>          framerate: 
>            The value is an integer greater than zero, specifying the 
>            maximum number of frames per second in the coded bit
stream,
>
> I suggest that the intended use of this parameter should be clarified.
We
> suppose that the parameter MUST NOT be used for pacing of the
rendering
> process 

As currently defined, I think it is impractical for someone to use the
"framerate" parameter for pacing, because the definition says it is the
_maximum_ frame rate.  At any given time, the actual frame rate may be
lower than specified, so any attempt to use it for pacing is not likely
to work.

However, I don't mind adding the clarification that you suggested, if
there is some other compelling reason to update the Internet-Draft.

> This list lacks BI-picture, specified in SMPTE 421M. Also section 2
> (abbreviations) lacks the BI-picture.  Please add.

A BI-picture is a just a special kind of B-picture.  I don't mention it
in version -04, because it adds nothing to the understanding of the RTP
payload format.  I actually did mention it in earlier versions of the
Internet-Draft, but removed it in an effort to focus on the relevant
stuff.  

I can put it back in though, if there is some other reason to revise the
Internet-Draft.

> In section 6.1 (Media type Registration), width, height, max-width,
and
> max-height are specified in terms of pixels. However, "pixel" is an
> ambiguous term, as the decoder outputs one luma picture and two chroma
> pictures, and a luma picture has a different size than the chroma
pictures
> in terms of pixels. Thus, we would recommend using term "luma sample"
> instead of "pixel".

I chose the term "pixel" because that is how the decoder initialization
parameters HORIZ_SIZE and VERT_SIZE are defined, in Annex J of SMPTE
421M.  For the case when the chroma pictures are smaller than the luma
picture, I seriously don't think that anyone would get confused and
think that "pixels" refers to the size of the chroma pictures.  This
comment is just nit-picking. 

But if I need to edit the Internet-Draft I guess I could replace the
word "pixel" with "luma sample (pixel in the luma picture)", or
something like that.

Anders

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt