[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] VC1 payload last call
Hello Anders, all,
Here are my comments to the VC-1 payload draft (04 version).
T1.
4.1 Access Units
...
- The AU payload MAY contain multiple EBDUs, e.g., a sequence layer
header, an entry-point header, a picture header and multiple
slices and the associated user-data. (However, all slices and
their corresponding macroblocks MUST belong to the same video
frame.)
...
4.2 Fragmentation of VC-1 frames
Each AU payload SHOULD contain a complete VC-1 frame.
What is the guideline for the relation of AU payloads and field pictures
- one field picture per AU payload or both field pictures of an
interlaced frame in an AU payload? Please clarify. In case of field
pictures/frames, please clarify which headers are allowed in an AU
payload.
T2.
4.3 Time stamp considerations
... The RTP timestamp field MUST be set to the
presentation time of the video frame contained in the first AU in the
RTP packet.
How is the presentation time of an interlaced frame defined? Please
clarify.
T3.
3.3 Decoder initialization parameters
It is stated in section 4.5 that there is a parameter in the entry-point
header that specifies the initial fullness (HRD_FULL) of the leaky
bucket the sequence layer header. The sequence layer header is present
only in the Advanced Profile bitstreams. For Main and Simple Profiles
the sequence layer data is provided by external means (through SDP/MIME
parameters according to the RTP payload draft). However, the initial
fullness of the leaky bucket usually changes in each random access
point. It would therefore be desirable that a mechanism to signal the
initial buffer fullness for each random access point would be specified
for Main and Simple Profiles too. I suppose the Buffer Fullness (BF)
syntax element of the picture header could be used for this purpose.
Could you add some sentences in section 3.3 (e.g. an informative note)
to clarify this issue. For example, add a new paragraph to the end of
section 3.3:
Informative note: The initial buffer fullness for an I-picture in the
Simple and Main Profile is signaled with the Buffer Fullness (BF) syntax
element that is present in the I picture header.
E1.
4.7 Signaling of media type parameters
...
"framerate" specify upper limits for these parameters. Thus, the
sequence layer header MAY specify values that that are lower than the
Remove one "that" of the two consecutive ones.
E2.
5.2 AU header syntax
...
RA Count: 8 bits
Random Access Point Counter. This field is a binary modulo
256 counter. The value of this field, MUST be incremented by
1, each time an AU is transmitted where the RA bit in the AU
Control field is set to 1. The initial value of this field
is undefined and MAY be chosen randomly.
Remove commas, i.e. new paragraph:
Random Access Point Counter. This field is a binary modulo
256 counter. The value of this field MUST be incremented by
1 each time an AU is transmitted where the RA bit in the AU
Control field is set to 1. The initial value of this field
is undefined and MAY be chosen randomly.
Best Regards,
Miska Hannuksela
>-----Original Message-----
>From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
>Behalf Of ext Stephan Wenger
>Sent: 21 December, 2005 23:13
>To: 'Colin Perkins'; avt at ietf.org
>Subject: [AVT] VC1 payload last call
>
>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
>avt at ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt