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

From: "Anders Klemets" <[email-masked]>
Date: Wed, 7 Dec 2005 09:34:02 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Dec 2005 17:14:37 +0100

Hi Anders,

> and didn't see anything similar being mentioned there. Did you mean a

Yes, sorry, I meant RFC 3640 that contains such paragraphs in its 
security consideration section.

> deal with it in some other way.

I think that should be clarified to enable the best possible error 
robustness.

> to certain profiles, because I think that might make it more complex.

Which I think was a good choice. Keep it as general applicable as possible.

> always has to accept what the server sends, or drop out from the RTP

I don't think that is a good feature due to the mid running need to 
reconfigure screens etc. I think also in the declarative case should the 
sender of the SDP abide its own restrictions in width and height. If 
using advanced profile, then declare width and height to be the largest 
possibly used. The configuration information would then tell the client 
exactly which applies to the currently used sequence layer.

If I understand it correctly, semantic the largest possibly used height 
and width is equal to the actual sequences values for main and simple 
profile. Thus no contradiction in this case.

> buffer, so those parameters won't need to be explicitly stated. 

Yes, values are not needed to be stated, unless the declaring party is 
expressing a voluntary reduction of these values which I think can be 
quite useful in many applications.

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]