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

From: [email-masked]
Date: Mon, 11 Sep 2000 13:03:46 +0200

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: Colin Perkins <[email-masked]>
Date: Mon, 11 Sep 2000 11:22:27 -0400

>associated with the payload type would be possible. Would that be a good way

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

Dear Colin, andl all

> different from using the payload type for the same effect?

The length of additional header will be variable. So, the device should know the length to skip the additional headers it doesn't understand.

Sincerely,
Young.

---

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

--> Young-Kwon LIM writes:
>The length of additional header will be variable. So, the device should
>know the length to skip the additional headers it doesn't understand.

But this doesn't help, since the ES draft imposes strict limitations on
the format of the elementary stream following this additional header. If
you try to use it for generic elementary stream transport, you will break
existing receivers.

Colin