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

["Allison, Art" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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.

> 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.

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.

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

> - 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.

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.

> - 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?

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.

> 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.

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


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

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