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

From: Kris Huber <[email-masked]>
Date: Wed, 13 Sep 2000 10:30:03 -0600

Hello Zvi, Colin [last comment before letting this discussion transition to
generic format]:

I think some of the discussion has resulted from misunderstanding of the
semantics of the payload type field apparently involving a change (by IETF?)
from static to dynamic binding of an external "payload name" to this field.
In any case, the desire has been to see whether or not this format can
somehow be a subset of the soon-to-be more generic payload format.  Leaving
out lack of LATM in the draft generic format, the answer appears to still be
"no", unless the payload name for the future format is assigned now and a
subset of its semantics, including how to read its adaptation field, are
included in draft-ietf-avt-rtp-mpeg4-es-03.  But this would be
unprecedented, I suspect (possible?  I don't know).  The other option is if
another static payload type is assigned and a future payload type of a
different name (MPEG SL format) uses the same payload type.

Why, some have asked?  To avoid the redundancy that we video compression
engineers hate so much!  How would this redundancy result?  Information
broadcast services begin initially using the Kichuchi-san payload format,
then have to make the decision later on between continuing to use it, and
either doubling their network bandwidth to do the new broadcasting services
or provide services support the new format (since the video ES data will
tend to dominate the bandwidth).  Allowing early-adopter non-upgradeable
devices to cease to function is another possibility, but that also has a
high cost if the number of such devices is large.  You might wonder about an
approach in which a new enhancement payload type is used rather than a
single scalable payload type (e.g., generic format to add the enhancement
information), and perhaps this is considered the "right way".  The only
problem I see with this that the information goes in separate packets and
therefore additional buffer memory and synchronization functionality are
required.  Let me clarify, for point-to-point usage there is no efficiency
problem, it is only for the broadcast (multipoint) case.

It seems that static payload typing, or early assignment of payload name +
"Jan-byte" + other modifications would give the proposed interoperability
functionality.  Out of curiosity let me ask (Colin?), how is "there will be
no more static payload assignments" formally stated, with SHALL NOT or
SHOULD NOT?  Or is it a policy existing outside of an RFC?  How many devices
would be obsoleted by a new static payload type?

Best regards,
Kris

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Wednesday, September 13, 2000 10:33 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, what you want either will not work or is not necessary.  I'm sorry we
didn't manage to convince you. I've run out of words...

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:	Wednesday, September 13, 2000 5:28 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,

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:13:10 -0400

>from static to dynamic binding of an external "payload name" to this field.

The decision to refuse further static payload type assignments was made at
the Munich IETF meeting, in August 1997. 

>different name (MPEG SL format) uses the same payload type.

This is one problem, certainly. The LATM problem is also major, and seems
to be ignored in much of this discussion.

>problem, it is only for the broadcast (multipoint) case.

I would consider the correct solution would be to send the extra information
as an additional stream. I don't believe the overheads are significant.

>would be obsoleted by a new static payload type?

The policy was made in the AVT working group, to prevent exhaustion of the
limited payload type space. 

Colin