Subject: [payload] Comments on draft-ietf-payload-rtp-h265-02

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Feb 2014 16:47:11 +0100

Hi,

I have reviewed the H.265 RTP payload format and have a some comments.

1. Move abstract

The current rules for the "first page" allows one to have the abstract
before the Status of this memo. I would recommend that.

2. Word issues:
A guess is that you are using MS Word for producing the draft. I seen at
least two issues. A) Varying page lengths. B) Table of Content has
strange spaces between section levels in the TOC.

I guess I can't convince you to switch draft production environment ;-).

3. Section 1.1.2:
   The profile, tier and level syntax structure that can be included in
   both VPS and sequence parameter set (SPS) includes 12 bytes data to
   describe the entire bitstream (including all temporally scalable
   layers,  which  are  referred  to  as  sub-layers  in  the  HEVC
   specification), and can optionally include more profile, tier and
   level  information  pertaining  to  individual  temporally  scalable
   layers.

"12 bytes data to" shouldn't this be "12 bytes of data to"?

4. Use of RTP flow:
This draft includes three usage of RTP flow. This is a poorly defined
term. I would suggest two things. Drop this usage and replace it with
the approriate term from Grouping Taxonomy.

5. Section 1.2:
  o Transmission of HEVC NAL units of the same bitstream within a
     single RTP stream (note that RTP stream is used equivalently as
     RTP flow in this memo) or multiple RTP streams

I would propose to make clear that "multiple RTP streams" is within one
or more RTP sessions.

6. Section 3.1.1:

   IRAP picture: A coded picture for which each VCL NAL unit has
   nal_unit_type in the range of BLA_W_LP to RSV_IRAP_VCL23, inclusive.

I wonder if this within paranthesis should include the corresponding
values to those labels, i.e.  BLA_W_LP (16) to RSV_IRAP_VCL23 (23), ...

7. Section 3.1.2:
   dependent RTP stream: An RTP stream in an MST on which another RTP
   stream depends.

Here is another case where I think these definitions should be aligned
or simply use the one from Grouping Taxonomy.

8. Intentionally missing!

9. Section 3.1.2:
   single-stream transmission (SST): Transmission of an HEVC bitstream
   using only one RTP stream.

   multi-stream transmission (MST): Transmission of an HEVC bitstream
   using more than one RTP stream.

So these redefines the SST and MST terms in RFC 6190 to one that is
single/Multi-stream instead of single/Multi-Session. I think this should
be aligned with the outcome of the ongoing discussion in AVTEXT
regarding grouping taxonomy.

10. Section 3.1.2:
   RTP stream: A sequence of RTP packets with increasing sequence
   numbers (except for wrap-around), identical PT and identical SSRC
   (Synchronization Source), carried in one RTP session.  Within the
   scope of this memo, one RTP stream is utilized to transport one or
   more temporal sub-layers.

I note that this is defined as "Packet Stream" in taxonomy. Consider
alignment. At least this definition is clear on what is meant.

11. Section 4.1:
   Sequence number (SN): 16 bits

      Set and used in accordance with RFC 3550.

To my understanding when using single stream transmission the Decoding
order is recovered soley from RTP sequence numbers and order of the
NALUs within each RTP payload. This usage should be mentioned here as it
affects the impact if anyone would inject other payloads in the same RTP
packet stream.

12. Section 4.1:
  I am missing the SSRC usage for this RTP payload. In SST that is the
classical identification of a particular encoding of a media source. But
for MST the SSRC usage is different as one needs to know which SSRC in
which RTP sessions that are associated. I think this dependency needs to
be noted.

13. Section 4.6:
    DONL (optional)

I claim that using "optional" is the wrong word, it should be
"conditional". The presence of the field are dependent on a signalling
parameters, thus conditional on that parameter.

This comment also apply to same type of usage in Section 4.7.

14. Section 4.6:
   The DONL field, when present, specifies the value of the 16 least
   significant bits of the decoding order number of the contained NAL
   unit.

   If sprop-depack-buf-nalus is greater than 0, the DONL field MUST be
   present, and the variable DON for the contained NAL unit is derived
   as equal to the value of the DONL field.  Otherwise (sprop-depack-
   buf-nalus is equal to 0), the DONL field MUST NOT be present.

I wonder why this is split into two paragraphs, the second paragraph's
content is very important to understand what is said in the first.

15. Section 4.7:
   If sprop-depack-buf-nalus is greater than 0, the DOND field MUST be
   present in an aggregation unit that is not the first aggregation
   unit in an AP, and the variable DON for the aggregated NAL unit is
   derived as equal to the DON of the preceding aggregated NAL unit in
   the same AP plus the value of the DOND field plus 1 modulo 65536.

I really wonder over the "+1" usage in the DOND field. That prevents two
NALUs in an AP to have same DON. Which at least Section 4.5 hints to as
being valid. If that is not valid, then Section 4.5 is in error.
Thus, this definition can cause issues and I don't see any issues with
defining the field without the plus. That limits the difference to
increment with a maximum of 255 instead of 256.

16. Section 4.7, figure 7:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          RTP Header                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PayloadHdr          |         NALU 1 Size           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I wonder if this would be clearer by including some values for the
payload header, here the Type of the payload header (type=48) appears
to be highly relevant for this example. Maybe somehting like this?

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          RTP Header                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PayloadHdr (Type=48)         |         NALU 1 Size           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

17. Section 4.9:
      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RTP Header                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F| PACI=50   |  LayerId  | TID |A|    Type   | PHSsize |F0..2|X|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Payload Header Extension Structure (PHES)              |
      |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=|
      |                                                               |
      |                  PACI payload: NAL unit                       |
      |                   . . .                                       |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

I wonder if one shouldn't mark the first 16 bits after the header as the
"payload header" and instead separate out the configuration of those for
this payload format. That would also resolve the next issue.

18. Section 4.9:

   PACI: 6 bits
      Indicates a PACI, and must be 50.

As this field is called Type in the other definition, why not call it
Type: 6 bits
    Indicates a PACI, and must be 50.

And to clarify the confusion with the PACI payload type, that Type field
should be called IType or something like that

19. Section 4.9:
   PHSsize: 5 bits
      Indicates the total length of the PHES.  The value is limited to
      be less than or equal to 32 octets, to simplify encoder design
      for MTU size matching.

   F0..2: 3 bits
      Each of the three bits indicate, when set, the presence of an
      optional field (or set of fields) in the PHES.

   X: 1 bit
      The X bit, when set, indicates the presence of another octet
      consisting of seven flags and another X bit, each of the seven
      flags indicating the presence of more PHES fields (for future
      extensions).

The motivation of the PHSSize of limiting this to 32 octets is not
fulfilled. As the RTP payload still are variable size due to the X bit,
which adds one or more bytes. Thus if the goal is to make clear that
this will never be more than 32 bytes, than I think the bytes that X
signals must be included in the 32-bytes for the PHES.

20. Section 4.9: Forward compability for PHES.

The content of the PHES field is determined using the F0..2 field and in
the future the octet(s) added using the X field, where each set bit
indicates what fields are included. However, this definition have some
severe implications regarding future compatibility. As each bit can
represent an unknown amount of fields a first gen decoder can't know how
many bits each of the bits represents. This may not matter much for the
first gen, as it only knows of the PHES data defined in this version. To
be able to decode these fields only a single thing is missing, an
assurance that the first defined data MUST be first in the PHES data
section when F0 is set.

For a third generation implementation there is another implication. To
know where the F2 PHES payload starts it MUST know also what F0 and F1
means in amount of fixed field data values.

I am not that happy for this forward compatibility limiations. But, it
can work, but the rules for how to make it work MUST be explictely
stated now.

1) The fields added for a particular FX bit MUST be fixed in length and
not depend on what other FX bits are set.
2) The FX bits must be assigned in order
3) An implementation that supports FX for any value will be required to
understand what fields are added and their size for all FX bits that are
X or less.

21. Section 4.9: I think the motivation for the PACI is missing. What
are the motivation for providing this information in the PACI and what
would any RTP endpoint or middlebox use the information for.

22. Section 4.10:

Can you please provide a name for the functionality set the F0 bit
represents so that we can use a name to reference it?

23. Section 5:
Otherwise (sprop-
      depack-buf-nalus  is  equal  to  0  for  an  RTP  stream),  the
      transmission order of NAL units carried in the RTP stream MUST be
      the same as the NAL unit decoding order.

This fails to describe how you determines the NAL unit decoding order. I
assume in RTP sequence order and for each payload in the order the NALUs
are included?

24. Section 6:

When MST is in use, NAL units of all RTP
   streams are stored in the same de-packetization buffer.

I think it needs to be clarified that this is all RTP streams from the
same encoder instance and media source. Not all RTP streams from
multiple encoder instances and media sources.

25. Section 7.1:
   The receiver MUST ignore any unspecified parameter.

First, I don't know if this is the right place to included this rule.
Secondly, should it not be "unknown" parameters for the one processing
the media format parameters?

26. Section 7.1:

profile-space, profile-id:
            Otherwise (the RTP stream is a dependent RTP stream), the
            following applies, with j being the value of the sub-layer-
            id parameter:

            o profile_space = sub_layer_profile_space[j]
            o profile_id = sub_layer_profile_idc[j]

The following text raises some concerns.
A) These are defined as being stream specific values. It is unclear how
one deals with these if one only want to configure the general
capability within a RTP payload type.

B) It is unclear if one may or are required to create different RTP
payload types for the different scalability layers. From my perspective
it is crucial that one can avoid a requirement to create layer specific
payload types as this can result in total consumption of the available
payload type space in an RTP session.

Thus, I see a need to clarify if and when one uses the above assignment.
And how the counter part in any signalling exchange is supposed to
interpret these cases.

The same concerns relate to the tier-flag, level-id:

            Otherwise (the RTP stream is a dependent RTP stream), the
            following applies, with j being the value of the sub-layer-
            id parameter:

            o tier-flag = sub_layer_tier_flag[j]
            o level-id = sub_layer_level_idc[j]

27. Section 7.1:
       profile-compatibility-indicator:

Isn't this a sprop parameter?

Also it is not clear what "j" is:

            If the RTP stream is not a dependent RTP stream, the
            following applies with j = 0..31:

            o The 32 flags = general_profile_compatibility_flag[j]

Am I correct that j in this case are the integer identifying a
particular HEVC profile?

28. Section 7.1:
profile-compatibility-indicator:

It is not clear to me that this parameter has long term applicability.
If one includes this, is that a promise until signaling changes to not
provide a stream that breaks the provided value? I wonder how one deals
with the use cases like AD splicing. One stream may ensure this, is it
the role of the signalling to enforce that what one says applies, or
will be renegotiated in signalling?

29.

      sub-layer-id:

         This parameter MAY be used to indicate the highest allowed
         value of TID in the stream.  When not present, the value of
         sub-layer-id is inferred to be equal to 6.

This parameter is written in a generic form, however the O/A Section
indicates this to declare a property of the stream to be sent. But not
explicit discussion of this parameter is provided. So what is the
meaning of this parameter?

A) I promise that the streams I send does not use more than X sub-layers

B) I require the peer sending me a stream to not use more than X sub-layers.

30. Section 7.1:
sprop-vps, sprop-sps and sprop-pps:

I think one unclarity and one that existed in H.264 also, is the
precedence between out-of-band and in-band parameter sets. And when they
start to apply. The later is especially important in cases when you
actually transmit a different set in a new signalling exchange then what
has previously been used.

Can some clarification on this be included?

31. Section 7.1:
   Many of the parameters. I notices that quite a lot of the parameters
are not explicitly defining the value range allowed for the parameters.
This is especially true for integer style values. See the many max-
parameters.

32. Section 7.1:
  max-dpb: Formation error

33. Section 7.1:

cap-parameter = tier-flag / level-id / max-lsr
                            / max-lps / max-br

These ABNF elements are not defined. I think they need to be.

34. Section 7.2.1:

Source specific parameters:

   o  The OPTIONAL parameters "sprop-vps", "sprop-sps", and "sprop-
      pps", when present, MUST be included in the "a=fmtp" line of SDP
      or conveyed using the "fmtp" source attribute as specified in
      section 6.3 of [RFC5576].  For a particular media format (i.e.
      RTP payload type), "sprop-vps" "sprop-sps", or "sprop-pps" MUST
      NOT be both included in the "a=fmtp" line of SDP and conveyed
      using the "fmtp" source attribute.

This text exemplifies that there are important differencies between RTP
session level configuration and individual source level configuration. I
think some more general discussion of the potential constraints and
implications of the two methods needs to be considered. Especially when
you are prevented from signalling both session and stream level.

Stream level requires on to know that this stream will be sent and its
configuration. And when you also can't provide a session level set that
is default fall back if no stream specific is provided then you get to
choose between. These parameter constraints applies to all streams, or
no pre-provided parameters can be provided at all, and you need per
stream signalling.

35. Section 7.2.2:

          Informative note:  The above parameters apply for any stream
          sent by a declaring entity with the same configuration; i.e.
          they are dependent on their source.  Rather than being bound
          to the payload type, the values may have to be applied to
          another payload type when being sent, as they apply for the
          configuration.

I find this confusing. I don't know if it is a typo and should say
"independent of their source", or if it is the definition of source here
that is wrong.

It might be that the paragraph before the above:
   o  The parameters sprop-depack-buf-nalus and sprop-depack-buf-bytes
      describe the properties of the RTP stream that the offerer or the
      answerer is sending for the media format configuration.  This
      differs from the normal usage of the Offer/Answer parameters:
      normally such parameters declare the properties of the stream
      that the offerer or the answerer is able to receive.  When
      dealing with HEVC, the offerer assumes that the answerer will be
      able to receive media encoded using the configuration being
      offered.

actually needs to separate between end point specific configurations
that apply to the whole RTP session through the payload type or if is on
specific media encoding basis and thus needs to be connected to the
SSRC(s) that carries the particular media encoding.

36. Section 7.2.2:

      min_spatial_segmentation_idc  equal  to  or  larger  than  dec-
      parallel-cap.spatial-seg-idc of the capability point.  A stream
      that is sent based on choosing a capability point with parallel
      tool    type    't'    from    dec-parallel-cap    MUST    have
      entropy_coding_sync_enabled_flag     equal     to     0     and
      min_spatial_segmentation_idc  equal  to  or  larger  than  dec-
      parallel-cap.spatial-seg-idc of the capability point.

It looks like someone managed to turn this text into straight left and
right columns, this is not allowed in IETF, we use ragged rights.

37. Section 7.2.2:

   o  An offerer has to include the size of the de-packetization
      buffer,  sprop-depack-buf-bytes,  and  sprop-depack-buf-nalus,  in
      the  offer  for  an  interleaved  HEVC  stream  or  for  the  MST
      transmission mode.  To enable the offerer and answerer to inform
      each  other  about  their  capabilities  for  de-packetization
      buffering in receiving streams, both parties are RECOMMENDED to
      include depack-buf-cap.  For interleaved streams or in MST, it is
      also RECOMMENDED to consider offering multiple payload types with
      different buffering requirements when the capabilities of the
      receiver are unknown.

This paragraph contains two mentions of "interleaved", the only two in
the whole specification. I assume a copy and paste from RFC 6184 that
wasn't converted properly.

38. Section 7.2.2.:

 However, when out-of-band transport of parameter
      sets  is  used,  parameter  sets  MAY  still  be  additionally
      transported   in-band   unless   explicitly   disallowed   by   an
      application.

To me it doesn't appear that this rule is O/A specific. It should apply
also to declarative usage. I propose that this is moved to the parameter
definition itself.

39. Section 7.2.2.:

       o In MST, the answerer MUST be prepared to use the parameter
          sets included in sprop-vps, sprop-sps, and sprop-pps of all
          RTP streams that a particular RTP stream depends on, when
          present (either included in the "a=fmtp" line of SDP or
          conveyed using the "fmtp" source attribute), for decoding the
          incoming NAL unit stream.

I become uncertain how this really works. Especially in the context of
recv-sub-layer-id. So the offerer includes the parameter sets for all
the layers it intended to send. Then the answerer sub-sets that
selection using recv-sub-layer-id. Is the intention to say that the
answerer needs to try to apply the parameter sets that matches the
selected layers.

40. Section 7.2.2:
       o If the level to use in the answerer-to-offerer direction is
          equal to the default level in the answer, the offerer MUST be
          prepared to use the parameter sets included in sprop-vps,
          sprop-sps, and sprop-pps (either included in the "a=fmtp"
          line of SDP or conveyed using the "fmtp" source attribute)
          for decoding the incoming NAL unit stream.  Otherwise, the
          offerer  MUST  ignore  sprop-vps,  sprop-sps,  and  sprop-pps
          (either included in the "a=fmtp" line of SDP or conveyed
          using the "fmtp" source attribute) and the answerer MUST
          transmit parameter sets in-band.

Sorry, I missing something here. In the Answerer to Offerer direction,
there are no reason for the answerer to not provide parameter sets that
matches the offerer's declared receiving capability. Thus, why discuss
the "default" level?

41. Section 7.2.2:
       o In MST, the offerer MUST be prepared to use the parameter
          sets included in sprop-vps, sprop-sps, and sprop-pps of all
          RTP streams that a particular RTP stream depends on, when
          present (either included in the "a=fmtp" line of SDP or
          conveyed using the "fmtp" source attribute), for decoding the
          incoming NAL unit stream.

I am uncertain if this is intended to mean something else than, if
provided attempt to use them.

42. Section 7.2.2:
      Parameter sets associated with one source MUST
      only be used to decode NAL units conveyed in RTP packets from the
      same source.

The question is what is meant with "same source" in the above. Is it
SSRC, Media Source or Media Encoding, or even Endpoint.

43. Section 7.2.2:

                                          sendonly --+
            answer: recvonly, recv-sub-layer-id --+  |
              recvonly w/o recv-sub-layer-id --+  |  |
      answer: sendrecv, recv-sub-layer-id --+  |  |  |
        sendrecv w/o recv-sub-layer-id --+  |  |  |  |
                                         |  |  |  |  |
      profile-space                      C  X  C  X  P
      profile-id                         C  X  C  X  P
      tier-flag                          C  X  C  X  P
      level-id                           C  X  C  X  P

      C: configuration for sending and receiving streams

I don't get this usage or definition of C for these parameters.

So these parameters are receiver capabilities, and they needs to be
symmetrically used in the signalling, however the actually used values
in the transmission direction from an O/A agent only needs to be within
the receivers provided parameters. Thus, they are not a "configuration"
for the sending direction.

Also I really don't get the X's in the answer: recvonly,
recv-sub-layer-id, and answer: sendrecv, recv-sub-layer-id. The
answering agent is going to receive stream in both these cases, thus it
needs to declare the payload type, and these parameters MUST be included
(unless defaulted). So why is they marked with X?

44. Section 7.2.2:

                                          sendonly --+
            answer: recvonly, recv-sub-layer-id --+  |
              recvonly w/o recv-sub-layer-id --+  |  |
      answer: sendrecv, recv-sub-layer-id --+  |  |  |
        sendrecv w/o recv-sub-layer-id --+  |  |  |  |
                                         |  |  |  |  |
      interop-constraints                C  X  C  X  P
      profile-compatibility-indicator    C  X  C  X  P

I don't understand how these parameters really are used for receiver
capability declarations, so I don't understand why the Cs are C and not P.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Fri, 28 Feb 2014 23:31:03 +0000

Hi Magus,

Thanks so much for your very careful review. Please see my responses below to your comments #1-16. Responses to other comments are to come a bit later. For convenience, comments 16 onwards are removed in this email.

BR, YK

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Friday, February 28, 2014 7:47 AM
To: [email-masked]; [email-masked]
Subject: [payload] Comments on draft-ietf-payload-rtp-h265-02

Hi,

1. Move abstract

The current rules for the "first page" allows one to have the abstract before the Status of this memo. I would recommend that.

[YK]: OK. To be done in the next version.

2. Word issues:
A guess is that you are using MS Word for producing the draft. I seen at least two issues. A) Varying page lengths. B) Table of Content has strange spaces between section levels in the TOC.

[YK]: Right we are using MS Word, and I guess it probably takes some effort to switch draft product environment. However, I will try to improve the above two aspects when producing version -03 for submission. And I will try to learn a different I-D product environment in the future when I got some spare time :-).

3. Section 1.1.2:

[YK]: I also feel that adding "of" is better. To be added in the next version.

4. Use of RTP flow:
This draft includes three usage of RTP flow. This is a poorly defined term. I would suggest two things. Drop this usage and replace it with the approriate term from Grouping Taxonomy.

[YK]: OK.

5. Section 1.2:

I would propose to make clear that "multiple RTP streams" is within one or more RTP sessions.

[YK]: The motivation is to allow for the multiple RTP streams to be within either one or more RTP sessions. I hope changing "or multiple RTP streams" to "or multiple RTP streams within one or more RTP sessions" would be good to clarify this.

6. Section 3.1.1:

I wonder if this within paranthesis should include the corresponding values to those labels, i.e.  BLA_W_LP (16) to RSV_IRAP_VCL23 (23), ...

[YK]: It seems that including the values would be better. To be included.

7. Section 3.1.2:

Here is another case where I think these definitions should be aligned or simply use the one from Grouping Taxonomy.

[YK]: Agreed. Should also check the definition of "highest RTP stream" as well.

9. Section 3.1.2:

So these redefines the SST and MST terms in RFC 6190 to one that is single/Multi-stream instead of single/Multi-Session. I think this should be aligned with the outcome of the ongoing discussion in AVTEXT regarding grouping taxonomy.

[YK]: Agreed.

10. Section 3.1.2:

I note that this is defined as "Packet Stream" in taxonomy. Consider alignment. At least this definition is clear on what is meant.

[YK]: OK, will try to align herein too.

11. Section 4.1:

To my understanding when using single stream transmission the Decoding order is recovered soley from RTP sequence numbers and order of the NALUs within each RTP payload. This usage should be mentioned here as it affects the impact if anyone would inject other payloads in the same RTP packet stream.

[YK]: The current draft also supports interleaved transmission, wherein decoding order can be different from RTP sequence number order. Decoder order number (DON) values are used for de-packetization. 

12. Section 4.1:
  I am missing the SSRC usage for this RTP payload. In SST that is the classical identification of a particular encoding of a media source. But for MST the SSRC usage is different as one needs to know which SSRC in which RTP sessions that are associated. I think this dependency needs to be noted.

[YK]: OK. I'd appreciate if you could provide some concrete language for this. 

13. Section 4.6:
    DONL (optional)

I claim that using "optional" is the wrong word, it should be "conditional". The presence of the field are dependent on a signalling parameters, thus conditional on that parameter.

[YK]: OK. All instances to be changed.

14. Section 4.6:

I wonder why this is split into two paragraphs, the second paragraph's content is very important to understand what is said in the first.

[YK]: I think the reason is because that originally there were more conditions and the sentences were not as simple. But now it makes sense to merge them. To be merged.

15. Section 4.7:

I really wonder over the "+1" usage in the DOND field. That prevents two NALUs in an AP to have same DON. Which at least Section 4.5 hints to as being valid. If that is not valid, then Section 4.5 is in error.
Thus, this definition can cause issues and I don't see any issues with defining the field without the plus. That limits the difference to increment with a maximum of 255 instead of 256.

[YK]: I don't see there is an error. Section 4.5 allows two NALUs in an AP to have the same DON, but it does not require them to have different DONs. To me, both options would work, and it is just a matter of design taste. To my knowledge there are already some implementations of the payload format, thus I'd prefer to keep the "plus 1", though I don't have a strong opinion herein.

    0                   1                   2                   3

I wonder if this would be clearer by including some values for the payload header, here the Type of the payload header (type=48) appears to be highly relevant for this example. Maybe somehting like this?

    0                   1                   2                   3

[YK]: Good point. To be changed. Also for Figures 4, 8, and 9.