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

From: Herpel Carsten <[email-masked]>
Date: Mon, 11 Sep 2000 18:39:15 +0200

Dear all, 

Jan:
>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 ?

Colin:
>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?

What happens here is a clash of worlds.
The two of you have different pre-conditions for their proposals, if I am
not mistaken.

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.

On the other hand is the assumption that when a new payload format gets
defined, all the existing devices will just be reprogrammed to read the new
format. And possibly the assumption that the changes in payload format will
be bigger than what can be captured by the proposal of just adding a single
field to be skipped. 

Is the first assumption so completely wrong that we can afford to go the
second way that is apparently being advocated by a majority of the speakers
in this thread?

Regards,
Carsten

---

From: "Young-Kwon LIM" <[email-masked]>
Date: Fri, 15 Sep 2000 01:29:27 +0900

Dear Carsten, and all

> compatible to any new format.

I do belive that this scenario is more realistic and more useful than the second case.

Sincerely,
Young.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 14 Sep 2000 14:11:54 -0400

>I do belive that this scenario is more realistic and more useful than the

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