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

From: Franceschini Guido <[email-masked]>
Date: Wed, 13 Sep 2000 09:22:17 +0200

Hi all,
my own considerations on this thread

In RTP and IETF procedure terms, I understand this thread on the extra byte
as:
1) modify the current ES draft to accomodate a payload header starting with
a byte indicating its length. No specification of what the payload header
carries
2) allow the modified ES draft to enter the RFC standard track and be widely
implemented
3) propose a new draft for 'generic' ES or SL mapping, which is identical to
the modified ES draft but also defines what the payload header carries
4) the 'generic' draft becomes standard and _obsoletes_ the ES draft.
Devices implementing the ES draft will skip the payload header information
but still understand the media content.

Well, I think we have a technical problem here, which has nothing to do with
usual practices / procedures / timelines.
The problem that I see is that:
- the ES draft defines 2 Payload Formats: 1 for Audio, 1 for Video
- the 'generic' draft will define 1 Payload Format only, and the type of
media (Audio, Video, BIFS ...) being carried will be specified using MPEG-4
Object Descriptors.

What we achieved at the Paris meeting (before discussing this extra byte
feature) has been to allow MPEG-4 Systems terminals implementing the
'generic' draft to use the ES draft as well withouth any need to duplicate
implementations (i.e.: the ES draft is a subset of the generic draft in the
Data Plane).
Now, the 'extra byte' proposal would allow devices implementing the ES draft
to be compatible in the Data Plane with the 'generic' format, too.

Compatibility in the Control Plane (i.e. Payload Type
negotiation/announcement) was not considered in Paris.
I believe that devices implementing the 'generic' draft would have no
difficulties in understanding 1 more SDP keyword or MIME type as introduced
by the ES draft.
But the reverse is more difficult and tricky. As I outlined above, the
'generic' draft would not specify by itself the type of media content it is
carrying, and would rely on the Object Descriptor to do that. If the goal is
to allow devices implementing the ES draft to be compatible with future
content delivered by means of the 'generic' draft, than we need to specify
NOW how to duplicate the information in the OD so that the media type is
made explicit for those devices. And then we will have to accept that
devices implementing MPEG-4 Systems get the indication of the media type
twice :-(

Did I make the point clear ?

Guido

> ----------
> From: 	Zvi Lifshitz[SMTP:[email-masked]]
> Sent: 	Wednesday, September 13, 2000 9:51 AM
> To: 	'Narasimhan, Sam (SD-EX)'; [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
> 
> Sam,
> 
> It seems you want the current draft to be modified in the future. Then:
> 
> 1. I don't believe this is possible.
> 2. I don't think this is necessary.
> 
> Regards,
> 
> z
> soon the whole world will STREAM
> ==================================================================
> Zvi Lifshitz				Phone +972(2)679-4788
> [email-masked]			Fax +972(2)679-4789
> Optibase Ltd.				Mobile: +972(53)461-787
> http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
> Send SMS from:
> http://isend.cellcom.co.il/English/Login.htm
> ==================================================================
> > Come see us at:
> Streaming Media Europe Earls Court Centre, Booth # 628, London, October
> 10th-12th, 2000
> 
> 
> -----Original Message-----
> From:	Narasimhan, Sam (SD-EX) [SMTP:[email-masked]]
> Sent:	Tuesday, September 12, 2000 6:21 PM
> To:	'Zvi Lifshitz'; Narasimhan, Sam (SD-EX);
> [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
> 
>  
> Zvi,
> 
>  I am assuming that the payload type from the future draft
> could be set to the same value as this draft, if this
> draft can accommodate the change.
> 
> Regards
> Sam Narasimhan
> Motorola
> 
> -----Original Message-----
> From: Zvi Lifshitz [mailto:[email-masked]]
> Sent: Tuesday, September 12, 2000 10:18 AM
> To: Narasimhan, Sam (SD-EX); [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
> 
> 
> [Narasimhan, Sam (SD-EX):]
> 
> If this draft were to say that receivers should parse over the
> adaptation bytes and not process them (as this draft does not
> define these), then such receivers will be able to process payload
> from future draft (from MPEG)
> 
> [Reply:]
> 
> They will not, because they don't know the payload type of the future
> draft
> therefore they will not know they can process payloads from the future
> draft
> even though they can.
> 
> If they know, they also know that the future draft has extra header info.
> So
> work on the future draft, not on the current draft.
> 
> Regards,
> 
> z
> soon the whole world will STREAM
> ==================================================================
> Zvi Lifshitz				Phone +972(2)679-4788
> [email-masked]			Fax +972(2)679-4789
> Optibase Ltd.				Mobile: +972(53)461-787
> http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
> Send SMS from:
> http://isend.cellcom.co.il/English/Login.htm
> ==================================================================
> > Come see us at:
> Streaming Media Europe Earls Court Centre, Booth # 628, London, October
> 10th-12th, 2000
>

---

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

>devices implementing MPEG-4 Systems get the indication of the media type

And get the necessary changes to H.323 made in time for the next ITU
meeting in November, where the ES format is to be included.

Colin