Subject: [AVT] comments on draft-ietf-avt-rtp-svc-02.txt

From: "Even, Roni" <[email-masked]>
Date: Fri, 20 Jul 2007 11:06:59 +0300

Hi,

Since H.264 annex G was consented at the last meeting I assume that this work can now address a stable payload.

I have some questions and comments on the document

1. In section 1.1 you say "and deprecate the single NAL unit packetization mode of RFC 3984." I believe that you are not suggesting deprecating the usage of single NAL unit for H264 media subtype but only suggesting that it will not be used for the SVC payload type. 

2. If you suggest using SVC instead of H264 payload type as in section 6.1 than I would strongly object to take out single NAL unit since this is the modes used in all video conferencing shipping products!!!! If you want to have interoperability with what you call "legacy" systems you must leave this mode. I also do not see any reason in section 6.5 why to take this mode out except saying that STAP is easy to implement. 

Further mode, the single NAL unit mode was agreed by the H.264 expert in order to expedite implementation support. 

3. I also question the claim in the introduction calling SVC a superset of H.264 since it is an annex in H.264 and does not cover all the modes of H.264. It does not encompass all the H.264 modes

4. In the definition section I find the following definition very confusing. "scalable bitstream:  A bitstream with the property that one or more bitstream subsets that are not identical to the scalable bitstream form another bitstream that conforms to the SVC specification."

5. In section 6.1 in order to achieve the design goal of having a full compatibility between a SVC full base layer and RFC 3984 encapsulation I suggest that the document will explain how to build such a packet and maybe recommend that systems that support SVC will be able to accept an H264 payload type.

6. In 6.2 " The following applies in addition", there is nothing else in the section following the above sentence.

7. About the editor note in 6.6 I suggest explaining it in the SDP usage. In the IANA registration these are optional parameters.

8. In section 6.9 you define a new NAL unit type PACSI, is the purpose only for MANE devices. How does it go with section 13.6

9. The PACSI NAL unit type is assigned a value (30) in this document. I did not see in H.264 or in any other place how you manage the allocation of the unspecified values preventing other applications from using this value.

10 in section 7 " Informative note: When either the prefix NAL unit or the   associated NAL unit containing an H.264/AVC coded slice is lost, the remaining one would be hardly useful in SVC context"

I thought that you can decode without the prefix NAL unit. I also thought that its usage is optional.

11. In section 7 "When Layers of a SVC bitstream are transported in more than one RTP session, the interleaved packetization mode MUST be used"

Why is that, can you explain.

12 in 9.1 what do you mean by " The receiver MUST ignore any unspecified parameter"

13. in 9.1 you mention all optional parameters from RFC3984. There are now new parameters being specified.

14. You define two new optional parameters sprop-scalability-info and sprop-layer-ids. What is the reason for these parameters, it looks to me that they duplicate information from the payload header. Also are thought parameters fixed during the session. Are they only for informational purposes.

15. The payload type is defined as SVC, maybe it should be H264-SVC.

16. Please replace the term MIME with payload type in the document.

Thanks

Roni Even 

 

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

---

From: Thomas Schierl <[email-masked]>
Date: Fri, 20 Jul 2007 11:19:26 +0200 (CEST)

Hi Roni,

Thanks for the feedback on the draft. Please, find my comments inline.

Thomas

On Jul 20, 2007 10:06 AM, "Even, Roni" <[email-masked]> wrote:

>1. In section 1.1 you say "and deprecate the single NAL unit
>packetization mode of RFC 3984." I believe that you are not suggesting
>deprecating the usage of single NAL unit for H264 media subtype but
>only suggesting that it will not be used for the SVC payload type.

Yes, when using H.264 in context with SVC, e.g. a SVC stream separated
in its H.264 base layer and the SVC enhancements. But for plain H.264,
we do not want to deprecate it, since it is a part of RFC3984.

>
>
>
>2. If you suggest using SVC instead of H264 payload type as in section
>6.1 than I would strongly object to take out single NAL unit since this
>is the modes used in all video conferencing shipping products!!!! If
>you want to have interoperability with what you call "legacy" systems
>you must leave this mode. I also do not see any reason in section 6.5
>why to take this mode out except saying that STAP is easy to implement.
>
>Further mode, the single NAL unit mode was agreed by the H.264 expert
>in order to expedite implementation support.
>

I am ok with your suggestion.

>
>
>3. I also question the claim in the introduction calling SVC a superset
>of H.264 since it is an annex in H.264 and does not cover all the modes
>of H.264. It does not encompass all the H.264 modes
>
>
You are right.

>
>4. In the definition section I find the following definition very
>confusing. "scalable bitstream: A bitstream with the property that one
>or more bitstream subsets that are not identical to the scalable
>bitstream form another bitstream that conforms to the SVC
>specification."
>

In H.264, there are the following definitions:

bitstream: A sequence of bits that forms the representation of coded
pictures and associated data forming one or more coded video sequences.
Bitstream is a collective term used to refer either to a NAL unit stream
or a byte stream.

bitstream subset: A bitstream that is derived as a subset from a
bitstream by discarding zero or more NAL units

Maybe, we use these definitions for more clarity.

>
>5. In section 6.1 in order to achieve the design goal of having a full
>compatibility between a SVC full base layer and RFC 3984 encapsulation
>I suggest that the document will explain how to build such a packet and
>maybe recommend that systems that support SVC will be able to accept an
>H264 payload type.
>

Good, we will incorporate that. But there may be also the case, where no
backward compatibility is required. In that case, I would not like to
force the receiver supporting full RFC3984.

>
>
>6. In 6.2 " The following applies in addition", there is nothing else
>in the section following the above sentence.
>
Yes, you are right, there was a note in the last draft about:
  When layers of an SVC scalable bitstream are transported in more
  than one RTP session, e.g. in layered multicast for which the use
  case is given in 13.2, session multiplexing MUST be used only as RTP
  multiplexing technique.

We found that not helpful anymore. So, we may need to remove 6.2.

>
>
>7. About the editor note in 6.6 I suggest explaining it in the SDP
>usage. In the IANA registration these are optional parameters.
>
Good.

>
>
>8. In section 6.9 you define a new NAL unit type PACSI, is the purpose
>only for MANE devices. How does it go with section 13.6
>
I think section 13.6 can be removed anyway. That was useful for
explaining IETF philosophy but is not required for the final payload
draft.

>
>9. The PACSI NAL unit type is assigned a value (30) in this document. I
>did not see in H.264 or in any other place how you manage the
>allocation of the unspecified values preventing other applications from
>using this value.
>
In H.264, these types are left open for application usage:
In Table 7-1 the H.264 standard says these types are unspecified.

>
>
>10 in section 7 " Informative note: When either the prefix NAL unit or
>the associated NAL unit containing an H.264/AVC coded slice is lost,
>the remaining one would be hardly useful in SVC context"
>

Exactly, you can decode it but you may not be able to use it as
reference for a SVC enhancement layer.

>
>
>11. In section 7 "When Layers of a SVC bitstream are transported in
>more than one RTP session, the interleaved packetization mode MUST be
>used"
>

We tried to explain that in section 14 of
draft-wenger-avt-rtp-svc-01.txt . In that section we tried to solve the
problem of re-interleaving NAL untis from different RTP sessions to one
SVC bistream. We found that this may be very complicated. On the other
hand it is very simple if using an extended cross-layer DON.

>12 in 9.1 what do you mean by " The receiver MUST ignore any
Maybe, Stephan can reply on that.

>14. You define two new optional parameters sprop-scalability-info and
>sprop-layer-ids. What is the reason for these parameters, it looks to
>me that they duplicate information from the payload header. Also are
>thought parameters fixed during the session. Are they only for
>informational purposes.
>

The scalability SEI (sprop-scalability-info) is useful, if someone wants
to understand the whole SVC bitstream, e.g., which layers are available
at which resolution or framerate. It also connects the NAL unti header
scalability identifier (PRID, DID, QID, TID) with such values.
The second parameter sprop-layer-ids is useful to describe in the
layered Multicast case which scalability levels of the whole bitstream
(described by sprop-scalability-info) are contained in an RTP session.

>15. The payload type is defined as SVC, maybe it should be H264-SVC.
I have no preference.

>16. Please replace the term MIME with payload type in the document.

Ok.

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 20 Jul 2007 14:17:14 +0300

Thomas,
Thanks,

About the PACSI NAL unit type. My question was about the allocation mechanism for the unspecified values in H.264. You are allocating 30 in this document for PACSI. What prevents someone else, for example in 3GPP, to define another NAL unit type and give it also the number 30. 

As for the new optional parameters, I understand that they are of informational value and I was wondering if the enhancement layers can be changed without signaling and how often can you change them.

Roni 

> -----Original Message-----
> From: Thomas Schierl [mailto:[email-masked]]
> Sent: Friday, July 20, 2007 12:19 PM
> To: Even, Roni
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [AVT] comments on draft-ietf-avt-rtp-svc-02.txt
> 
> Hi Roni,
>

---

From: Thomas Schierl <[email-masked]>
Date: Fri, 20 Jul 2007 14:02:39 +0200 (CEST)

Hi Roni,

Please find my comments inline.

Thomas

On Jul 20, 2007 01:17 PM, "Even, Roni" <[email-masked]> wrote:

>About the PACSI NAL unit type. My question was about the allocation
>mechanism for the unspecified values in H.264. You are allocating 30 in
>this document for PACSI. What prevents someone else, for example in
>3GPP, to define another NAL unit type and give it also the number 30.

There is no coordination for the usage of user space NAL units, thus
only the specification in question can rely on such a number.

>
>As for the new optional parameters, I understand that they are of
>informational value and I was wondering if the enhancement layers can
>be changed without signaling and how often can you change them.

Enhancement layers can be changed on a frame by frame basis. Since the
signaling must be still correct within a RTP session, the idea is to
signal the highest operation point of the RTP session. So that, the
receiver  is prepared for receiving that and all lower operation points.
Does that answer your question?

>>>13. in 9.1 you mention all optional parameters from RFC3984. There
>>>are
>>>now new parameters being specified.
>>>
>>>
>>>

________________________________________________________
Thomas Schierl, Dipl.-Ing.
Fraunhofer HHI
Senior Research Engineer
Image Processing Dept. / Multimedia Streaming Tech.
Einsteinufer 37, 10587 Berlin, Germany
PHONE: +49 30 31002 227, FAX: +49 30 392 7200, WEB: ip.hhi.de
EMAIL: [email-masked], SKYPE: thomas.schierl

---

From: Colin Perkins <[email-masked]>
Date: Sun, 22 Jul 2007 10:57:09 -0500

On 20 Jul 2007, at 04:19, Thomas Schierl wrote:
...
> explaining IETF philosophy but is not required for the final payload

I think it's important to document bad ideas, and why they are a bad  
idea, so I would strongly prefer to keep that discussion in the final  
RFC.

-- 
Colin Perkins
http://csperkins.org/