Subject: [AVT] Comments on draft-ietf-avt-rtp-vc1-02

From: Magnus Westerlund <[email-masked]>
Date: Wed, 07 Dec 2005 11:42:29 +0100

Hi Anders,

I have reviewed the complete draft and have a few question and comments. 
There are several topic in here that I think warrant discussion before 
you update the draft. Seeing forward to your comments and answers.

Technical

T1. Will it be possible to carry any type of active content (like 
scripts or Java code) in the VC-1 user data? If that is the case there 
must be a security considerations around this. RFC 3984 may be a start 
for such a statement in that case.

T2. Section 4: The AU packetization: I must have been reading what I 
wanted to read rather than what is written. Because it suddenly strikes 
me that this is a bit unusual compared to some of the other recent video 
codecs.

To verify the understanding: An AU contains a complete frame or field. A 
frame can consist of multiple EBDUs. Thus the RTP payload AU isn't the 
smallest decodable data unit. Instead the payload handles an aggregate 
of EBDUs from the same frame. There is a recommendation that the 
fragmentation is done at EBDU borders to potentially allow them to be 
used. My question arise here. Must the receiver do start code detection 
to determine these boundaries? Secondly will this always work as a 
method to use for example a slice, if that slice is complete?

T3. Section 4.7 and 6.1: The height, width, max-height, max-width 
parameters:

Currently I have several issues with these definitions:

- First I am missing a parameter that gives a normative binding 
statement about which will be the largest width and height that may 
occur in this session. This parameter must not be possible to override 
by new sequence layer headers, only new session setup signalling may 
change this one. This is to allow an application implementor to actually 
know which is the largest screen size it needs to be handled. Thus I 
don't find the statement that in the advanced profile it is possible to 
override particular good.

- Is it correct that the streams actual width and height is part of the 
config information (struct_c in simple and main profile) and the 
sequence layer header for advanced? Thus it being redundant as currently 
specified?

Thus my question to you Anders and the WG. Wouldn't it be better to 
specify height and width to be the global maximum over any used sequence 
and not having it overridable in the case of the advanced profile. For 
simple and main I don't think there will be any difference from how it 
is defined today as only a single set of parameters per payload type is 
possible to use.

I think this discussion applies also to buffer and frame rate parameters.

T4. Section 6.1: The lack of a "rate" parameter that determines the RTP 
timestamp rate. Currently the draft states that the RTP timestamp rate 
is 90000 or larger. However no media type parameter is defined for 
negotiating that, also offer/answer behavior around this is needed. The 
rate parameter is then mapped into "rtpmap"'s clock rate field. Unless 
you are fine with a single fixed clock rate there is a need for such a 
parameter.

T5. Section 6.1, Second paragraph of the level parameter:
           "Note that when Advanced
            profile is used, this parameter may only apply while the
            sequence layer header specified in the config parameter is in
            use."

This is one parameter I don't see as acceptable to override within a 
established session. If one has negotiated a particular profile and 
level for a payload type. Then a later sequence layer header may not 
come and override that level to a higher value. The application must be 
allowed to negotiate binding agreements about the amount of resources 
that may be used. Thus the negotiated profile and level is the highest 
one that may be used. A lower level within a profile may be used.

T6. Section 6.3:

    o The "level" parameter describes the level of the VC-1 profile of
      the coded bit stream that the offerer or answerer is sending for
      this media format configuration, when the direction attribute is
      sendonly or sendrecv.  If the direction attribute is sendrecv or
      recvonly, the parameter also specifies the highest level of the
      VC-1 profile that the receiver implementation accepts.

This definition contains an ambiguity as the definitions for sendrecv 
streams are contradicting. To align with the common interpretation of 
parameters, that they define what the receiver accepts to receive I 
would like to change this section. First of all I would move the second 
sentence into the first sentence. The special case of it applying in the 
sending direction for "sendonly" streams would be moved to the second 
sentence. It also could be changed to clarify that this indicates the 
highest level this sender intends/capable to send.

Secondly:
      "The answerer MUST NOT specify a numerically higher level in the
      answer than what was specified in the offer, regardless of the
      direction attribute.

      If an offer specifies the recvonly direction attribute, the
      answerer MAY specify a level that is lower than what was specified
      in the offer, i.e., the level parameter can be "downgraded"."

I think you can remove the limitation of "recvonly" if you change the 
meaning to be the highest level the agent accept to receive. That way 
the media sender may use a lower level but never a higher one.

Thirdly:
      "If the offer specifies the sendonly direction attribute, the level
      parameter cannot be downgraded by the answerer.  In this case, the
      answerer MUST either maintain the level parameter or remove the
      media format (payload type) completely if the level is not
      supported."

I think this definition results in unnecessary failure to communicate. I 
would think requiring a second round of invites to update the offerers 
config information is better then to fail to communicate when it is only 
the configuration information that is wrong.

Editorial Comments

E1. First of all I would request that you replace the usage of the 
abbreviation "MIME" with "media type" as I think in at least most of 
them  they refer to the media type rather than the "Multipurpose 
Internet Mail Extensions" which enables different content in email.

E2. Section 2, has a strange subject line, please try to get them correct.

E3. Section 4.3. As I understand this section intends to enable one to 
set the times correctly, however it doesn't reference the mechanisms 
used to provide the necessary times. For example it is not obvious if 
you need to use the decoding time offset value for P frames when they 
shall be decoded. Please clarify when you and which mechanisms of the 
payload format you need to use in 4.3

E4. Section 6.1:
I think the discussion on why one should use max-height and max-width 
should be clarified. To me any value lower than the profile maximum 
indicates that I as a receiver will not have any use of any higher 
resolution. However the receiver must be capable of scaling down, but 
that would be waisting resources. The usage to indicate higher values 
than profile level I don't have any opinion on.

E5. Section 6.1, bpic:
"If B-pictures will never be present in the coded bit stream,
            even if the sequence layer header changes, this parameter
            SHOULD be present and its value SHOULD be equal to 0. "

I think this formulation is a bit weak. I would prefer it to define it 
as being binding.

"A value of 0 indicates that B-pictures SHALL NOT be present in the 
codec bit stream, even if the sequence layer header changes. It is 
RECOMMENDED to include this parameter if no B-pictures will be included 
in the coded bit stream."

E6. Section 6.1, bpic:

"This parameter MUST not be used with Simple and Main
            profiles."

Please make the "not" in all upper case to make it a normative negative 
statement.

E7. I think there are a number of usages of MUST that would read better 
with SHALL. For example the last paragraph in section 6.1, for the bpic 
parameter:
"For Advanced profile, if this parameter is not specified, a
            value of 1 SHALL be assumed."

E8. Section 6.1, "mode" parameter: I think you defines the mode values 
better in section 4.8 and 4.9 and therefore should reference those 
definitions.

E9. Section 6.1, "max-width" parameter, end of page 21:
"If any of the parameters specifies a capability that is less
            than the required capabilities of the signaled profile and
            level, then the parameter SHOULD be interpreted as a
            preferred value for that capability."

What is the alternative interpretations that are allowed? See also E4.

E10. Section 6.1, Security consideration: Please replace "this document" 
with RFC XXXX.

E11. Section 6.1, Published specification: Please replace "This payload 
format specification with "RFC XXXX". The reason is that the Media 
registration should be possible to extract from the RFC and still be 
readable.

E12. Does VC-1 have a standardized file format with its own Media Type? 
In that case the Additional information section could include a pointer 
to that format.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 7 Dec 2005 14:35:04 -0500

User data might be constrained, but there legit (optional) uses for this
space, besides the ones defined by the VC-1 standard itself.
Example: Active Format Description (the aspect ratio of the image inside
the coded frame, especially where they are different, such as, the
common 4:3 in 16:9)<for that field>
Example: If the active video has a wider than 16:9 aspect ratio (i.e.
Cinemascope) exactly where the 'real' video starts and stops.<for the
field>
Example: In some systems, closed captioning data (e.g. CEA -708)  <a
part of a text flow related to the audio that goes with the video>

If one were to standardize carriage of active content, then perhaps
security considerations would be in order; but I fail to see any
validity to the assertion of a 'must' just because a logical space
exists for data.  Exploits of devices that are reading the user data
cannot be stopped by a standard anyway. One could insert a string of
profane words in the closed captions...I guess. I leave to others more
knowledgeable than I to address how one exploits a string of bytes with
no defined structure by inserting active content. 

Besides, this space exists in MPEG-2 (and AVC) so whatever is (was?)
done there should apply equally.  

______________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N St. NW
Washington DC 20036
202 429 5418

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Klemets
Sent: Wednesday, December 07, 2005 12:34 PM
To: Magnus Westerlund; IETF AVT WG
Subject: [AVT] RE: Comments on draft-ietf-avt-rtp-vc1-02

Magnus,

Thanks for your careful review.

> for such a statement in that case.

Yes, the VC-1 spec doesn't limit what could be put in the user-data
field.  But I checked the Security Considerations section in RFC 3984
and didn't see anything similar being mentioned there. Did you mean a
different RFC?

> To verify the understanding: ...
> My question arise here. Must the receiver do start code detection to 
> determine these boundaries? Secondly will this always work as a method

> to use for example a slice, if that slice is complete?

Your understanding about the AU is correct.  Normally, an AU will start
at an EBDU boundary.  But in some cases it might not (such as when the
frame is much larger than the network MTU.)  If the receiver cares to
distinguish between these two cases it can do so by checking the first
three bytes of the AU payload to see if they are equal to a start code
(i.e., 0x00, 0x00, 0x01).  Not all receivers may need to do this, as
some VC-1 implementations might not be able to handle frames in which
one or more EBDUs have been lost.

Please advise if you think I should add some text to explain this, or
deal with it in some other way.

> occur in this session.

In the Offer/Answer case, "width" and "height" is supposed to specify
the largest width and height.  It can't be changed later.  I will add
some text to clarify.

> sequence layer header for advanced? Thus it being redundant as
currently 

No, width and height information is not available in "config" (struct_c)
for Simple and Main profiles.  However, it is available in the "config"
parameter for Advanced profile.  
I chose not to define the "width" and "height" parameters only to apply
to certain profiles, because I think that might make it more complex.

> and not having it overridable in the case of the advanced profile.

I had already intended it to work this way for the Offer/Answer
scenario.  For the Declarative SDP scenario (e.g., RTSP or SAP),
however, the server can change the Advanced profile Sequence Header at
any time, and by doing so changing the width, height, level, bitrate and
buffer parameters.  

I am not sure if it is really a concern, because in RTSP and SAP, the
client is always in a "take it or leave it" situation.  The client
always has to accept what the server sends, or drop out from the RTP
session.

However, if you and/or the WG think that this needs to be changed, it
could be done in this way: The "level" parameter will specify the
maximum level that can ever be used in the RTP session.  The actual
level parameter used may be lower. (In Advanced profile, the "config"
parameter also specifies level information, so this may now indicate a
lower level.) A maximum level also implies a maximum width, height,
bitrate and buffer, so those parameters won't need to be explicitly
stated. 

Anders