Subject: [AVT] Comments on draft-ietf-avt-rtp-svc-09.txt

From: <[email-masked]>
Date: Mon, 19 May 2008 17:04:04 +0100

Here are some comments on draft 9 of the RTP Payload Format for SVC
Video.

1) Table 3.3. shows that PACSI is disallowed when packetization mode is
NI-T. Is this intended? I had imagined that the restriction was that
PACSI could be present but the T bit must be set to zero, so that DONC
is not present.

2) Table 3.5. Same question: is PACSI really to be disallowed when
packetization mode is I-C?

3) Section 6.6.1 uses the terms SN and NALU time. Presumably these are
the RTP sequence number and the RTP time stamp respectively? This should
be stated explicitly.

4) Section 6.6.1. Considering the case of PACSI in STAP-A being followed
by a single NAL unit packet. The text states that the incremental method
is used to determine CS-DON. Why not use the SN difference method,
modified to work relative to the last non-PACSI NAL in the STAP-A. This
would seem to simplify the CS-DON recovery rules to using the
incremental method within STAP-A and using SN diff otherwise.

5) In the definition of PACSI, the semantics of the S and E bits refer
to decoding order, but the informative note that follows refers to
transmission order. Note that decoding was changed to transmission (in
this note) in this draft of the text.

6) Section 7.1. The terminology in "If an access unit of sampling time
instance X is present in RTP session A, this access unit MUST be also
present in any RTP session, which depends on RTP session A." does not
seem right. Is it right to talk about an access unit being in an RTP
session? Or should it be "one of more NAL units of an access unit". This
would lead to: "If one of more NAL units of an access unit are present
in an RTP session, then one of more NAL units of the same access unit
MUST be present in each RTP session that depends on that RTP session."

7) Section 7.1. "When the NI-T or NI-TC session-multiplexing
packetization mode is in use, the following applies. ... When a PACSI
NAL unit is present, the T bit MUST be equal to 0, i.e. the DONC field
MUST NOT be present." Surely not for the NI-TC mode? Also see comment 1,
which questioned whether PACSI is allowed with NI-T.

8) In section 7.1, in the text about NI-T and NI-TC modes, it would be
useful to have a paragraph explaining the reasoning. Alternatively this
could be in 6.6.1. This would seem to be that CS-DON is specified with
error resilience in mind, using incremental values within an STAP-A
packet, and using RTP sequence number differences where possible, and
falling back on incremental values outside of STAP-A only when necessary
(unless comment 4 is adopted). 

9) The first paragraph of 8.1.2 refers to the ANIT mode which should be
I-C.

Best regards

Mike

Mike Nilsson 
Multimedia Analysis and Coding
BT Group Chief Technology Office
___________________________ 

Sirius House (B54-MH), Room 92 
Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK 
Tel:    +44 1473 645413 
Mobile: +44 7917 025433 
Fax:    +44 1908 862365 
Email:  [email-masked] <BLOCKED::mailto:[email-masked]> 

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

---

From: <[email-masked]>
Date: Mon, 19 May 2008 22:45:00 +0300

Thanks Mike for your careful reading and valuable comments. See inline
please. 
 
BR, YK

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext [email-masked]
	Sent: Monday, May 19, 2008 7:04 PM
	To: [email-masked]
	Subject: [AVT] Comments on draft-ietf-avt-rtp-svc-09.txt

	Here are some comments on draft 9 of the RTP Payload Format for
SVC Video.

	1) Table 3.3. shows that PACSI is disallowed when packetization
mode is NI-T. Is this intended? I had imagined that the restriction was
that PACSI could be present but the T bit must be set to zero, so that
DONC is not present.
	[Wang Ye-Kui]  The table shows what NAL unit types as RTP packet
payload are allowed for each mode. PACSI is not allowed as the only
payload for NI-T, but it is still allowed to be included in an
aggregation packets. This is similar as in RFC 3984 Table 3 where NAL
unit types 1-23 are not allowed in the non-interleaved packetization
mode. However, I would agree that it can easily be interpretted as you
did (as it happened once too)  - in this draft I have already tried to
make it better than in RFC 3984. Maybe I should make it more clearer in
both this draft and RFC3984bis.

	2) Table 3.5. Same question: is PACSI really to be disallowed
when packetization mode is I-C?
	[Wang Ye-Kui] Same as above. 

	3) Section 6.6.1 uses the terms SN and NALU time. Presumably
these are the RTP sequence number and the RTP time stamp respectively?
This should be stated explicitly.
	[Wang Ye-Kui] Yes - will be updated in the next version.  

	4) Section 6.6.1. Considering the case of PACSI in STAP-A being
followed by a single NAL unit packet. The text states that the
incremental method is used to determine CS-DON. Why not use the SN
difference method, modified to work relative to the last non-PACSI NAL
in the STAP-A. This would seem to simplify the CS-DON recovery rules to
using the incremental method within STAP-A and using SN diff otherwise.
	[Wang Ye-Kui]  I think this is a good idea. Will integrate it
unless I find any problem. 

	5) In the definition of PACSI, the semantics of the S and E bits
refer to decoding order, but the informative note that follows refers to
transmission order. Note that decoding was changed to transmission (in
this note) in this draft of the text.
	[Wang Ye-Kui] Thomas and Alex wanted to use "decoding order"
instead of "transmission order". I let you guys to figure what and
decide. But anyway, the text will be made consistent. 

	6) Section 7.1. The terminology in "If an access unit of
sampling time instance X is present in RTP session A, this access unit
MUST be also present in any RTP session, which depends on RTP session
A." does not seem right. Is it right to talk about an access unit being
in an RTP session? Or should it be "one of more NAL units of an access
unit". This would lead to: "If one of more NAL units of an access unit
are present in an RTP session, then one of more NAL units of the same
access unit MUST be present in each RTP session that depends on that RTP
session."
	[Wang Ye-Kui] I think you are right - but I let Thomas respond
"officially" :-) 

	[Wang Ye-Kui] Same as comment 1. 

	8) In section 7.1, in the text about NI-T and NI-TC modes, it
would be useful to have a paragraph explaining the reasoning.
Alternatively this could be in 6.6.1. This would seem to be that CS-DON
is specified with error resilience in mind, using incremental values
within an STAP-A packet, and using RTP sequence number differences where
possible, and falling back on incremental values outside of STAP-A only
when necessary (unless comment 4 is adopted). 
	[Wang Ye-Kui] Agree that addition of such text would be good. 

	9) The first paragraph of 8.1.2 refers to the ANIT mode which
should be I-C.
	[Wang Ye-Kui] Agree - will be changed. 

	Best regards

	Mike

	Mike Nilsson

	Sirius House (B54-MH), Room 92
	Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK
	Tel:    +44 1473 645413
	Mobile: +44 7917 025433
	Fax:    +44 1908 862365
	Email:  [email-masked]
<BLOCKED::mailto:[email-masked]>

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 21 May 2008 15:12:05 +0300

Hi,

The following question was asked by Mike Nilsson and YK responded.

5) In the definition of PACSI, the semantics of the S and E bits refer
to decoding order, but the informative note that follows refers to
transmission order. Note that decoding was changed to transmission (in
this note) in this draft of the text.
[Wang Ye-Kui] Thomas and Alex wanted to use "decoding order" instead of
"transmission order". I let you guys to figure what and decide. But
anyway, the text will be made consistent. 

I reviewed the 08 and 09 drafts (see the text bellow) and noticed the
change in the informative note in 09 from "decoding" to "transmission"
and the change in the semantics of 08 to 09.

I am not sure why the change was made but it is more correct if the
purpose was to say that the first and last slices in the decoding order
are also the first and last slices in the transmission order.

08 text

"o The S bit MUST be set to 1, if the first VCL NAL unit, in decoding

   order, of the layer representation containing the first NAL unit

   following the PACSI NAL unit in the aggregation packet is present in

   the payload.  Otherwise, the S bit MUST be set to 0.

   o The E bit MUST be set to 1, if the last VCL NAL unit, in decoding

   order, of the layer representation containing the first NAL unit

   following the PACSI NAL unit in the aggregation packet is present in

   the payload.  Otherwise, the E field MUST be set to 0.

      Informative note: The S or E bit indicates whether the first or

      last slice, in decoding order, of a layer representation is in

      the packet, to enable a MANE to detect slice loss and take proper

      action such as requesting a retransmission as soon as possible,

      as well as to allow an efficient playout buffer handling

      similarly as the M bit in the RTP header.  The M bit in the RTP

      header still indicates the end of an access unit, not the end of

      a layer representation.

"

09 text:

" o  The S bit MUST be set to 1, if the first VCL NAL unit, in decoding 

      order, of the layer representation containing the first NAL unit 

      following the PACSI NAL unit in the aggregation packet is present 

      in the payload (when the PACSI NAL unit is included in an 

      aggregation packet) or if the next non-PACSI NAL unit in 

      transmission order is the first VCL NAL unit, in decoding order, 

      of a layer representation (when the PACSI NAL unit is included in 

      a single NAL unit packet).  Otherwise, the S bit MUST be set to 0.

   o  The E bit MUST be set to 1, if the last VCL NAL unit, in decoding 

      order, of the layer representation containing the first NAL unit 

      following the PACSI NAL unit in the aggregation packet is present 

      in the payload (when the PACSI NAL unit is included in an 

      aggregation packet) or if the next non-PACSI NAL unit in 

      transmission order is the last VCL NAL unit, in decoding order, of

      a layer representation (when the PACSI NAL unit is included in a 

      single NAL unit packet).  Otherwise, the E field MUST be set to 0.

      Informative note: The S or E bit indicates whether the first or 

      last slice, in transmission order, of a layer representation is 

      in a packet, to enable a MANE to detect slice loss and take 

      proper action such as requesting a retransmission as soon as 

      possible, as well as to allow an efficient playout buffer 

      handling similarly as the M bit in the RTP header.  The M bit in 

      the RTP header still indicates the end of an access unit, not the 

      end of a layer representation. 

"

 

Roni