Subject: [AVT] Comments on draft-ietf-avt-rtp-h264-03.txt

From: Thomas Zeng <[email-masked]>
Date: Thu, 18 Dec 2003 14:13:35 -0800

Dear Steve W. and Other Authors:

I have some questions and comments on draft-ietf-avt-rtp-h264-03.txt
<http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-03.txt>:

*	Section 5.4: Packetization Modes
        There is this statement:
		The non-interleaved mode is targeted for conversational 
		   systems that may not comply with ITU-T Recommendation
H.241.  

	I tried to download H.241 spec but since I don't have ITU
subscription I am not able to find it. It would be helpful to add a brief
explanation (if feasible) on why this " may not comply with ITU-T
Recommendation H.241."   

	Reading a later section, I believe that reason is that H.241 does
not allow grouping of NAL units in RTP packets. Is that the only reason?

*	Section 5.7.2: MTAPs
There is a statement, quoted below:

	      "This memo does not specify how the NAL units within an MTAP
are ordered, but, in most cases, NAL unit 
	   decoding order SHOULD be used."

	There is a case where, when partial checksum is available, from
either UDP lite or DCCP, that the best way to order NAL units within a MTAP
is by the reverse order of NRI, since NRI indicates the relative importance
of a NAL unit, and that NRI=0 means that the NAL unit is not used as
reference to any other NAL unit. Hence it makes sense to apply partial
checksum on the first group of NAL units, upto but not including the NAL
units with NRIs equal to 0. Adding such a use case would show one more
advantage of current  MTAP structures.

*	section 8.1.     MIME Registration:
		It seems that the MIME parameters init-buf-time,
interleaving-depth and max-don-diff are somehow related, when at least two
of them are explicitely singalled. For example, if init-buf-time is too
small compares to interleaving-depth (although interleaving-depth is
specified not in time units, but in terms of number of NAL units), video
images can not be displayed after init-buf-time is reached. 
	      
	So I am wondering: wouldn't it make sense to specify
interleaving-depth in terms of time units, rather than number of NAL units?
In that case, max-don-diff would provide supplemental information about the
interleaving depth in terms of number of NAL objects. 

	Thanks, 
	-Thomas

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

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 20 Dec 2003 23:55:16 +0100

Hi Thomas,

with respect to your H.241 related comments:
When referencing (informatively) standards of non-IETF bodies, it is always 
very difficult to find a good balance between being sufficient explanatory 
and making sure that one is, in the long term, correct.

H.241 includes many different sections, only one of which is concerned with 
the RTP paylaod for H.264.  The current language of H.241 specifies (in 
addition to other, unrelated subjects) an RTP payload format for H.264 
which is a small subset of our draft.  As for major features, 
fragmentation, aggregation, the MIME/SDP stuff and a few other aspects are 
not in H.241.

The main reason for being vague is that we may well add, say, aggregation 
to the next version of H.241.  Or we may, once our draft has become an RFC, 
go ahead and retire the annex where the payload spec is specified in, and 
add a reference to our then RFC, maybe with some additional language that 
disables some mechanisms of the RFC.  In the ITU-T, we can do this as long 
as the changes are technically upward compatible, and it is common practice 
to do so.  In the IETF, on the other hand, the payload spec will stay as an 
RFC unchanged, until a new RFC with a future version of the payload spec is 
issues (and that spec may or may not be upward/downward compatible).

For this reason, I'm a bit reluctant to add more explanatory language to 
our draft.  Instead, I would even consider removing the H.241 discussions 
altogether.  However, doing this is not such a great idea either, because 
there will be implemetors with previous H.241 implementation experience, 
which would likely find it beneficial to get some hint that they do not 
have to start from scratch when implementing our draft.

More comments inline.

>advantage of current  MTAP structures.

That is why the language calls for a "SHOULD" and not a "MUST".  Doing what 
you suggests has benefits for the error resilience (when using the 
protocols you mentioned over bit error prone links) but has a negative 
impact on the latency.  I believe, most implementors of standards like this 
one should have a rough idea about the tradeoffs, and I don't think we need 
to spell it out in more detail.  Especially not when the only usage 
examples are not widely deployed (to say the least :-) protocols like UDP 
lite, or DCCP (or the modified FEC stuff).

>interleaving depth in terms of number of NAL objects.

Using time for specifying interleaving-depth would make sense if most/all 
of the NAL units of a stream were of roughly the same size.  However, this 
is not the case.  NAL units can be very small (i.e. for parameter sets, SEI 
messages, or Picture Delimiters) or large (slices).  A single picture can 
consist of dozens of NAL units -- this is not a theoretical option, but a 
very real scenario.  Interleaving of such NAL units (even within a picture) 
makes sense as it changes the error concealment properties.  Hence the 
interleaving is defined on NAL units, and it would not make sense to use 
time instead.

Thanks for your comments, and best regards,
Stephan

---

From: Tom Taylor <[email-masked]>
Date: Mon, 22 Dec 2003 12:22:11 -0500

Just as a matter of general information, the ITU-T has changed their 
procedures in recent years to make it easier for other standards groups 
to cooperate with them.  Any individual can order up to three of their 
documents per year without charge.  Select the appropriate option at 
http://ecs.itu.ch/cgi-bin/ebookshop.

Thomas Zeng wrote:

...
> explanation (if feasible) on why this " may not comply with ITU-T
...>