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 12:19:05 -0400

Colin,

 If the objective of receivers that implement this draft is to
only do one thing and process only one payload type, then there
is no change required. Those that are in the CE business want
to build receivers that can be fielded in many application
areas and will build receivers that will understand different
payload types and formats they are carried in. However, content
providers will not want to generate 2 separate streams (with 2
payload types) in order to reach 2 different receivers (one that
implemented Kikuchi-San's proposal and one that implemented
what Jan is proposing). They will probably use the more generic
format and reach those receivers that process these adaptation
headers.

 For Example, in US digital cable the receivers span a 5 year
deployment window and content providers create a single content 
that is decodable by ALL these different models. 

Best Regards
Sam Narasimhan

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Tuesday, September 12, 2000 9:07 AM
To: Narasimhan, Sam (SD-EX)
Cc: [email-masked]'; [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,

There is no process problem, except that delaying the Kikuchi-san draft
will prevent MPEG-4 ES being used with H.323 systems. 

My main issue is technical: I think that the addition of this extra field
is a mistake, and that the correct approach is to use the payload type to
indicate that the media data transported is in a different format. I have
yet to hear a convincing argument otherwise.

Colin

--> "Narasimhan, Sam (SD-EX)" writes:
>Zvi,
>
> Let me see if I can capture what Jan is proposing as a change
>to Kikuchi-San's draft. For the same payload type (MPEG4 Video ES), 
>add an adaptation header length followed by the length bytes before
>MPEG-4 visual stream payload.
>
>
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |V=2|P|X|  CC   |M|     PT      |       sequence number         | RTP
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                           timestamp                           | Header
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |           synchronization source (SSRC) identifier            |
>   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>   |            contributing source (CSRC) identifiers             |
>   |                             ....                              |
>   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>   |adaptation length +--length--+                                 |
>
>   |                                                               |  RTP
>   |                                                               |
>   |                                                               |
>   |       MPEG-4 Visual stream (byte aligned)                     |
Payload
>   |                                                               |
>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                               :...OPTIONAL RTP padding        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>        Figure 1 - An RTP packet for MPEG-4 Visual stream
>
> 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) which included meaningful adaptation
>field data as these receivers will be able to 'parse over' the
>adaptation and get the ES payload. If they cannot 'parse over' 
>such field, then they will crash. Parsing over such data is not 
>very complex and is easy to implement. 
>
> If Kikuchi-San's draft can make this change, then it may become
>fully compatible with what the MPEG AHG may define as 'generic'
>format. It is always easy to define 'hundred's' of payload types;
>however service providers want to reach as many receivers as
>they can and this change will make receivers that implement Kikuchi-San's
>proposal receive properly generated data in the future that may
>include adaptation header.
>
> If this change cannot be made for some process reason's, then we need
>to accept the fact that this draft will not be compatible with what MPEG
>will
>define for a generic format as there is no place to even carry DTS in this
>draft.
> 
>Best Regards
>Sam Narasimhan
>Motorola
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, September 12, 2000 8:15 AM
>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
>
>
>Zvi,
>
>I don't think there is any confusion. If no such bytes are allowed, the
>scenario I gave will not be possible. Which in my view would be a mistake.
>>From MPEG point of view a serious mistake.
>
>To allow for extensibility in the "generic format" will solve problems, but
>not this one
>
>Regards,
>
>Jan
>
>
>-----Original Message-----
>From:	[email-masked] [mailto:[email-masked]]
>Sent:	dinsdag, 12 september, 2000 17:04
>To:	Jan vanderMeer
>Cc:	[email-masked]; [email-masked]
>Subject:	RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in
>response to
>the last call
>
>
>Dear Jan,
>
>I think there is a confusion. The ES format has been proceeded as an
>Internet Draft and there is no more time for comments. I don't think it's
>possible to make this format extendable, because, first, I'm not sure this
>is at all possible in IETF. Even if it is, text on extendibility, both
>syntactically and semantically must be included in the draft, and it is
not.
>So the only thing we can do is proposing that in the Generic format the
>extra SL header that is contained in the payload will be preceded by a
>length byte, so it will be readable by systems that don't use MPEG-4
>Systems.
>
>In any case, the request to have an extra byte in the ES format makes,
>IMNSHO, no sense.
>
>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
>==================================================================

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Sep 2000 12:24:02 -0400

>that is decodable by ALL these different models. 

I see nothing in Jan's proposal which makes this easier. 

Colin