Subject: [AVT] Questions on RTP payload format for SVC

From: "BERTHELOT Bertrand RD-MAPS-REN" <[email-masked]>
Date: Thu, 6 Jul 2006 10:20:16 +0200

Dear Stephan,
 
I have some questions/remarks on your last draft of the RTP payload
format for SVC.
 
1 - The term 'layer' has not the same signification in your draft as in
SVC. A layer in SVC contains all NAL units with the same dependency_id.
Therefore, a base layer should contains all NAL units with dependency_id
= 0, and not the minimum (D,T,Q).
 
2 - Section 3.3: "PRID: simple_priority_id. This component specifies a
priority identifier for the NAL unit"
    => The simple priority_id cannot be lonely interpreted as a priority
identifier for transport, it has to be associated with the D,T,Q
information.
 
3 - Section 6.4 (NAL unit header usage): Same remark as in 2.
 
4 - Section 6.5: "The single NAL unit mode SHALL NOT be used".
    => Why? I do not see any reason to disable this mode.
 
5 - Section 6.10: PACSI NAL Unit
    => It is a very good point that you introduced this new NAL unit
type for aggregation packets. PACSI could be very useful for adaptation
modules (see remark/question 7). 
 
6 - Section 13: NAL unit reordering for layered multicast
    => Does it mean that you always have to use the 'costly' interleaved
mode when using layered multicast. Receivers could reorder NAL units
without DON as described in your previous draft.
 
7 - Section 14.6: This scenario is not so much out of interest. One
could imagine a module in the security context which is less complex
than a MANE, i.e. that do not need to terminate RTP sessions and create
new ones, and that can perform adaptation on the fly by dropping RTP
packets according to the P,D,T,Q information contained in the
peudo-header. This module could be considered as a "light" MANE. As you
mentionned, the RTP sequence numbers and/or RTCP RRs would need to be
patched but I think it is workable. 

Best regards, 
 
Bertrand Berthelot
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Thu, 6 Jul 2006 21:31:27 +0300

Dear Bertrand,
 
First of all, thanks for your review of the draft. I am not Stephan, but
let me try to answer your questions/comments. 
 
1. You are right that we have used the term "scalable layer" or "layer"
in a different way as in the current SVC draft. The main reason we used
a different layer concept is because the definitions of layer and
picture etc. are still quite open to our knowledge. In the latest SVC
draft, there is a definition of "layer" (Section 3.70) and also a
definition of "scalable layer" (Section F.3.1) - both are copied below. 
 layer: One of a set of syntactical structures in a non-branching
hierarchical relationship. Higher layers contain lower layers. The
coding layers are the coded video sequence, picture, slice, and
macroblock layers.

 scalable layer: A set of NAL units within an access unit with the same
value of dependency_id.

So if you add a constraint "within an access unit" to the definition of
"layer" you mentioned, then it is the SVC definition of "scalable
layer". I.e., you also have a different understanding of "layer". In
addition, the term "AVC base layer" has been extensively used in JVT.
The words "base layer" in this term definitely means only the AVC NAL
units while excluding the possibly present FGS NAL units having the same
value of dependency_id.
 
So this will aligned after the definitions of the important terms are
finalized in JVT. Anyway, improving suggestions are welcome. 
 
2. The semantics of simple_priority_id is still open in JVT. There have
been discussions in the JVT mailing list on this. The current semantics
in our draft is exactly the same as in the latest SVC draft. 
 
3. Please let me know if response to your remark 2 does not explain
this.
 
4. This question has been asked for quite a few times. First of all,
disabling the single NAL unit packetization mode does not mean that you
are not allowed to put only one NAL unit into one RTP packet, that is
still allowed in the non-interleaved mode. Secondly, implementations
typically support at least non-interleaved mode, which does not require
much additional implementation complexity but is much more powerful than
single NAL unit mode. Therefore, it makes to remove the single NAL unit
mode such that the number of IOP tests can be reduced. Stephan, please
correct/complement me if needed. 
 
5. Thanks.
 
6. Yes and Yes. The reason we removed the old text for NAL unit
reordering is because of the complexity of the reordering process
without cross-layer DON. My understanding is that this has been agreed
in the previous AVT meeting. 
 
7. This point I let Stephan or Thomas to comment. 
 
Best Regards,
Ye-Kui Wang

________________________________

	From: ext BERTHELOT Bertrand RD-MAPS-REN
[mailto:[email-masked]] 
	Sent: Thursday, July 06, 2006 11:20 AM
	To: [email-masked]
	Cc: [email-masked]
	Subject: [AVT] Questions on RTP payload format for SVC

	Dear Stephan,
	 
	I have some questions/remarks on your last draft of the RTP
payload format for SVC.
	 
	1 - The term 'layer' has not the same signification in your
draft as in SVC. A layer in SVC contains all NAL units with the same
dependency_id. Therefore, a base layer should contains all NAL units
with dependency_id = 0, and not the minimum (D,T,Q).
	 
	2 - Section 3.3: "PRID: simple_priority_id. This component
specifies a priority identifier for the NAL unit"
	    => The simple priority_id cannot be lonely interpreted as a
priority identifier for transport, it has to be associated with the
D,T,Q information.

	 
	5 - Section 6.10: PACSI NAL Unit
	    => It is a very good point that you introduced this new NAL
unit type for aggregation packets. PACSI could be very useful for
adaptation modules (see remark/question 7). 
	 
	6 - Section 13: NAL unit reordering for layered multicast
	    => Does it mean that you always have to use the 'costly'
interleaved mode when using layered multicast. Receivers could reorder
NAL units without DON as described in your previous draft.
	 
	7 - Section 14.6: This scenario is not so much out of interest.
One could imagine a module in the security context which is less complex
than a MANE, i.e. that do not need to terminate RTP sessions and create
new ones, and that can perform adaptation on the fly by dropping RTP
packets according to the P,D,T,Q information contained in the
peudo-header. This module could be considered as a "light" MANE. As you
mentionned, the RTP sequence numbers and/or RTCP RRs would need to be
patched but I think it is workable. 

	Best regards, 
	 
	Bertrand Berthelot

---

From: "Thomas Schierl" <[email-masked]>
Date: Fri, 7 Jul 2006 11:56:37 +0200

Dear Bertrand,

Two points from my side:

(6.) I’m not sure what you mean with ‘costly’. Complexity is much reduced if
using cross-layer DON. I think there was a decision in Dallas to go on
working on cross-layer DON. Of course from my point of view no-one decided
this being the one and only solution. But for the moment we will describe
the cross-layer DON approach only. If there should be a need of having an
informative section on layered multicast transport without cross-layer DON
we may roll up this item again. But as I mentioned, this part would be
informational and not normative.

(7.) Please see the remark in the draft on how to guarantee that the ‘light’
MANE (‘aka’ MDfH) is aware of the signaling. Further being in the security
context would imply being aware of the signaling anyway.  In the draft we
assumed that these points may be overcome by IETF-external standardization,
but will be not considered by the authors. The RTP-Translation is only a
further point which has to be taken into account.

Best regards,

Thomas

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 06, 2006 8:31 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [AVT] Questions on RTP payload format for SVC

Dear Bertrand,
 
First of all, thanks for your review of the draft. I am not Stephan, but let
me try to answer your questions/comments. 
 
1. You are right that we have used the term "scalable layer" or "layer" in a
different way as in the current SVC draft. The main reason we used a
different layer concept is because the definitions of layer and picture etc.
are still quite open to our knowledge. In the latest SVC draft, there is a
definition of "layer" (Section 3.70) and also a definition of "scalable
layer" (Section F.3.1) - both are copied below. 
 layer: One of a set of syntactical structures in a non-branching
hierarchical relationship. Higher layers contain lower layers. The coding
layers are the coded video sequence, picture, slice, and macroblock layers.
 scalable layer: A set of NAL units within an access unit with the same
value of dependency_id.
 
So if you add a constraint "within an access unit" to the definition of
"layer" you mentioned, then it is the SVC definition of "scalable layer".
I.e., you also have a different understanding of "layer". In addition, the
term "AVC base layer" has been extensively used in JVT. The words "base
layer" in this term definitely means only the AVC NAL units while excluding
the possibly present FGS NAL units having the same value of dependency_id.

2. The semantics of simple_priority_id is still open in JVT. There have been
discussions in the JVT mailing list on this. The current semantics in our
draft is exactly the same as in the latest SVC draft. 
 
3. Please let me know if response to your remark 2 does not explain this.
 
4. This question has been asked for quite a few times. First of all,
disabling the single NAL unit packetization mode does not mean that you are
not allowed to put only one NAL unit into one RTP packet, that is still
allowed in the non-interleaved mode. Secondly, implementations typically
support at least non-interleaved mode, which does not require much
additional implementation complexity but is much more powerful than single
NAL unit mode. Therefore, it makes to remove the single NAL unit mode such
that the number of IOP tests can be reduced. Stephan, please
correct/complement me if needed. 
 
5. Thanks.
 
6. Yes and Yes. The reason we removed the old text for NAL unit reordering
is because of the complexity of the reordering process without cross-layer
DON. My understanding is that this has been agreed in the previous AVT
meeting. 

Best Regards,
Ye-Kui Wang

________________________________________
 
I have some questions/remarks on your last draft of the RTP payload format
for SVC.
 
1 - The term 'layer' has not the same signification in your draft as in SVC.
A layer in SVC contains all NAL units with the same dependency_id.
Therefore, a base layer should contains all NAL units with dependency_id =
0, and not the minimum (D,T,Q).

 
 
5 - Section 6.10: PACSI NAL Unit
    => It is a very good point that you introduced this new NAL unit type
for aggregation packets. PACSI could be very useful for adaptation modules
(see remark/question 7). 
 
6 - Section 13: NAL unit reordering for layered multicast
    => Does it mean that you always have to use the 'costly' interleaved
mode when using layered multicast. Receivers could reorder NAL units without
DON as described in your previous draft.
 
7 - Section 14.6: This scenario is not so much out of interest. One could
imagine a module in the security context which is less complex than a MANE,
i.e. that do not need to terminate RTP sessions and create new ones, and
that can perform adaptation on the fly by dropping RTP packets according to
the P,D,T,Q information contained in the peudo-header. This module could be
considered as a "light" MANE. As you mentionned, the RTP sequence numbers
and/or RTCP RRs would need to be patched but I think it is workable. 

Best regards, 
 
Bertrand Berthelot

--
Meet us at 

OC&I 2006 and NOC 2006: 10.-13.7.06 at HHI Berlin, Germany
IFA: 1.-6.9.06, Berlin, Germany