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: Wed, 13 Sep 2000 11:28:26 -0400

Zvi,

1.  I thought all the comments were to make changes to 
    Kikuchi-San's draft NOW - not later. If it just added
    the adaptation length followed by length bytes before
    the ES payload (in the RTP payload), then content
    authors could author content that can play on receivers
    that implemented Kikuchi-San's draft as well as the
    proposal that will come out of MPEG. I am assuming
    that the MPEG proposal will use this adaptation
    bytes to signal type of content. If so, this will
    make Kikuchi-San's draft a sub-set of what MPEG will
    propose (preferable was the term you used). The only way
    this can happen is if Kikuchi-San's draft can be modified
    NOW.
2.  If Kikuchi-San's draft can be modified, it does NOT have to
    specify the content of adaptation header payload. MPEG will
    do it. What all it has to say is use the 'adaptation length'
    field to offset where you pick up the ES payload.
3.  In MPEG-2, the byte that follows the adaptation length 
    signals what is in the rest of the adaptation header such
    as PCR, OPCR, splicing etc. Those that cannot process the
    adaptation header just use the adaptation length to offset to
    the next payload start (such as PES header or ES). This
    is what I am assuming MPEG will do for 'generic' mapping. The
    byte after adaptation header may signal presence of DTS,
    SL header, flexmux header, scalable data, buffer etc.
4.  If Kikuchi-San's draft progresses 'as is' and MPEG uses the
    adaptation header, then content authors that used the MPEG
    coding can only play it on receivers that implemented the
    re-assembly of MPEG 'generic' mapping and not on those that
    'ONLY' implemented Kikuchi-San's draft (if it was not modified).
    CE vendors can choose to implement receivers that can support
    multiple payload formats. However, if Kikuchi-San's draft can
    be modified NOW, we may see a single payload format for MPEG-4
    and I believe that is a plus and thus NECESSARY.

Best Regards
Sam Narasimhan 
Motorola

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Wednesday, September 13, 2000 12:52 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 20:36:35 -0400

>    this can happen is if Kikuchi-San's draft can be modified

The Kikuchi-san draft is needed for inclusion in the H.323 standard, 
under revision in the ITU. This is why we are very short on time for
modifications.

>    field to offset where you pick up the ES payload.

This assumes that the ES payload is either LATM audio or video in the
Combined Configuration/Elementary stream mode. Can you really produce
a generic format which always includes ES data in that format? If not,
you will break the old receivers.

>    and I believe that is a plus and thus NECESSARY.

Colin