Subject: [AVT] Summary of the issues of draft-ietf-avt-rtp-h264-00.txt

From: Stephan Wenger <[email-masked]>
Date: Sat, 16 Nov 2002 20:12:42 +0100

Folks,

below the summary of the issues I want to see discussed in Atlanta.  Slides 
will follow on Monday the latest (will be on travel until then, but 
probably have Email connections before).

1. Status
The draft is a renamed, slightly extended and cleaned up version of 
draft-wenger-avt-rtp-jvt-01.  Important sections such as the MIME 
considerations are still missing and will be added later.  We do not plan 
to go for last call until H.264 is ratified, which may be the case in 
January, but could also take a longer time, depending on a number of issues 
that need to be resolved within JVT.  The draft is currently aligned with 
the most up-to-date editor's working draft, with the exception of a number 
of typos in the NAL unit numbering.
2. Open issues
There are two open issues that require discussions.  The first is about the 
timestamp offsets in the packet aggregation scheme.  Do the timestamp 
offsets of 8 bit and 32 bit make sense in a 90 kHz environment? Probably 
not, considering that H.264 ha a maximum frame rate of 180 fps.  Hence we 
propose to remove them, until someone shows us a useful application for 
these two offsets.
Secondly, there is the partly technical, and partly political issue of the 
alignment of the H.264 packetization with the MPEG-4 Simple 
packetization.  H.264 will not only be published by the ITU-T, but also as 
Part 10 of ISO/IEC 14496, commonly known as MPEG-4.  We hear requests from 
some individuals active in the MPEG systems group that they would NOT like 
to see an independent  packetization scheme for H.264 at all -- they 
consider it as part of the MPEG-4 framework and would prefer an MPEG-4 
packetization scheme as the only way to deal with this media type.  Others 
would accept an H.264 packetization if there is a common operation point 
between the MPEG-4 simple draft packetization and a scheme like the draft 
under discussion.  On the ITU side, many individuals including the authors 
of this draft voice a strong demand for a packetization scheme that is done 
specifically for H.264 (particularly when it comes to MIME type 
registrations), but a binary compatibility would be acceptable as long as 
it does not limit the functionality too severely.
So far, the authors believed that we have achieved the compromise of binary 
compatibility to a certain extent, but private conversations lead us to a 
feeling that this may not be the case.  Hopefully, the whole issue can be 
resolved easily by technically aligning the two drafts in question.  If 
this is not feasible, then we would like to hear guidance from ietf/avt, as 
the only responsible standardization group, on how to proceed with the 
H.264 packetization in general.
3. Editorial suggestions
We got a number of comments, both on the mailing list and in private, on 
necessary editorial work.  There are a few small issues that we may want to 
address if there is time left.  Slides will be prepared, however, 
considering the complexity of issue #2, likely never presented.

See you all in Atlanta,
Stephan

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

---

From: John Lazzaro <[email-masked]>
Date: Sat, 16 Nov 2002 14:42:11 -0800

> Stephan Wenger <[email-masked]> writes:
>
> If this is not feasible, then we would like to hear guidance from
> ietf/avt, as the only responsible standardization group, on how to
> proceed with the H.264 packetization in general.

I'm agnostic on the "MPEG compatibility" issue. This posting is just
to provide data on the MWPP experience with respect to mpeg4-generic
compatibility. This is how MWPP went about compatibility:

  -- MWPP is defined as a stand-alone RTP packetization,
     MIME type mwpp.

  -- To use MWPP under mpeg4-generic, mwpp packets MUST be
     mapped one-to-one onto mpeg4-generic packets. So, 
     there is a restricted set of mpeg4-generic packet 
     structures that are permissible to use with MWPP.

  -- When mpeg4-generic is set up in this way, the marker 
     bit needs to be set on every packet. To minimize confusion,
     the stand-alone MWPP packetization also sets the marker
     bit in every packet. But this was conservatism on my
     part, since most MWPP programmers will be new to RTP.

  -- As a consequence, identical bits are on the RTP wire for 
     "MWPP over RTP" and "MWPP over mpeg4-generic", the only 
     difference is the SDP.

I don't know enough about video codecs to say if this compromise with
realistic for H.264 -- a lot of the mpeg4-generic features you would
be declaring off-limits via the "one-to-one" mapping are there to help
video codecs, features which I assume you'd be doing yourself inside
your H.264 packetization.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------