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 11:58:45 -0400

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:06:54 -0400

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