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

["Anders Klemets" <[e-mail]>]

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