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

From: Zvi Lifshitz <[email-masked]>
Date: Mon, 11 Sep 2000 16:09:03 +0200

Jan, all,

The simplest solution IMO is, as I proposed in the previous message, to use 
the first byte of the payload in the Generic format to indicate the length 
of the following extra header. No change is needed to the ES format.

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:
IBC Amsterdam RAI, Booth # 2.251,  September 8th-12, 2000
Streaming Media Europe Earls Court Centre, Booth # 628, London, October 
10th-12th, 2000

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Monday, September 11, 2000 1:04 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to 
the last call

Stephan, Colin,

Stephan wrote:

Regardless how the generic payload format of the future may look like,
systems can be most easily designed to support both payload types.

True. But the issue is different. Mobile devices that are build to support
the current MPEG-4 ES draft will not be capable to decode RTP payloads with
the additional info flagged by the first byte in the payload. (Note that 
the
additional info would be needed by other applications that include usage of
the same stream)

In the past of MPEG, the use of "reserved fields" proved extremely 
powerful.
To not allow them here would be a failure in my opinion. Of course it would
be best to avoid unnecessary overhead. Therefore it would be most 
attractive
if the inclusion of the additional field is indicated, for example by a 
flag
or by a parameter that goes with the payload type. I understand that in the
RTP header no such flag is available, but that the use of a parameter
associated with the payload type would be possible. Would that be a good 
way
to solve this ?

Regards,

Jan

************************
Jan van der Meer
Philips - Digital Networks
Building OAN-4
P.O. Box 80002
5600 JB Eindhoven
The Netherlands
Phone +31 402 735 774
Fax +31 402 735 545
Email [email-masked]
************************

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	vrijdag, 08 september, 2000 13:05
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to
the last call

Folks,

>1.  We suggest to have a room for future extension of RTP header (e.g. one
>byte of payload header at the beginning of the payload part) to make the
>devices implementing this draft interoperable with the bitstream based on
>the generic format under development. For example, it is possible to use
>the reserved byte to specify the length of the payload header of generic
>payload format. Then the device implementing this draft can play the
>bitstream of generic payload format by simply skipping those bytes.

I'm not sure whether this is a good idea.  We would waste one byte of
payload (from RTP's point of view) for something which is probably not
used by any systems currently under discussion or development.

Regardless how the generic payload format of the future may look like,
systems can be most easily designed to support both payload types.
RTP's PT mechanism has enough numbering space to support both.
Capability announcement/negotiation will be different and have to
be redesigned anyway for anything more capable then what is
currently in the MPEG-4 ES draft.  Annoucing/Negotiating another
PT for the new generic payload spec will not make a difference.

When, in the future, a generic payload type would be available that
includes a super set of functionality of the MPEG-4 ES payload format,
then we could declare the MPEG-4 ES RFC as obsolete, thereby
advising people to move over to the new, generic payload type.

Or, it may also be possible to have two payload specs coexisting,
one for simple audio/video ES packetization only, the other containing
more (the rest of?) functionality of MPEG-4.  This does not sound
like a bad idea to me, because the necessary demands of functionality
both from the network (in terms of QoS) and implementation efforts
(single audio/visual ESs vs. system layer, flexmux, whatever...) are
very different.

Please let the header format as is -- no more changes, otherwise you
can almost certainly forget the deadline you want to meet (mid
November's SG16 meeting).

Stephan

---

From: Zvi Lifshitz <[email-masked]>
Date: Mon, 11 Sep 2000 18:29:14 +0200

Indeed.

z
Send SMS from: 			http://isend.cellcom.co.il/English/Login.htm ==================================================================
IBC Amsterdam RAI, Booth # 2.251,  September 8th-12, 2000
Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000

-----Original Message-----
From:	Colin Perkins [SMTP:[email-masked]]
Sent:	Monday, September 11, 2000 5:22 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]; [email-masked]
Subject:	Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call 

--> [email-masked] writes:
>the additional info flagged by the first byte in the payload. (Note that the
>In the past of MPEG, the use of "reserved fields" proved extremely powerful.
>be best to avoid unnecessary overhead. Therefore it would be most attractive
>if the inclusion of the additional field is indicated, for example by a flag
>associated with the payload type would be possible. Would that be a good way
>to solve this ?

In RTP, that parameter is the payload type field. 

I really don't understand why this additional field will add value. It 
allows for systems to skip data which they don't understand, how is this
different from using the payload type for the same effect?

Colin

---

From: Zvi Lifshitz <[email-masked]>
Date: Mon, 11 Sep 2000 20:01:31 +0200

[Herpel Carsten:]

One assumption is that huge numbers of devices will be out there that use
the ES payload format. Assuming that these devices cannot be upgraded to a
newer payload format!
Then applications come up with more functionality, using MPEG-4 Systems. 
New
devices will exist that know how to use this functionality. Old devices
should at least be able to understand the (unmodified!) MPEG-4 Video over
RTP stream. Since the old devices are not reprogrammable, they cannot be
upgraded to another payload format. So the old format needs to be by design
compatible to any new format.

[Reply:]

How would it help? The new format will come with a new payload type, and if 
the old devices don't know this payload type they will not read it because 
they don't know what it is. In other words they will not know they know how 
to read it...

So they will need to be reprogrammed to identify the new payload type. 2 
extra lines of code and they will know how to read it even if it's not 
identical to the old one.

And BTW I'm not sure the assumption is real. The two formats are there more 
or less at the same time. One is a little bit advanced in the procedure, 
but I don't believe this will create the "huge numbers" of devices that 
know one and not the other.

Regards,

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Tue, 12 Sep 2000 14:22:11 +0200

Dear Jan,

You clarified the scenario, but not how it relates to the discussion.

Regards,

z
[email-masked] <mailto:[email-masked]> 			Fax
+972(2)679-4789

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 12:44 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in
response to the last call

Stephan, Carsten, Colin, Zvi and others,

It surely is a clash of worlds. And I think we did not come to full
understanding yet. I think I understand the point made by Stephan, but I
also think that Carsten did make the real point. Let me explain below with
an example.

A service provides several multicast sessions to mobile devices using the
simple MPEG-4 ES payload format. This is done during a sport event such as
the "Tour de France" providing the performance of a number of favorite
racers. At the same time there is a broadcast coverage of the event,
providing a more global overview. Now, when I am "on the road" I watch my
own favorite racer on my mobile device. When at home, I watch the broadcast
coverage on my TV. This TV has the capability to also receive mobile
services. Over the normal broadcast channel an MPEG-4 application is
delivered that allows me to display the multicast streaming of my favorite
racer on TV, as an overlay over the broadcast video. For this purpose, some
information is needed that is contained in an SL header. In order to be
bandwidth efficient on the mobile network, the same multicast session is
used as for mobile devices.

Now follows an essential assumption: the mobile devices are not_upgradable;
these dedicated devices are not capable to even process a single byte to
upgrade their functionality. If this assumption is true, they need the
capability to accept the additional bytes from day one. Otherwise two
separate multicast sessions are needed.

In my understanding there are no higher level protocols involved. And the
essential question is whether these mobile devices are indeed not
upgradable. It is my guess that upgradability is not a requirement for such
devices, but only a feature that cannot be relied upon.

I hope this clarifies.

Kind regards,

Jan

---

From: [email-masked]
Date: Tue, 12 Sep 2000 15:50:36 +0200

Dear Zvi,

I thought I did. What I try to say is: to have this type of functionality in
future, you need to allow for inclusion of the additional bytes in the
MPEG-2 ES payload now.

Regards,

Jan

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

Dear Jan,

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 12:44 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

I hope this clarifies.

Kind regards,

Jan

---

From: Zvi Lifshitz <[email-masked]>
Date: Tue, 12 Sep 2000 17:04:59 +0200

It will not help, because when you get the new payload in the future the old
devices don't recognize the payload type and will not handle it.

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 3:51 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Dear Zvi,

Regards,

Jan

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

Dear Jan,

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 12:44 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

I hope this clarifies.

Kind regards,

Jan

---

From: [email-masked]
Date: Tue, 12 Sep 2000 16:20:59 +0200

Zvi,

It is not another payload type; it's the MPEG-4 ES one, but with some other
bytes which are not understood by the mobile device but which are allowed to
be there.

Regards,

Jan

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

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 3:51 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Dear Zvi,

Regards,

Jan

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

Dear Jan,

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 12:44 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

I hope this clarifies.

Kind regards,

Jan

---

From: [email-masked]
Date: Tue, 12 Sep 2000 16:27:22 +0200

Colin,

The composition info is sent with the broadcast; with the mobile service
only the information needed to allow for the composition is sent.

Regards,

Jan

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	dinsdag, 12 september, 2000 16:22
To:	Jan vanderMeer
Cc:	[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject:	Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to
the last call

I don't understand why you don't simply send the composition information
along with the broadcast signal? Sending it with the mobile signal (where
it is useless unless the broadcast signal is also received) seems to be a
waste of mobile capacity.

Colin

--> [email-masked] writes:
>Sent:	maandag, 11 september, 2000 21:05
>To:	[email-masked]
>Folks
>>What happens here is a clash of worlds.
>
>Clearly, it is!
>
>But I don't think that Carsten came to the real point here.
>
>IMHO, the main point is that MPEG-folk seem to think that
>the media stream (RTP/payload/MPEG) should be self-contained
>and  independent from the higher protocol layers that perform the
>capability exchange/announcement (and other things such
>as call establishment etc.).
>IETF/AVT folk (including me), however, make the implicit
>assumption that media cannot be seen independently from
>higher protocols.
>
>The latter, however, is not an assumption -- its the plain truth,
>especially after AVT made it the general policy to no more
>assign static payload types for media coding.
>
>This means, that RTP systems rely (and cannot live without)
>some external form of capability exchange/announcement, which,
>as a minimum, dynamically (per call) associates a freely chosen
>number with a certain payload (e.g. MPEG-4 ES or, in the future,
>MPEG-4 generic/SL/whatever).  The information which payload is
>to be transmitted is in H.245, for example, coded in ASN.1.  For SIP
>systems, the relevant information is transmitted in ASCII form,
>where the payload types (such as MPEG-4-ES) has typically
>a MIME registration.
>
>That is why Colin and me and others insist that there is no need to
>duplicate this type of information in the media stream.  Every
>system that uses RTP in a standard-compliant way has already
>the functionality build in that is necessary to distinguish between
>different payload types.
>
>Very simple to achieve.  Have two payload types, MPEG-4-SL and MPEG-4-ES.
>Try to negotiate MPEG-4-SL.  If the other system rejects, use MPEG-4-ES.
>This is how things are done, at least in H.323, all the time.
>
>Stephan
>

---

From: Zvi Lifshitz <[email-masked]>
Date: Tue, 12 Sep 2000 17:28:53 +0200

The ES payload format is not configurable and will never have extra SL
header fields, so what is the future functionality of this format you have
in mind?

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 4:21 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Zvi,

Regards,

Jan

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

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 3:51 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Dear Zvi,

Regards,

Jan

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

Dear Jan,

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 12:44 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

I hope this clarifies.

Kind regards,

Jan

---

From: [email-masked]
Date: Tue, 12 Sep 2000 16:44:45 +0200

Zvi,

I would like to allow for some optional bytes that proceed the ES payload,
e.g. starting with a byte signaling the number of optional bytes. But that
would burn at least always one byte signaling no more bytes. Therefore it
would be better to find another signaling method, e.g. two payload types of
MPEG-4 ES, one with and one without the additional bytes. Does not look
elegant of course and therefore I am still hoping for a better solution.

Jan

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

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 4:21 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Zvi,

Regards,

Jan

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

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 3:51 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Dear Zvi,

Regards,

Jan

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

Dear Jan,

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 12:44 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

I hope this clarifies.

Kind regards,

Jan

---

From: Zvi Lifshitz <[email-masked]>
Date: Tue, 12 Sep 2000 18:00:03 +0200

Dear Jan,

I think there is a confusion. The ES format has been proceeded as an
Internet Draft and there is no more time for comments. I don't think it's
possible to make this format extendable, because, first, I'm not sure this
is at all possible in IETF. Even if it is, text on extendibility, both
syntactically and semantically must be included in the draft, and it is not.
So the only thing we can do is proposing that in the Generic format the
extra SL header that is contained in the payload will be preceded by a
length byte, so it will be readable by systems that don't use MPEG-4
Systems.

In any case, the request to have an extra byte in the ES format makes,
IMNSHO, no sense.

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 4:45 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Zvi,

Jan

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

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 4:21 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Zvi,

Regards,

Jan

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

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 3:51 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Dear Zvi,

Regards,

Jan

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

Dear Jan,

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 12:44 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

I hope this clarifies.

Kind regards,

Jan

---

From: [email-masked]
Date: Tue, 12 Sep 2000 17:15:18 +0200

Zvi,

I don't think there is any confusion. If no such bytes are allowed, the
scenario I gave will not be possible. Which in my view would be a mistake.
From MPEG point of view a serious mistake.

To allow for extensibility in the "generic format" will solve problems, but
not this one

Regards,

Jan

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

Dear Jan,

Regards,

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Tue, 12 Sep 2000 18:27:11 +0200

The scenario you gave is not possible, for the reasons I previously
explained.

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 5:15 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Zvi,

Regards,

Jan

---

From: [email-masked]
Date: Tue, 12 Sep 2000 17:39:10 +0200

Which is not a mistake ????

Regards,

Jan

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

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 5:15 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Zvi,

Regards,

Jan

---

From: Zvi Lifshitz <[email-masked]>
Date: Tue, 12 Sep 2000 19:02:37 +0200

Mistake is when you can do something and you do it wrong. Here we could not
do anything, except asking to reject the Kikuci-san proposal and start
another one. Is that what you wanted?

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 5:39 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Regards,

Jan

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

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 5:15 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Zvi,

Regards,

Jan

---

From: Zvi Lifshitz <[email-masked]>
Date: Tue, 12 Sep 2000 19:18:10 +0200

[Narasimhan, Sam (SD-EX):]

If this draft were to say that receivers should parse over the
adaptation bytes and not process them (as this draft does not
define these), then such receivers will be able to process payload
from future draft (from MPEG)

[Reply:]

They will not, because they don't know the payload type of the future draft
therefore they will not know they can process payloads from the future draft
even though they can.

If they know, they also know that the future draft has extra header info. So
work on the future draft, not on the current draft.

Regards,

z

---

From: [email-masked]
Date: Tue, 12 Sep 2000 15:53:28 -0500

> 
> Zvi,
> 
>  I am assuming that the payload type from the future draft
> could be set to the same value as this draft, if this
> draft can accommodate the change.
> 
> Regards
> Sam Narasimhan
> Motorola
> 

If guess that what you assume is rather that the current and future drafts
will have the same  NAME and that the future draft will be backward
compatible to the current draft. Is that it?

Regards, David.

---

From: "Luthra, Ajay (SD-EX)" <[email-masked]>
Date: Tue, 12 Sep 2000 17:48:52 -0400

Yes, if WG-11 does not think Kikuchi-san's proposal meets the needs (I am
not saying whether it does or does not - we are currently debating it here).
As I understood, conclusion in Beijing was to start WG-11's proposals on how
to carry different MPEG-4 streams (ES, SL etc) on RTP. If that aligns with
Kikuchi-san's proposal then fine otherwise have "official" proposals from
WG-11 according to what its experts collectively think are the best ways to
carry MPEG-4 streams. As I mentioned before, alignment with Kikuchi-san's
proposal was desired but not required. 

Ajay

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Tuesday, September 12, 2000 10:03 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 5:39 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Regards,

Jan

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

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 5:15 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in

Zvi,

Regards,

Jan

---

From: [email-masked]
Date: Tue, 12 Sep 2000 17:25:37 -0500

> 
> 
> David,
> 
>  I am assuming that the 2 drafts will use the same
> 'payload type' and the header fields before the
> ES so that the server can send the same RTP packets
> which can be assembled by either of the receivers.
> I am not suggesting the same NAME for the drafts.

As it has been said, the payload type is not static. The name is fixed but
if you assume that the two formats are using different names, how could a
receiver which has implemented the current payload format even know the name
of a future (and thus non assigned) payload format? 

David.

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 09:49:08 +0200

Dear Ajay,

In Paris we came the conclusion that MPEG can support both the ES format 
proposed by Kikuci-san, and the Generic format (Civanlar et al), since with 
a proper use of SLConfig the first becomes a subset of the second (at least 
for video). Therefore we didn't find a reason to delay the process of the 
ES draft. All seemed pretty nice, until this issue of the extra byte came 
up and created an awful mess. We can still go forward, if everybody 
understands that the extension mechanism is dealt by the Generic format, 
and is not necessary and can serve nothing in the ES draft.

Regards,

z

-----Original Message-----
From:	Luthra, Ajay (SD-EX) [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 6:18 PM
To:	'Zvi Lifshitz'; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response 
to	the last call

Dear Zvi,
  Now, I am confused by your statement.  As we discussed in Beijing, the ES
format draft being considered by IETF is proposed by individuals and we can
not and should not control what they input to IETF. That is IETF's 
business.
What we had agreed to do in Beijing was to come up with WG-11's
recommendation and contribution on how to carry ES (as well as SL and other
streams types) in RTP and to let IETF know that that contribution is coming
(by Oct 2000) and make them aware that WG-11 contribution may or may not
align with what is being considered by IETF.  As I understand, WG-11 has
done that.

  So, as agreed in Beijing, compatibility with what individual 
contributions
IETF is considering is not a requirement (desired but not required).
Therefore, if we think we need additional byte then let us put it in 
WG-11's
contribution to IETF on how to carry ES. The discussion should be on 
whether
we need additional bytes or not, and not whether it is compatible with what
was proposed to IETF by some other authors. I know it is a mess and is
partly (major part) due to our fault in WG-11 and partly (minor part) due 
to
IETF process. In Beijing, WG-11 had asked people to not to submit 
individual
contributions and/or withdraw their inputs until this matter is fully
discussed in WG-11. The decision to freeze or withdraw is not WG-11's. 
There
is nothing we can do about it at this stage. It is water under the bridge.

  So, let us just discuss whether the additional bytes, as proposed by Jan,
make sense or not. In that regard, I think it makes good sense. It gives 
you
lot of flexibility that will be needed in future. We are still reaping the
benefits of the flexibility of MPEG-2 systems. I really do not understand
the reason for not accepting it.

With regards,
Ajay

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 09:51:37 +0200

Sam,

It seems you want the current draft to be modified in the future. Then:

1. I don't believe this is possible.
2. I don't think this is necessary.

Regards,

z

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

Zvi,

Regards
Sam Narasimhan
Motorola

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Tuesday, September 12, 2000 10:18 AM
To: Narasimhan, Sam (SD-EX); [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call

[Reply:]

Regards,

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 09:56:16 +0200

I don't think Colin needs my support, but I will nevertheless give it out of frustration. This is a simple truth.

Regards,

z

-----Original Message-----
From:	Colin Perkins [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 6:24 PM
To:	Luthra, Ajay (SD-EX)
Cc:	'Zvi Lifshitz'; [email-masked]; [email-masked]; [email-masked]
Subject:	Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call 

--> "Luthra, Ajay (SD-EX)" writes:
>not and should not control what they input to IETF. That is IETF's business.
>  So, as agreed in Beijing, compatibility with what individual contributions
>Therefore, if we think we need additional byte then let us put it in WG-11's
>contribution to IETF on how to carry ES. The discussion should be on whether
>partly (major part) due to our fault in WG-11 and partly (minor part) due to
>IETF process. In Beijing, WG-11 had asked people to not to submit individual
>discussed in WG-11. The decision to freeze or withdraw is not WG-11's. There
>make sense or not. In that regard, I think it makes good sense. It gives you

Because we have a mechanism for extensibility in RTP via the payload type.
This extra byte provides no advantage - all the examples which have been 
proposed can be done without using this field - and is incompatible with 
existing practise.

Colin

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 09:57:57 +0200

[Colin Perkins:]

How are the enhancements signalled? 

[Reply:]

How indeed?

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 09:58:57 +0200

If it has the same name then it is the same format. See my previous comment.

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 10:53 PM
To:	[email-masked]; [email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to	the last call

Regards, David.

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 10:27:44 +0200

So how would old devices recognize the new name?

z

-----Original Message-----
From:	Narasimhan, Sam (SD-EX) [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 11:34 PM
To:	[email-masked]'; [email-masked]; [email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to	the last call

David,

Best Regards
Sam Narasimhan
Motorola

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 10:31:35 +0200

See my previous reply to you.

z

-----Original Message-----
From:	Luthra, Ajay (SD-EX) [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 11:49 PM
To:	'Zvi Lifshitz'; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to	the last call

Ajay

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 10:30:02 +0200

The receiver which
understands enhancements will parse the information present
in the stream.

[Reply:]

How will it know that there are enhancements?

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 10:32:41 +0200

;-)

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 12:26 AM
To:	[email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to	the last call

David.

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 10:35:34 +0200

Jan,

Your nice proposal can be incorporated in the Generic format. I hope we managed to explain why it is useless with the ES format.

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 5:28 AM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call

Colin, all,

I think it is important to keep in mind that often MPEG uses in-stream
signaling. For example, after the length byte, the adaptation field may
start with an identifier that specifies the sort of enhancement. Based on
this approach, the following would be needed :

1) Define an MPEG-4 ES payload format that allows for an adaptation field
without defining the meaning of the adaptation field.

2) Define the meaning of the adaptation field in the "generic MPEG-4
specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "generic
specification" defines the use of exactly_the_same payload type as defined
in 1). The only difference is the defined use of the adaptation field.
Whether or not an SL header is carried is signaled in the adaptation field.

3) Next to the payload types for MPEG-4 ES and SL streams, the "generic
specification" may also define payloads for other streams, such as FlexMux
streams. For these, other payload types will be needed.

Now the initial services start using the MPEG-4 ES payload format; though
the adaptation field is not used, this field is allowed to occur. Future
services may use exactly the same payload type, but with the adaptation
field as defined by the "generic specification".

It may also be important to understand that the presence of the adaptation
field is intended to be transparent from RTP point of view and for the
session in general. The adaptation field serves MPEG-4 system purposes which
are fully orthogonal to RTP and the streaming session.

Kind regards,

Jan

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 10:42:34 +0200

Hi Guido,

You didn't make the point clearer, just showed how messy we got with this 
idea of extending the ES format.

Therefore I propose to kill this discussion about modifications to the ES 
format, and concentrating how to improve the Generic format, if necessary.

Ciao,

z

-----Original Message-----
From:	Franceschini Guido [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 9:22 AM
To:	'Narasimhan, Sam (SD-EX)'; [email-masked]'; 'zvi'
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response 
to	the last call

Hi all,
my own considerations on this thread

In RTP and IETF procedure terms, I understand this thread on the extra byte
as:
1) modify the current ES draft to accomodate a payload header starting with
a byte indicating its length. No specification of what the payload header
carries
2) allow the modified ES draft to enter the RFC standard track and be 
widely
implemented
3) propose a new draft for 'generic' ES or SL mapping, which is identical 
to
the modified ES draft but also defines what the payload header carries
4) the 'generic' draft becomes standard and _obsoletes_ the ES draft.
Devices implementing the ES draft will skip the payload header information
but still understand the media content.

Well, I think we have a technical problem here, which has nothing to do 
with
usual practices / procedures / timelines.
The problem that I see is that:
- the ES draft defines 2 Payload Formats: 1 for Audio, 1 for Video
- the 'generic' draft will define 1 Payload Format only, and the type of
media (Audio, Video, BIFS ...) being carried will be specified using MPEG-4
Object Descriptors.

What we achieved at the Paris meeting (before discussing this extra byte
feature) has been to allow MPEG-4 Systems terminals implementing the
'generic' draft to use the ES draft as well withouth any need to duplicate
implementations (i.e.: the ES draft is a subset of the generic draft in the
Data Plane).
Now, the 'extra byte' proposal would allow devices implementing the ES 
draft
to be compatible in the Data Plane with the 'generic' format, too.

Compatibility in the Control Plane (i.e. Payload Type
negotiation/announcement) was not considered in Paris.
I believe that devices implementing the 'generic' draft would have no
difficulties in understanding 1 more SDP keyword or MIME type as introduced
by the ES draft.
But the reverse is more difficult and tricky. As I outlined above, the
'generic' draft would not specify by itself the type of media content it is
carrying, and would rely on the Object Descriptor to do that. If the goal 
is
to allow devices implementing the ES draft to be compatible with future
content delivered by means of the 'generic' draft, than we need to specify
NOW how to duplicate the information in the OD so that the media type is
made explicit for those devices. And then we will have to accept that
devices implementing MPEG-4 Systems get the indication of the media type
twice :-(

Did I make the point clear ?

Guido

> ----------
> From: 	Zvi Lifshitz[SMTP:[email-masked]]
> Sent: 	Wednesday, September 13, 2000 9:51 AM
> To: 	'Narasimhan, Sam (SD-EX)'; [email-masked]'
> Send SMS from:
> http://isend.cellcom.co.il/English/Login.htm
> Send SMS from:
> http://isend.cellcom.co.il/English/Login.htm

---

From: Herpel Carsten <[email-masked]>
Date: Wed, 13 Sep 2000 12:02:53 +0200

[Zvi]

[Carsten]

Amen! (But I do think Guido made a good summary of the problem, though ;-)

May I mention again that for the Audio portion of the ES payload format the
extra byte does not buy anything anyway, since here we have the situation
that the ES format uses LATM while the generic one as it stands today does
not. 

We said in Paris that we want to correct MPEG-4 Systems in order to allow
multiple AUs per SL. But I don't recall we said that we want to put LATM
inside SL packets. So incompatibility between payload formats is guaranteed,
no matter whether we have the Jan-byte ;-) or not. (Disclaimer: This
observation is meant to trigger discussion about the _generic_ format ;-)

Regards,
Carsten

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 18:32:51 +0200

Sam, what you want either will not work or is not necessary.  I'm sorry we didn't manage to convince you. I've run out of words...

Regards,

z

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

Zvi,

1.  I thought all the comments were to make changes to 
    Kikuchi-San's draft NOW - not later. If it just added
    the adaptation length followed by length bytes before
    the ES payload (in the RTP payload), then content
    authors could author content that can play on receivers
    that implemented Kikuchi-San's draft as well as the
    proposal that will come out of MPEG. I am assuming
    that the MPEG proposal will use this adaptation
    bytes to signal type of content. If so, this will
    make Kikuchi-San's draft a sub-set of what MPEG will
    propose (preferable was the term you used). The only way
    this can happen is if Kikuchi-San's draft can be modified
    NOW.
2.  If Kikuchi-San's draft can be modified, it does NOT have to
    specify the content of adaptation header payload. MPEG will
    do it. What all it has to say is use the 'adaptation length'
    field to offset where you pick up the ES payload.
3.  In MPEG-2, the byte that follows the adaptation length 
    signals what is in the rest of the adaptation header such
    as PCR, OPCR, splicing etc. Those that cannot process the
    adaptation header just use the adaptation length to offset to
    the next payload start (such as PES header or ES). This
    is what I am assuming MPEG will do for 'generic' mapping. The
    byte after adaptation header may signal presence of DTS,
    SL header, flexmux header, scalable data, buffer etc.
4.  If Kikuchi-San's draft progresses 'as is' and MPEG uses the
    adaptation header, then content authors that used the MPEG
    coding can only play it on receivers that implemented the
    re-assembly of MPEG 'generic' mapping and not on those that
    'ONLY' implemented Kikuchi-San's draft (if it was not modified).
    CE vendors can choose to implement receivers that can support
    multiple payload formats. However, if Kikuchi-San's draft can
    be modified NOW, we may see a single payload format for MPEG-4
    and I believe that is a plus and thus NECESSARY.

Best Regards
Sam Narasimhan 
Motorola

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Wednesday, September 13, 2000 12:52 AM
To: 'Narasimhan, Sam (SD-EX)'; [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call

Sam,

Regards,

z

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

Zvi,

Regards
Sam Narasimhan
Motorola

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Tuesday, September 12, 2000 10:18 AM
To: Narasimhan, Sam (SD-EX); [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call

[Reply:]

Regards,

z

---

From: "Narasimhan, Sam (SD-EX)" <[email-masked]>
Date: Wed, 13 Sep 2000 11:49:06 -0400

I am sorry you see it this way. I do not agree with you; however
I have also run out of words and will save it for the MPEG
work.

Regards
Sam Narasimhan
Motorola

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Wednesday, September 13, 2000 9:33 AM
To: 'Narasimhan, Sam (SD-EX)'; [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call

Sam, what you want either will not work or is not necessary.  I'm sorry we
didn't manage to convince you. I've run out of words...

Regards,

z

-----Original Message-----
From:	Narasimhan, Sam (SD-EX) [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 5:28 PM
To:	'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)';

Zvi,

Best Regards
Sam Narasimhan 
Motorola

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Wednesday, September 13, 2000 12:52 AM
To: 'Narasimhan, Sam (SD-EX)'; [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call

Sam,

Regards,

z

-----Original Message-----
From:	Narasimhan, Sam (SD-EX) [SMTP:[email-masked]]
Sent:	Tuesday, September 12, 2000 6:21 PM
To:	'Zvi Lifshitz'; Narasimhan, Sam (SD-EX);

Zvi,

Regards
Sam Narasimhan
Motorola

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Tuesday, September 12, 2000 10:18 AM
To: Narasimhan, Sam (SD-EX); [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call

[Reply:]

Regards,

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 19:44:59 +0200

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

-----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: [email-masked]
Date: Wed, 13 Sep 2000 18:50:35 +0200

Dear Zvi,

My conclusion is that I failed to let you understand the issue. And you seem
to suggest that you are not the only one. Your suggestion to kill this
discussion ignores the problem addressed. I agree that putting our heads
into the sand is a way to go forward. But in my opinion we should take our
responsibility to define a future proof solution.

Best regards,

Jan

soon there will be more in this world than plain streaming ...

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

Jan,

Your nice proposal can be incorporated in the Generic format. I hope we
managed to explain why it is useless with the ES format.

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 5:28 AM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to
the last call

Colin, all,

Kind regards,

Jan

---

From: [email-masked]
Date: Wed, 13 Sep 2000 18:49:33 +0200

Guido,

Thanks. You made your point very clear but not clear enough for all. Neither
did I. We seem to live in too different worlds to really understand each
other. Sad.

Regards,

Jan

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

Hi all,

In RTP and IETF procedure terms, I understand this thread on the extra byte
as:
1) modify the current ES draft to accomodate a payload header starting with
a byte indicating its length. No specification of what the payload header
carries
2) allow the modified ES draft to enter the RFC standard track and be widely
implemented
3) propose a new draft for 'generic' ES or SL mapping, which is identical to
the modified ES draft but also defines what the payload header carries
4) the 'generic' draft becomes standard and _obsoletes_ the ES draft.
Devices implementing the ES draft will skip the payload header information
but still understand the media content.

Well, I think we have a technical problem here, which has nothing to do with

Now, the 'extra byte' proposal would allow devices implementing the ES draft

carrying, and would rely on the Object Descriptor to do that. If the goal is

Guido

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 20:12:05 +0200

Hi Jan,

I have the same conclusion. Maybe I would have had another conclusion if I 
saw answers to the questions Collin and me and other asked. I'll try to 
summarize it for last time:

1. Applications that know only the ES format will not recognize a future 
format because they will not identify the format name.
2. Therefore having extension mechanism in the ES format without fully 
describing the extensions makes no sense.
3. Defining the extensions in the ES format amounts to replacing it by the 
Generic format. Practically in time-to-market terms, that means suppressing 
the ES format. What is the gain, if the Generic format is going to be a 
superset of the ES format?

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 6:51 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to 
the last call

Dear Zvi,

My conclusion is that I failed to let you understand the issue. And you 
seem

Best regards,

Jan

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 13 Sep 2000 13:16:40 -0400

From this seat at the NAB it seems to me that unless the business models
change and a serious business justification exists, one should not expect
broadcasters (at least the small set of US broadcasters) to change methods
to one that obsolete previous deployments once a method is started. On the
other hand, as this is MPEG4 over IP, and IP will be a clean layer so that a
broadcaster need not worry about the content of the IP, only those
broadcasters that think consumers will complain to the station may care.  If
the problem is only on 'PCs', those users are less likely to complain.  One
could reason that manufacturers of 'TVs' would be unlikely to add support
for M4/IP for similar reasons.  If it doesn't work for broadcasters in the
US, they will find another way to provide the desired functionality.

Disclosure: This view may be biased by my assessment of MPEG-4's timing
capabilities in addition to the issues under discussion. <old dead issue>.
Art
::{)
-----Original Message-----
From: Kris Huber [mailto:[email-masked]]
Sent: Wednesday, September 13, 2000 12: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

<snip>

... Let me clarify, for point-to-point usage there is no efficiency
problem, it is only for the broadcast (multipoint) case. ...

<snip>

Best regards,
Kris

<snip>

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 13 Sep 2000 13:25:10 -0400

Here! here!

Art
::{)
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 13, 2000 12:51 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call

Dear Zvi,

Best regards,

Jan

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

Jan,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 5:28 AM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in
response to
the last call

Colin, all,

Kind regards,

Jan

---

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

Zvi,

Your first assumption is incorrect. The name does not change when including
the adaptation field. But rather than explaining once more by email, I will
try to reach you by phone. A few minutes ago I failed to reach you on both
phone numbers you gave, so I will give it another try by tomorrow, assuming
that you will be in your office by than. If needed, please let me know how I
can reach you otherwise.

Best regards,

Jan

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

Hi Jan,

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 6:51 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to
the last call

Dear Zvi,

Best regards,

Jan

---

From: Zvi Lifshitz <[email-masked]>
Date: Wed, 13 Sep 2000 22:18:43 +0200

Sorry I'm not available for MPEG discussions 24 hours a day ;-) Try 
tomorrow, why not? I'm curious to hear your explanation to your first 
sentence below.. If you manage to make it through my hard head there will 
be a big apologize on the reflector ;-))

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 7:51 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to 
the last call

Zvi,

that you will be in your office by than. If needed, please let me know how 
I
can reach you otherwise.

Best regards,

Jan

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

Hi Jan,

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, September 13, 2000 6:51 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to
the last call

Dear Zvi,

Best regards,

Jan

---

From: Scott Bradner <[email-masked]>
Date: Wed, 13 Sep 2000 20:38:44 -0400 (EDT)

> 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.

I would strongly suggest that this is the better path to take

Scott

---

From: Zvi Lifshitz <[email-masked]>
Date: Thu, 14 Sep 2000 10:48:41 +0200

[[email-masked]:]

specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the 
"generic

[Reply:]

If I understand you right, you seem to suggest what I asked you about few 
emails ago. To define one payload format, with an empty extension, and 
later to define the content of the extension. Same payload format, same 
name. Well, if this is your meaning at least I can understand what you want 
to do technically. Theoretically this can work, as it solves the problem of 
old devices having to recognize new name.

[Over night I thought about another scenario which solves the 
old-device-new-name issue, and planned to ask you (and Sam) if this was 
your scenario. This is when streams are broadcast but session description 
is interactively negotiated point-to-point. Then, assuming a stream is 
broadcast in the "new" format and a client starts negotiation to locate 
this stream, the server asks the client what formats it recognizes. If the 
client says the new format is OK, the server tells it the truth that this 
is in the new format. But if the client says it knows only the "old" 
format, the server bluffs and tells this is the old format].

Still, I don't believe this can work. I think also Colin said that. First, 
I believe this is against the IETF practice. Then, the Generic format 
differs from the ES format in much more than just the extension content. 
The ES format uses LATM. The Generic format is not only for audio/video 
elementary streams. The ES format defines fragmentation rules, which in the 
Generic format are configured by the SLConfig. The evolution that one needs 
to reach the other is Darwinian and might take 2 billion years... The main 
question is, assuming old devices can peacefully skip the extension field, 
how do we guarantee that they correctly handle the content beyond?

And, again, I don't see why we need it. If a stream that is delivered with 
the ES format can be played and synchronized, why would you ever want to 
put something in its adaptation field? What kind of extra SL info do you 
think can enhance it? The only thing I can think of is combining it with 
other streams that require the Generic format, but this is possible without 
touching the stream.

----
at this point I'm getting a phone call from Jan :-)............
---

(20 minutes later).. OK, we clarified between us few more things. At least 
we better understand now the disagreement... I'll send my message is as and 
let Jan continue...

Regards,

z

---

From: [email-masked]
Date: Thu, 14 Sep 2000 11:53:01 +0200

Colin, all,

I am happy to take the challenge. My objective will be to produce a modified
Kikuchi proposal that can be agreed upon as a subset of the generic format.
I will propose explicit wording changes, but first I would like to review
the problems to be solved. I will come back on both in separate emails
today.

Regards,

Jan

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	donderdag, 14 september, 2000 02:27
To:	Jan vanderMeer
Cc:	[email-masked]; [email-masked]
Subject:	Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to
the last call

--> [email-masked] writes:
>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.

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.

Colin

---

From: [email-masked]
Date: Thu, 14 Sep 2000 16:02:20 +0200

Hello Zvi,

I am glad we came to technical understanding. In your email you ask many
questions, some of which I think are answered in the email I sent meanwhile
on Kikuchi-san's proposal as a subset of the generic format. Is that right ?
Perhaps we could continue our discussion within the "generic context".

Kind regards,

Jan

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

[Reply:]

----

Regards,

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Thu, 14 Sep 2000 18:30:17 +0200

Jan,

I would welcome continuing the discussion within the "generic" and, 
moreover, the framework contexts, to make it a superset of the Kikuchi-san 
proposal (which doesn't need a change ;-).

Two suggestions I have in mind right now, on top of the SL configuration 
issues we discussed in Paris:

1. Precede the extra (in-band) header in the Generic format by a byte 
indicating its length. This would enable non-MPEG systems to read it.

2. Allowing LATM as valid stream content in MPEG-4.

Regards,

z

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Thursday, September 14, 2000 4:02 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to 
the last call

Hello Zvi,

I am glad we came to technical understanding. In your email you ask many
questions, some of which I think are answered in the email I sent meanwhile
on Kikuchi-san's proposal as a subset of the generic format. Is that right 
?
Perhaps we could continue our discussion within the "generic context".

Kind regards,

Jan

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

[Reply:]

----

Regards,

z

---

From: [email-masked]
Date: Thu, 14 Sep 2000 17:54:35 +0200

Zvi,

We agree to a large extend, with the one exception that you know very well.

Kind regards, anyhow.

Jan

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

Jan,

Regards,

z

---

From: Kris Huber <[email-masked]>
Date: Thu, 14 Sep 2000 12:43:37 -0600

Colin,

>The existing ES format is intended for devices which do not implement
>MPEG-4 systems. I fail to see why anyone would use it for an application
>which depended on the systems framework, since a number of features of 
>the draft are in direct opposition to the systems framework.
>
>Square peg. Round hole.

Existing ES may become used by systems that implement the system framework
simply to avoid sending duplicate broadcasts to non-updateable devices and
newer devices utilizing systems tools.  I think this is the reason why.
Remember video ES data probably dominates bandwidth consumption which is not
unlimited (yet!?) and therefore we should consider a precious resource.

I'm assuming services worried about not obsoleting nonupgradable devices can
take the  approach of using Kikuchi-san format in their systems-based
services for video ES if they want.  Of course, it is not guaranteed that
nonupgradeable devices won't become obsolete quite soon, especially if the
generic format is rapidly deployed, but since it seems to be an option of
the services provider to avoid it, I am satisfied and have no further
comment other than to wish the generic format definition to continue along
well.

I may attend the pre-meeting Saturday (if I'm not bought off by the airlines
to delay!
$:>).  Actually, I have relatives living at a few hours distance that I hope
to visit, too.  I have full confidence in the superiority of the rest of the
group in this area!

regards,
Kris

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 12:12 PM
To: Young-Kwon LIM
Cc: Herpel Carsten; rem-conf; 4on2andIP-sys
Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response
to the last call 

--> Young-Kwon LIM writes:
>Dear Carsten, and all
New
>I do belive that this scenario is more realistic and more useful than the
>second case.

The existing ES format is intended for devices which do not implement
MPEG-4 systems. I fail to see why anyone would use it for an application
which depended on the systems framework, since a number of features of 
the draft are in direct opposition to the systems framework.

Square peg. Round hole.

Colin

---

From: Zvi Lifshitz <[email-masked]>
Date: Thu, 14 Sep 2000 22:01:23 +0200

[Young-Kwon LIM:]

I'd like to be more clear on this point. The payload type of MPEG-4 ES over 
RTP bitstream and MPEG-4 SL over RTP bitstream can have the same tayload 
type semantically. Right?

[Reply:]

Wrong.
The option that was raised when I talked to Jan was that a server would 
advertise same content twice, once as having the ES format and then as 
having the Generic format. This would probably work but IMO is useless...

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Thu, 14 Sep 2000 22:07:17 +0200

If you want to make the stream consumable to devices knowing only MPEG4-ES, 
use MPEG-4 ES. What value will the MPEG-4 SL give you?

z

-----Original Message-----
From:	Young-Kwon LIM [SMTP:[email-masked]]
Sent:	Thursday, September 14, 2000 6:41 PM
To:	Herpel Carsten; Stephan Wenger
Cc:	[email-masked]; [email-masked]
Subject:	Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to 
the last call

Dear Stephe and all,

> This is how things are done, at least in H.323, all the time.

With additional one byte indicating the length of the payload header at the 
beginning of the payload, bitstream for MPEG-4 SL can be comsumed by the 
device only supporting MPEG-4 ES without any modification. This is one of 
the advantages using this byte.

Sincerely,
Young.