Subject: [AVT] VC1 payload last call

From: "Stephan Wenger" <[email-masked]>
Date: Wed, 21 Dec 2005 23:13:08 +0200

Hi Anders, Colin, folks,

the WG-LC caught us a bit by surprise -- things are moving faster than we
thought.  But given the DVB-H constraints, the timing is perhaps
unavoidable.  I'm going on vacation tomorrow and will be back only after New
Year.  Miska is already unavailable, but be he will be commenting sometime
after Christmas.  Let's get the technology right in the remaining short
time.

Having received the updated IPR statement alleviates all my non-technical
concerns, and I'm now quite willing to work with you.  Officially speaking,
Nokia is very happy with the updated statement - let's keep it this way :-)
Please take the comments below in that faith.

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.

A few immediate technical concerns below.  None of them, I believe, are
difficult to address, and I would agree to a shortened second WG-LC period
if another WG-LC is necessary at all.

Regards,
Stephan

Topic 1, Congestion Control section missing

Recent RTP payload formats for media of variable bandwidth nature tend to
include a Congestion Control section.  Examples include RFC 4184, RFC4175
(in the security section), RFC 4103, and RFC 3984.  We have had significant
problems with RFC 3984 without that section, and I would not recommend an
IETF-wide review without it.  I suggest adding such a section, using RFC3984
as a template.  Instead of mentioning sub-sequences and stuff, you could
mention B frames as "disposable" content.

Topic 2, Media type registration: framerate
>From section 6.1:
         framerate: 
           The value is an integer greater than zero, specifying the 
           maximum number of frames per second in the coded bit stream, 
           multiplied by 1000 and rounded to the nearest integer value.  
           For example, 30000/1001 (approximately 29.97) frames per 
           second is represented as 29970. 
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 (because RTP timestamps are meant for that and because rounding of
the parameter value to the closest integer would cause a timing drift in the
rendering process).

Topic 3: picture types
>From section 3.1
3.1 VC-1 bit stream layering model 
    
   Each picture can be coded as an I-picture, P-picture, skipped 
   picture, or as a B-picture.  These terms are defined in section 2 of 
   this document and in section 4.12 of SMPTE 421M [1]. 

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

Topic 4: imprecise language re "pixel"
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".

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt