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

From: Stephan Wenger <[email-masked]>
Date: Mon, 11 Sep 2000 20:57:18 +0200

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.

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

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: "Young-Kwon LIM" <[email-masked]>
Date: Fri, 15 Sep 2000 01:40:43 +0900

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.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 14 Sep 2000 13:56:31 -0400

--> Young-Kwon LIM writes:
>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.  

This does not work, since a device supporting the ES format will only
understand LATM audio or video in Combined Configuration/Elementary 
stream mode. If the content sent after the payload header is in a format
other than these, the old receiver will break (even if it can skip the
payload header).

Surely you are not proposing a generic format which can only transport
this particular subset of MPEG4?

Colin