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

[<Ye-Kui.Wang at nokia.com>]

Thanks again! I further removed those items that are resolved or action
points agreed upon.
 
>>> 4. Section 5.1.2:
>>>
>>> "   RTP packet stream: A sequence of RTP packets with increasing
>>>   sequence numbers, identical PT and SSRC, carried in one 
>RTP session.
>>>   Within the scope of this memo, one RTP packet stream is 
>utilized to
>>>   transport an integer number of SVC Layers."
>>>
>>> I don't agree that the PT needs to be identical. However, for your 
>>> purposes I assume that it is great simpification not having 
>to think 
>>> about people using multiple PTs configured for carrying SVC 
>NAL units 
>>> for the same video sequence. I think you are introducing a 
>limitation 
>>> that doesn't need to exist, but has little practical value.
>>>
>> 
>> OK, will enable PT multiplexing in the new version. 
>
>I hope this only means that you will remove the restriction 
>you have entered, not recommending specific behaviors 
>regarding using multiple PTs.
>

OK.

>>> 8. Section 6.6:
>>>   [Ed.Note(YkW): I think we need more thinking on the
>>>   value of the parameters. For example, requiring the parameters be
>>>   the same for all the RTP streams and clients might be overkill for
>>>   receivers of only lower layers.]
>>>
>>>
>>>   [Edt. Note (StW): In RFC3984, the aforementioned codepoints are
>>>   optional.  It appears that for SVC, when used in conjunction with
>>>   session mux, they are mandatory.  I don't know how to express this
>>>   in the MIME registration; we'll cross that bridge once we are
>>>   getting to it.]"
>>>
>>>
>>> Assuming that you have multiple layers in multiple RTP 
>sessions. As I 
>>> see it the only good way of getting the buffer handling to 
>work will 
>>> be max-don-diff. That needs to be the same for all layers. However 
>>> deint-buf-req can increase and be the sum of all layers 
>included and 
>>> which there are dependencies from this session. That way 
>one can have 
>>> an increasing buffer requirement depending on the number of RTP 
>>> sessions being received in a multi-layer structure.
>>>
>> 
>> Requiring max-don-diff to be the same for all sessions could 
>have been OK, if madating of interleaved packetization in 
>layered multicast has not been relaxed in the Chicago meeting. 
>However, as now it has been agreed to allow for any 
>packetization mode for the base layer, therefore if the 
>session for the base layer does not use interleaved mode while 
>other sessions use interleaved mode, max-don-diff cannot be 
>identical for all the sessions. 
>> 
>> Personally, I think each session should have their own 
>parameters, optionally, as in RFC 3984. A receiver that 
>subscribes to a certain set of sessions only consider the 
>parameters of the session of the highest layer. In this case, 
>for example, sprop-deint-buf-req would increase for sessions 
>from low to high layers, as you described above. But we need 
>more thinking after we have the NAL unit order recovery 
>process for layered multicast on the table, which are are 
>current working on. We authors will work hard to find a viable 
>solution to be included in the new version. Suggestions are 
>welcome and would be appreciated. 
>
>Without having seen how you really are going to address this 
>issue, it is hard to know if you are making it to hard or only 
>allows larger flexibility. If one likes to support 
>interleaving within a layer, then clearly the interleaving and 
>layer reordering is a form of overloading of the DON field. I 
>think that will work under certain restrictions. And I don't 
>think using interleaving is some layers and not in others will 
>be an issue for using DON to recover the decoding order. 
>Please do remember that the DON number usage can be very 
>sparse seen from a particular layer. Also interleaving is 
>simply changing the transmission order of things. If some 
>layers are re-ordered and others not does not make using the 
>same max-don-diff a problem.
>
>I think the real issue is if one allows for mixing non DON 
>supporting packetizations with DONs how that will be resolved. 
>It might be that you are making life unnecessary complex for 
>no real gain. But I do understand the desire to be able to use 
>a non DON supporting packetization in the base layer.
>

We have to come back when the entire signaling problem is solved and
specified in the draft, hopefully in the next version, hopefully
submitted sometime in September. Your comments will be carefully
considered. 

>> Including SEI messages in PACSI NAL units allows to 
>transport SEI messages with each coded slice of a picture for 
>error resilience purposes. Just to name one example. When 
>multiple copies of the same SEI message are received, those 
>contained in PACSI NAL units can be easily identified and 
>discarded to keep only one copy. This applies to any SEI 
>messages. You could also do this by repeating the SEI messages 
>directly in aggregation packets. However, this method has two 
>problems, one is that it is not easy to identify whether the 
>SEI message is a repeated one, the other is that it is not 
>compatible with RFC 3984. Discarding of redundant copies is 
>important because it is not for granted that the bitstream 
>containing repeated SEI messages conforms to the SVC 
>specification, as the implications to HRD conformance are 
>unpredictable, and there might be such semantics of SEI 
>messages that assume only one message per access unit.
>
>Okay, but I don't understand how a receiver will be able to 
>determine which are the redundant copy. If you loose a primary 
>transmission, you still hve to go through all the SEI messages 
>in the PACSI NALU to see if you are missing anyone. In 
>addition, I have some problem understanding how one is going 
>to ensure that the SEI message is inserted in the right 
>position in relation to the other NALUs present in the payload.
>

I will add text to explain these in the new version. See whether these
issues are clarified then. 

>> 
>>> 14. Section 9. I don't think SVC should change anything with the 
>>> media type for AVC. Use it as is, for the base layer. Some 
>>> explanation on how it relates to the SVC layers are of course 
>>> necessary.
>>>
>> 
>> Yes, it is specified that RFC 3984 is used for the base 
>layer transported in its own session, which of course includes 
>using the AVC media type. Will include some sentences to 
>clarify the relationship of the two media types. 
>
>It was more on the formulation in the section, which can be 
>interpret that it changes 3984.
>

OK, will try to avoid that interpretation. 

BR, YK 

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt