MPEG-4 elementary streams in H.323
chsharp at CISCO.COM
Thu Oct 26 18:04:48 EDT 2000
At 11:22 PM 10/26/00 +0200, Stephan Wenger wrote:
>The MPEG-ES I-D is in IESG last call since 10/17. I believe that
>it is neither to SG16 and certainly not to MPEG to decide of its
>movement forward. For SG16 it is, however, relevant, that the
>assignment of an RFC number follows the IESG approval at
>considerable delay, typically several weeks. Unless someone
>is pushing the RFC editor really hard, the ES-I-D will not have
>a RFC number assigned in time for the SG meeting. I don't know
>what the SG should do regarding the determined code points
>referencing the draft.
It can sometimes take several months for the RFC to be issued after IESG
last call, depending on how long the RFC Editor's queue is.
There is at least one other example in ITU (SG13) of an ITU Recommendation
being decided (I believe Y.1310) with normative references to several I-Ds
with the understanding that these specifications would reach Proposed
Standard at some point and that the Recommendation would not be published
until the RFCs were published. You can even purchase a copy of the
pre-published version of Y.1310 with the normative references to the I-Ds
in it. So theoretically, you could do the same thing here. However, one
person described this method of doing things as buying a pig in a poke.
>If someone wants to stop the progress of the I-D now, the right
>action would be to announce so, including technical reasons,
>on the rem-conf reflector.
>Before doing so I would like you to consider the following:
>MPEG systems wants, for their own reasons, to promote MPEG
>systems, not only the media coding schemes. Many (including
>me) believe that the current system specification cannot be
>delivered over lossy networks. For that reason, the I-D focusing
>on the transmission of MPEG systems (SL-draft by Civanlar et. al)
>will likely move forward as "experimental" only, and not as
>standards track. I'm not sure that MPEG knows the difference,
>and I'm also not sure whether we in the ITU allow to normatively
>reference an experimental RFC. Would be nice to see this
I believe A.5 only allows normative references to Standards-Track RFCs, but
you could always change it to an informational reference. That also
obviates the tedious task of filling out the A.5 forms that are required.
>At 01:50 PM 10/26/2000 -0700, Gary Sullivan wrote:
>>ITU-T Systems and Video Experts,
>>I am at an MPEG meeting in France. There has been a lot of recent
>>discussion here and in the IETF on how to carry MPEG-4 data on IP
>>networks. I was asked by some MPEG participants to help explain
>>and understand the impact of this work on ITU-T SG16.
>>My understanding is that the H.323 community has been expecting
>>an IETF RFC with Proposed Standard status to be approved prior
>>to the November SG16 meeting sufficient to specify an RTP
>>packetization format for use in H.323 systems to carry MPEG-4
>>video (and perhaps audio) elementary streams.
>>However, there are some discussions here at MPEG about how to ensure
>>that any such specification is adequate not only for the needs of H.323
>>but also for MPEG-4 systems as well.
>>As a result, it appears that MPEG is poised to recommend tomorrow
>>that the current Kikuchi-san Internet Draft not be promoted to
>>Proposed Standard RFC status in the IETF. This seems to mean
>>that we are unlikely to be able to reach Decision status for this
>>feature in H.323 in November in SG16.
>>The SG16 community needs to understand this unfortunate situation
>>and its impact on the progress of work for the SG 16 meeting in November.
>>For help on this mail list, send "HELP ITU-SG16" in a message to
>>listserv at mailbag.intel.com
>For help on this mail list, send "HELP ITU-SG16" in a message to
>listserv at mailbag.intel.com
Chip Sharp Consulting Engineering
"The best way to pick a lock is with a key."
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd