Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call

From: [email-masked]
Date: Wed, 13 Sep 2000 19:24:20 +0200

Dear all,

I would like to put the problem in a little bit wider perspective. Several
people perfectly understand the problem while some (?) others don't yet
understand the problem, while suggesting that we are wasting our time with
useless discussions. As Ajay stated correctly, it is the responsibility of
IETF to decide how to proceed with the current MPEG-4 ES proposal. The only
thing we can say right now is that several (perhaps even well respected)
MPEG members have substantial comments on the current proposal. As a
consequence it is likely that MPEG (members) will submit another proposal
for carriage of MPEG-4 ES to IETF. Though this proposal is expected to have
a high level of overlap with the current one, it is slightly different. IETF
may wish to take this into account when coming to a decision.

Kind regards,

Jan

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	woensdag, 13 september, 2000 18:52
To:	[email-masked]; [email-masked]
Cc:	Jan vanderMeer; [email-masked];
[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to
the last call

Kris, all,

I'm not so concerned about future upgradablity.  The ES format is there
now, but also we have a pretty good idea about how the Generic format is
going to look like. As an implementer of MPEG-4 server technology, that's
enough for me, and the official status of the proposals is not so
important. I'm sure there are others who have the same approach, and
together we'll build state of the art systems. This is assuming we use our
time to develop, and not spend it on useless discussions....

Regards,

z
soon the whole world will STREAM
==================================================================
Zvi Lifshitz				Phone +972(2)679-4788
[email-masked]			Fax +972(2)679-4789
Optibase Ltd.				Mobile: +972(53)461-787
http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
Send SMS from: 			http://isend.cellcom.co.il/English/Login.htm
==================================================================
> Come see us at:
Streaming Media Europe Earls Court Centre, Booth # 628, London, October
10th-12th, 2000

-----Original Message-----
From:	Kris Huber [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 6:30 PM
To:	Zvi Lifshitz; Colin Perkins
Cc:	[email-masked]; [email-masked]; 'Narasimhan, Sam
(SD-EX)'; [email-masked]'
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to	the last call

Hello Zvi, Colin [last comment before letting this discussion transition to
generic format]:

I think some of the discussion has resulted from misunderstanding of the
semantics of the payload type field apparently involving a change (by
IETF?)
from static to dynamic binding of an external "payload name" to this field.
In any case, the desire has been to see whether or not this format can
somehow be a subset of the soon-to-be more generic payload format.  Leaving
out lack of LATM in the draft generic format, the answer appears to still
be
"no", unless the payload name for the future format is assigned now and a
subset of its semantics, including how to read its adaptation field, are
included in draft-ietf-avt-rtp-mpeg4-es-03.  But this would be
unprecedented, I suspect (possible?  I don't know).  The other option is if
another static payload type is assigned and a future payload type of a
different name (MPEG SL format) uses the same payload type.

Why, some have asked?  To avoid the redundancy that we video compression
engineers hate so much!  How would this redundancy result?  Information
broadcast services begin initially using the Kichuchi-san payload format,
then have to make the decision later on between continuing to use it, and
either doubling their network bandwidth to do the new broadcasting services
or provide services support the new format (since the video ES data will
tend to dominate the bandwidth).  Allowing early-adopter non-upgradeable
devices to cease to function is another possibility, but that also has a
high cost if the number of such devices is large.  You might wonder about
an
approach in which a new enhancement payload type is used rather than a
single scalable payload type (e.g., generic format to add the enhancement
information), and perhaps this is considered the "right way".  The only
problem I see with this that the information goes in separate packets and
therefore additional buffer memory and synchronization functionality are
required.  Let me clarify, for point-to-point usage there is no efficiency
problem, it is only for the broadcast (multipoint) case.

It seems that static payload typing, or early assignment of payload name +
"Jan-byte" + other modifications would give the proposed interoperability
functionality.  Out of curiosity let me ask (Colin?), how is "there will be
no more static payload assignments" formally stated, with SHALL NOT or
SHOULD NOT?  Or is it a policy existing outside of an RFC?  How many
devices
would be obsoleted by a new static payload type?

Best regards,
Kris

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Sep 2000 20:24:51 -0400

>may wish to take this into account when coming to a decision.

We look forward to your proposal, however note that due to interactions
with the ITU (who which to use MPEG-4 ES as part of the next version of
H.323) you need to produce this as an internet draft within the next few
days or else we will be unable to consider it.

As an alternative, you may wish to propose explicit wording changes to
the Kikuchi-san proposal to bring it into line with your ideas. This 
discussion may reach closure faster if we have a more concrete design.

Colin