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

[Magnus Westerlund <[e-mail]>]

Hi Anders,

Anders Klemets wrote:
> 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?

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

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

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

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

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

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

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.

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

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 [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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