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

From: "Narasimhan, Sam (SD-EX)" <[email-masked]>
Date: Tue, 12 Sep 2000 17:38:41 -0400

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.

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

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Sep 2000 17:42:18 -0400

>packets. This can be avoided if the draft included the

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

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

Dear Colin,

> understandable by clients of the other, this would seem to be

I do belive this is a good thing and we have very efficient and nice solution which make this happen easily. Low-end devices having limited capabilities will understand only the partial information of the bitstream but high-end, powerful devices will understand all the informations and perform better than the low-end one.

> what sort of enhancement is present?

For the receivers understanding enhancements, configuration information understandable by the MPEG-4 System entity will be sent additionally. I think this is the same thing when you say "signalled".

Sincerely,
Young.