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 05:27:55 +0200

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

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	dinsdag, 12 september, 2000 23:45
To:	[email-masked]
Cc:	[email-masked]; [email-masked]; 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

--> "Narasimhan, Sam (SD-EX)" writes:
>Colin,
>
> See my comments.
>
>Best Regards
>Sam Narasimhan
>Motorola
>
>-----Original Message-----
>From: Colin Perkins [mailto:[email-masked]]
>Sent: Tuesday, September 12, 2000 12:43 PM
>To: Narasimhan, Sam (SD-EX)
>Cc: Kris Huber; Luthra, Ajay (SD-EX); '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
>
>
>Sam,
>
>--> "Narasimhan, Sam (SD-EX)" writes:
>> In this mode, if the sender wants to reach both the
>>'generic format receiver' and 'mpeg4-es-03.txt receiver',
>>then he has to use the same payload type. If payload format
>>for the generic format differs from mpeg4-es-03.txt draft,
>>then the sender has to use 2 different payload types, which
>>does not seem to be possible in multicast.
>
>Why not?
>
>Sam - If the payload type is different and the payload format
>is different, then the sender has to send 2 different RTP
>packets. This can be avoided if the draft included the
>header fields.

Since they include different information, and since one is not
understandable by clients of the other, this would seem to be
a good thing!

>> If mpeg4-es-03.txt included the header with no processing
>>requirement, then the 'generic format' draft could use the
>>same payload type as this draft. The generic format would
>>define the content of adaptation fields that future receivers
>>that support this will understand. The sender can author
>>content that will play on both the receivers (slightly
>>different from each other) using the same payload type.
>>This is what Jan has been suggesting. This is similar to
>>many 'scalable' modes where same content can play on
>>low end and high end players. Low end players play the base
>>layer and parse over or ignore the enhancement layers while
>>high end players enhance the decoded presentation with the
>>enhancement layers. The adaptation field gives the capability
>>to include such enhancements later without breaking the
>>base layer (at little extra complexity).
>
>How are the enhancements signalled?
>
>Sam - they do not have to be signaled. The receiver which
>understands enhancements will parse the information present
>in the stream. The receiver which does not support enhancement
>will 'parse over' the enhancement information.

Of course they have to be signalled - else how do receivers know
what sort of enhancement is present?

Colin

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Sep 2000 19:37:35 -0400

>Whether or not an SL header is carried is signaled in the adaptation field.

I do not believe that this is possible. The differences between the ES
format and the "generic" format are too great - one assumes the use of
MPEG Systems, one requires that MPEG systems is NOT used (and that LATM
is used instead, in the case of audio). 

Simply adding an extra byte for an extension header will not solve this
fundamental semantic difference. 

Colin