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

[Magnus Westerlund <[e-mail]>]

Hi,

Here are some comments on the document.

1. Section 1, last sentence. I think you need to clarify the following.
 - That it uses its own identity rather then extending on the identity
of H.264.
 - That the deprecation only affects usage under SVC and not the normal
H.264 payload format. I would change the word deprecates, removes to
indicate that it doesn't change any existing only removes a not needed
functionality.

2. Section 3.2: I think this text is a bit unclear. It can to easily be
interpreted as that once an parameter set has been used it can't be
changed. But I assume that this hasn't been changed and that you can
change the active set and have the sets changed during the session by
overwriting them. I think you should tell when the sets can be changed,
rather also to make it clear. Because that do create some extra complexity.

3. Section 3.3, R and RR bits. Is this MUST in both send and receive.
And what do you do if you find an violation. To be extendable a clear
receiver policy needs to be defined, chose between discard NAL or Ignore
bit.

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.

5. Section 6.2:
"Please see section 5.1 of [RFC3984].  The following applies in
   addition."

I think you should reomve the second sentence.

6. Section 6.4, I think you need to extend a bit on what is meant with
protecting in this section. I understand it that it might be any RTP or
network transport mechanism that affect the probability of delivery of
the packet, including network QoS, FEC, RTP retransmissions, even
scheduling behavior if one has knowledge about a local link with such
properties.

7. Section 6.5, Is single nalu mode allowed for the base layer? As that
is following 3984, it is not clear.

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.


9. Section 6.9, why is the F bit redefined here? It seems much better to
leave this bit alone to not complicate processing by having specific
processing for it for this NALU type. Isn't the reasonable usage the
same as for the aggregation NALU types in RFC 3984?

10. Section 6.9, definition of A bit is not understandable. To much new
concepts introduced in the section. I would recommend that the concepts
are explained in the introductionary part, rather then here in the
specification part. "Layer Picture" also needs to be explained.

11. Section 6.9, what is "temporal scalable layer switching point"?

12. Section 6.9, are the definition, like "The P bit MUST be set to 1 if
all the layer pictures containing the target NAL units (as defined
above) are redundant pictures." meant to apply only to NALUs within this
packet but also to NALUs in any other packet?

13. Section 6.9, there is little concreate motivation why PASCI NALU and
the additional signalling flags are needed. Making an observation it
seems that the PASCI has only limited appliability. First of all the
level of aggregation within in a single RTP packet will not be that high
that digging out the NALU headers will be a significant problem. Can we
really expect that more than a few VCL NALUs to be present in the same
packet. In some cases some SEI and parameters set NALUs may also appear
but that will not be that common that it will be a significant issue. It
is after all read and jump operations based on the NALU field length.
Thus making the jumping around operation on a per NALU become the following:

1. Read NALU type,
2. read NALU length field (dependent on NALU type)
3. perform 1 at current + NALU size + C.

Are there any great benefit from grouping the SEI NALUs in this NALU
type? To me it seems that they could just as well be placed in the
normal position. And if this information is so important please clarify
which SEI messages that should be included here.

Also the additional signalling information, I am missing how hard (if at
all possible to derive) is to get from the NALUs itself. Is this
additional information that doesn't exist otherwise in the bit-stream.
Also how useful is it?

My big question is: Is the PASCI motivated, despite being optional to
utilize, it complicates the specification and implementations to smaller
or bigger degree.

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.

15. Section 9.1: sprop-interleaving-depth: Will usage of interleaving be
allowed in combination with layering? They are after all to certain
degree orthogonal usage. You can after all have interleaving-depth 0 and
still use layering with DONs. I think there need to be a separation on
the buffering required for inserting the layers and for interleaving.

I would propose that this is thought over and possibly new parameters
are defined to better indicate properties of the layered stream when it
comes to buffering.

16. Section 9.1, sprop-scalabilit-info: Please include referense to Base64.

17. Section 9.1, sprop-leyer-ids: Why is it needed to base64 encode the
DID,QID and TID numbers? Aren't there a point of keeping these human
readable?

18. Section 9.2.2: Here is some work. I think we need to rework the
offer/answer of 3984 with the additional complexity of the layering.

19. Section 9.2.3: This also needs clarification.

20, Section 10, I think you will need to elaborate on why there are no
extra security issues due to the layering.

21. Section 13.3, Mentioning FGS when it is not yet supported by SVC. Is
that not going a bit to far? I think MGS is good enough for motivating
in this use case.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

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