Subject: [AVT] SVC Design team - May 6th meeting summary

From: "Even, Roni" <[email-masked]>
Date: Wed, 14 May 2008 23:01:02 +0300

Hi,

The SVC design team continues to meet every two weeks. For the last meeting we did not have a new revision of the SVC draft but tried to discuss some of the open issues.

The following list gives the issue and the design team views. 

1. In the PACSI NAL unit, the presence of the fields TL0PICIDX (8 bits) and IDRPICID (16 bits) are optional (depends on the value of the Y bit), and the bits A, P, C, S, and E are always present but their semantics are specified only when the X bit is equal to 1. Should the presense and semantics of these fields and bits be mandatory? 

Result: The group thinks that one flag will be enough to specify if the two fields exist or not. Jonathan will prepare text to define the semantics

2. Non-VCL NAL units, e.g. SEI messages and parameter sets, may be needed by an enhancement layer but not the base layer. However, according to SVC, within an access unit, these non-VCL NAL units must precede VCL NAL units in decoding order. In session multiplexing, should non-VCL NAL units be transported in the same session as the layer that requires the non-VCL NAL unit, or should they be always transported in the base session? Does it make sense to allow a MANE to include all of the non-VCL NAL units within all the sessions?

Result: The group believes that the solution should allow non-VCL to be carried in the base or the enhancement layer. Jonathan will prepare text describing both modes and some justification when to use each of them. He will also address open issue 4 (NAL unit type 14 and 15). The consensus was also to allow non-VCL NAL units to be carried in all layers.

Carrying the non-VCL NAL units in the enhancement layer will need some text explaining how to synchronize on enhancement layer. For example a receiver who only uses the base layer decide also to use one enhancement layer from a broadcast, how does he get the parameter sets if they are only in the enhancement layer?

3. Do we need the media type parameter sprop-spatial-resolution for offering/answering spatial scalable layers?

Result:  There was no final decision here, YK will give some more text about the requirements and will also look at 3GPP use case. The question from Roni is if the model is for the sender to offer all his operation points and the receiver will chose or it is the other way when the receiver ask for an operation point and the sender can either supply it or can decline giving some close operation points that it can support. 

4. Shall we allow NAL unit types 14 and 15 (i.e. prefix NAL unit and subset SPS) to be present in the RTP stream carrying the T0 base Layer, when encapsulated using RFC3984?

Result: see issue 2

5. Do we allow the use of sprop-scalability-info, which contains the scalability information SEI message, in offer/answer?

Result: in general being able to negotiate operation point we need some more information about the negotiation model, is it an offer from the sender or is it a request from the receiver.

We would like to have a new revision of the text for the next meeting. Thomas will not be able to work on the draft (vacation) so YK will have the token as editor and will update the text on multiplexing for the next meeting.  

The next meeting is on May 20.

Time: 17:00 Israel (Jerusalem)

Dial in number: +1-678-7955235

Regards

Roni Even

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