Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-05.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 3 May 2004 16:11:14 +0100

On Friday 30 April 2004 16:33, Magnus Westerlund wrote:
...
> If more people has comments they are appreciated if they can be sent no
> later than monday. I will try to do a update in the beginning of the
> next week, and submit that as soon as possible.

I have a few comments:

 - In Section 3, I agree with the likely initial applications of the 
   payload format. I would suggest adding text to note that the format
   is not limited to these applications, however.

 - The last paragraph of Section 5.1 mentions that the RTCP jitter
   statistic is not trustworthy. It would be more accurate to say
   that the RTCP jitter is not a trustworthy indication of network
   performance.

 - Table 1 should make explicit reference to NAL unit types 0, 30 and 31, 
   even if just to indicate that they are undefined.

 - A number of places talk about "optional" MIME parameters, but would be
   better using the RFC 2119 "OPTIONAL" language. For example:
    - Section 5.4, last paragraph on page 14
    - Section 5.5, second paragraph
    - Section 6.1, second paragraph on page 28
    - Section 6.2, first paragraph
    - Section 6.3
    - Section 6.4
    - Section 7.2
    - Section 8.2.1, 4th bullet point

 - In Section 5.4 (last paragraph on page 14) it states that `"No" in the
   "type 1-23" row indicates that an RTP payload cannot contain a single
   NAL unit whose type is in the range of 1-23, inclusive'. Please clarify
   what this refers to.

 - Section 5.5, second paragraph, is unclear what is done if the MIME
   parameter is not present.

 - The last paragraph of Section 5.7 mentions that Section 5.7.1 and 5.7.2
   define the three different types of aggregation unit. Should this be the
   four different types?

 - In Section 5.7.1, I would recommend moving the paragraph starting "The
   DON field specifies the value of the DON for the first NAL unit in an
   STAP-B...." to be immediately after Figure 5.

 - In Section 5.7.1, could an example of an STAP-A packet be provided?

 - In Section 5.7.2, is it correct that the DOND field is unsigned?

 - In Section 5.7.2, you might consider splitting the long paragraph on
   page 22, perhaps starting new paragraphs with "The structure of the
   multi-time aggregation units..." and "The timestamp offset field MUST
   be set..."

   If this was done, I would also move the contents last paragraph on page
   21 to the end of the first on page 22 (immediately after "...whereby n 
   can be 16 or 24").

 - In Section 5.7.2, an example of an MTAP24 would be valuable

 - In Section 5.8, the penultimate paragraph mentions that "A FU payload
   MAY have any number of octets and MAY be empty". Can you clarify when
   an FU payload may be empty, and why that is useful?

 - Section 6.1, second bullet point on page 28, should be clear that NAL
   units are duplicated in the application, not be generating duplicate
   RTP packets. Similarly, the discussion of gateway devices later in the
   Section should explain how the gateway aggregates/deaggregates NAL units
   without breaking RTP when gatewaying between IP networks with different
   MTU size (it will be an RTP translator, and will need to rewrite RTCP)

 - It may be appropriate to move Section 7 to be an appendix?

 - In Section 7.2, it's unclear where the 4th paragraph fits?

 - In Section 8.1, please clarify how the "max-dpb" parameter relates to
   the jitter buffer size, if at all? Similar for the deint-buf-req, 
   deint-buf-cap and int-buf-time parameters (this is mentioned at the
   end of page 40, but this is not obviously related to the earlier 
   definitions). 

 - In Section 8.1, please clarify how the "max-br" parameter relates to
   congestion control, if at all?

 - In the encoding considerations for the MIME type, may wish to note that
   file formats are defined elsewhere?

 - Section 8.2.2, first bullet point on page 44, suggest clarifying that
   "...the answerer must either maintain all configuration parameters or
   remove the media format..." is a MUST?

 - Section 8.2.2, second bullet point on page 44, similarly suggest that
   "The offerer must assume that the answerer supports the same
   configuration and basic capabilities that it is offering" should be a
   MUST?

 - Section 8.2.2, second bullet point on page 44: this is different from
   normal offer/answer usage. Do you have buy-in from the SIP community?

 - Is there any need to discuss use with RTSP in Section 8.2.2 or 8.2.3?

 - The draft needs to discuss congestion control, either within Security
   Considerations, or as a separate section.

Finally, the document could do with careful proof-reading for spelling and 
grammar mistakes.

Colin

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

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 06 May 2004 01:44:28 +0200

Hi Colin, AVTers,

first I want to thank Colin and Philippe for their careful review of the 
I-D.  A new version of the draft is in its final stages of preparation and 
will be made available shortly.  This new draft reflects Philippe's comment 
(by restructuring section 8.4 and several other places in the draft to 
avoid too much redundancy) and most comments of Colin as well.

Let me come back to a few items of Colin's list of which we don't know what 

>  - In Section 5.7.2, is it correct that the DOND field is unsigned?
I believe this is correct.  We can set the DONB (Decoding Order Number 
Base) to make it possible that only positive values are necessary, and this 
definition makes the wrap-around language easier.  Is there a need to spell 
this out explicitely?

>  - It may be appropriate to move Section 7 to be an appendix?
We think it may be better to leave this where it is, because this section 
explains concepts that are helpful to understand some of the following MIME 
parameter definitions.  Also, many older RTP payload specs have the 
packetization and de-packetization sections next to each other -- it seems 
natural to me.

>    file formats are defined elsewhere?
The problem here is that all file formats are still in their specification 
phase -- we can't reference them (yet).  And what good would a simple 
"elsewhere" do?

>  - Is there any need to discuss use with RTSP in Section 8.2.2 or 8.2.3?
I believe that in RTSP a simple, declarative process is used.  This sems to 
be well enough defined, and I'm not aware of any special considerations 
needed for RTSP.  Colin, did you have anything in particular in mind?

>    Considerations, or as a separate section.
I don't see any issues of congestion control beyond those of RFC3550, maybe 
with the exception of what is written in section 7.3 (it is possible to 
discard certain NALUs in translators, mixers, and receivers under certain 
conditions, and that could be used for congestion control in scenarios 
where mixers and translators are in use).  Hence we suggest to add a 
sentence in the security section that people need to observe RFC3550 
congestion control, and can possibly make the network's life easier by 
implementing 7.3.  Is there a need to say anything beyond that?

Thanks again for your helpful comments,
Stephan

---

From: Colin Perkins <[email-masked]>
Date: Thu, 6 May 2004 09:55:38 +0100

On Thursday 06 May 2004 00:44, Stephan Wenger wrote:
> I-D.  A new version of the draft is in its final stages of preparation
> and will be made available shortly.  This new draft reflects Philippe's
> comment (by restructuring section 8.4 and several other places in the
> draft to avoid too much redundancy) and most comments of Colin as well.
>
> Base) to make it possible that only positive values are necessary, and
> this definition makes the wrap-around language easier.  Is there a need
> to spell this out explicitely?

No. I was just checking that the text was correct.

> We think it may be better to leave this where it is, because this
> section explains concepts that are helpful to understand some of the
> following MIME parameter definitions.  Also, many older RTP payload
> specs have the packetization and de-packetization sections next to each
> other -- it seems natural to me.

Okay.

> >- In the encoding considerations for the MIME type, may wish to note
> > that file formats are defined elsewhere?
>
> The problem here is that all file formats are still in their
> specification phase -- we can't reference them (yet).  And what good
> would a simple "elsewhere" do?

Questions about the lack of a file format have been raised during IESG 
review of other RTP payload formats. Noting that the formats are being 
defined elsewhere will avoid the question later. 

> I believe that in RTSP a simple, declarative process is used.  This sems
> to be well enough defined, and I'm not aware of any special
> considerations needed for RTSP.  Colin, did you have anything in
> particular in mind?

Only that RTSP isn't mentioned in the draft: a simple "for example, RTSP," 
in the appropriate section will cover it.

> >  - The draft needs to discuss congestion control, either within
> > Security Considerations, or as a separate section.
>
> I don't see any issues of congestion control beyond those of RFC3550,
> maybe with the exception of what is written in section 7.3 (it is
> possible to discard certain NALUs in translators, mixers, and receivers
> under certain conditions, and that could be used for congestion control
> in scenarios where mixers and translators are in use).  Hence we suggest
> to add a sentence in the security section that people need to observe
> RFC3550 congestion control, and can possibly make the network's life
> easier by implementing 7.3.  Is there a need to say anything beyond
> that?

No, but that needs to be said (actually, reference RFC 3550 "and any 
applicable RTP profile, e.g. RFC 3551").

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

---

From: Dave Singer <[email-masked]>
Date: Thu, 6 May 2004 09:13:47 -0700

>defined elsewhere will avoid the question later.

Then perhaps it is appropriate to say a little more.

MPEG has defined the storage of AVC/H.264 content in ISO-family 
files, and that specification is published.  It's not expected to be 
used standalone, of course, as video is rarely found standalone 
(usually with audio).  So this does define the storage of AVC in MP4, 
3GP, 3GP2 and so on.  RTP packetization of this format shouldn't be 
excessively problematic, as it stores whole NAL Units in the same 
form as the RTP payload, and hint tracks can also be used if 
appropriate to pre-compute packetization.

The packing of AVC/H.264 into MPEG-2 transport streams is also 
defined, so it is also possible to encounter MPEG-2 
transport-streams-frozen-on-disk which contain H.264.  The RTP 
packetization of those would involve changing the NAL Units from 
start-code to length-fields, and I expect other operations.

Would text like this help?
-- 
David Singer
Apple Computer/QuickTime

---

From: Colin Perkins <[email-masked]>
Date: Fri, 7 May 2004 09:23:11 +0100

> Would text like this help?

I wouldn't go into too much detail, but certainly mentioning these points 
is worthwhile.

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