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

From: "Young-Kwon LIM" <[email-masked]>
Date: Thu, 7 Sep 2000 18:19:41 +0900

Dear Collin and AVT working group members,

Yesterday 20 MPEG experts had an AHG meeting at Paris. We discussed the technical problems and the solutions in terms of basic interoperabilities what we want to achieve form the ongoing work to develop overall framework for carriage of MPEG-4 content over IP. Based on the consensus of the AHG members, we would like to make two comments to possibly ensure the basic interoperabilities between the payload format of this draft and the generic payload foramt under development.

1.  We suggest to have a room for future extension of RTP header (e.g. one byte of payload header at the beginning of the payload part) to make the devices implementing this draft interoperable with the bitstream based on the generic format under development. For example, it is possible to use the reserved byte to specify the length of the payload header of generic payload format. Then the device implementing this draft can play the bitstream of generic payload format by simply skipping those bytes.

2. We request to clarify the usage of LATM. It was recognized during the meeting that there seems no reason to use multiplexing feature of LATM for the purpose of this draft. In addition, limiting the usage of LATM to carry configuation information and concatenation of audio frames is desirable to make this draft more compatible to the generic payload format under development.

Sincerely,

Young-Kwon LIM
Co-chair
AHG on MPEG-4 content on IP network

---

From: "Jiro Katto" <[email-masked]>
Date: Fri, 8 Sep 2000 11:52:58 +0900

Dear all, 

I appreciate the progress. Just humple comments, 

> 1.  We suggest to have a room for future extension of RTP header (e.g. one byte 
> of payload header at the beginning of the payload part) to make the devices 
> implementing this draft interoperable with the bitstream based on the generic 
> format under development. For example, it is possible to use the reserved byte to 
> specify the length of the payload header of generic payload format. Then the device 
> implementing this draft can play the bitstream of generic payload format by simply 
> skipping those bytes.

This may be good compromise. But, usage of extension byte in the MPEG-4 
payload header, instead of defining another payload header, seems to conclude 
that the "generic" payload format is MPEG-4 "specific." Let me confirm that
"generic" means MPEG-4 generic, not applied to other codecs nor future ones. 

I sometimes felt, in MPEG world, generic issues and MPEG-4 specific issues 
were confused. Generic format and handling of multiple VOPs are examples. 
When expected, they should be expanded (and separated) to general cases, 
similar to the previous RTCP extension case, in my humble opinion.

> 2. We request to clarify the usage of LATM. It was recognized during the meeting 
> that there seems no reason to use multiplexing feature of LATM for the purpose 
> of this draft. In addition, limiting the usage of LATM to carry configuation information 
> and concatenation of audio frames is desirable to make this draft more compatible 
> to the generic payload format under development.

Without LATM, a payload format for MPEG-4 Audio would need most fields 
in the LATM header to be added into it. Acceptance of LATM with restriction 
seems practical compromise.

Best regards, 
--
Jiro Katto
Waseda University

---

From: "Young-Kwon LIM" <[email-masked]>
Date: Fri, 8 Sep 2000 15:20:24 +0900

Dear Jiro,

==> Yes, you are right. The AHG group is working on MPEG-4 over IP.

Sincerely,
Young.

---

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Fri, 8 Sep 2000 17:21:42 +0900

Dear Katto-san, Young-Kwon, all,

> "generic" means MPEG-4 generic, not applied to other codecs nor future
ones.
As clearly described in the introduction, the intention of the MPEG-4
Audio/Visual payload format includes that this payload format will be used
in the existing frameworks (such as H.323) in an ordinary way, and can be
handled in an unified way together with those formats defined for non-MPEG-4
codecs. This, of cource, does not exclude the use in the MPEG's 4-on-IP
framework, but we must be care that any changes will not harm the original
intention.

> ==> Yes, you are right. The AHG group is working on MPEG-4 over IP.

I understand the importance of interoperability, however, isn't it better to
ask IETF experts if the specific proposal of adding a reserved byte in the
RTP header is really a general way also for other frameworks?

I believe this is the intention of the comment.

Kind regards,
Yoshihiro Kikuchi

----
        Yoshihiro Kikuchi

E-mail: [email-masked]
Corporate Research and Development Center
TOSHIBA Corporation
TEL: +81 +44 549 2288    FAX: +81 +44 520 1267

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 08 Sep 2000 12:55:27 +0200

Folks,

>1.  We suggest to have a room for future extension of RTP header (e.g. one 
>byte of payload header at the beginning of the payload part) to make the 
>devices implementing this draft interoperable with the bitstream based on 
>the generic format under development. For example, it is possible to use 
>the reserved byte to specify the length of the payload header of generic 
>payload format. Then the device implementing this draft can play the 
>bitstream of generic payload format by simply skipping those bytes.

I'm not sure whether this is a good idea.  We would waste one byte of
payload (from RTP's point of view) for something which is probably not
used by any systems currently under discussion or development.

Regardless how the generic payload format of the future may look like,
systems can be most easily designed to support both payload types.
RTP's PT mechanism has enough numbering space to support both.
Capability announcement/negotiation will be different and have to
be redesigned anyway for anything more capable then what is
currently in the MPEG-4 ES draft.  Annoucing/Negotiating another
PT for the new generic payload spec will not make a difference.

When, in the future, a generic payload type would be available that
includes a super set of functionality of the MPEG-4 ES payload format,
then we could declare the MPEG-4 ES RFC as obsolete, thereby
advising people to move over to the new, generic payload type.

Or, it may also be possible to have two payload specs coexisting,
one for simple audio/video ES packetization only, the other containing
more (the rest of?) functionality of MPEG-4.  This does not sound
like a bad idea to me, because the necessary demands of functionality
both from the network (in terms of QoS) and implementation efforts
(single audio/visual ESs vs. system layer, flexmux, whatever...) are
very different.

Please let the header format as is -- no more changes, otherwise you
can almost certainly forget the deadline you want to meet (mid
November's SG16 meeting).

Stephan

---

From: "Jiro Katto" <[email-masked]>
Date: Fri, 8 Sep 2000 20:35:34 +0900

Dear Kikuchi-san and all, 

> > payload header, instead of defining another payload header, seems to
> > conclude that the "generic" payload format is MPEG-4 "specific." Let me 
> > confirm that "generic" means MPEG-4 generic, not applied to other codecs 
> > nor future ones.
> 

I just wanted to know the area that the word "generic" covers. 
I thought it is obscure and, when used, it should be applied to a 
bigger picture. 

I think both of current two formats (ES-specific and SL-specific) 
do not break existing frameworks (e.g, H.323) nor the original SL-
layer concept. This fact should be kept in future. A single format 
or two formats are not my intention.

> I believe this is the intention of the comment.

Yes, that must be. Thank you for your translation.

Best regards,
--
Jiro Katto
Waseda University

---

From: Colin Perkins <[email-masked]>
Date: Fri, 08 Sep 2000 10:04:20 -0400

--> Young-Kwon LIM writes:
>Yesterday 20 MPEG experts had an AHG meeting at Paris. We discussed the
>technical problems and the solutions in terms of basic interoperabilities
>what we want to achieve form the ongoing work to develop overall framework
>for carriage of MPEG-4 content over IP. Based on the consensus of the AHG
>members, we would like to make two comments to possibly ensure the basic
>interoperabilities between the payload format of this draft and the generic
>payload foramt under development.
>

I agree with the comment made by Stephan Wenger. The RTP payload type field
is intended to differentiate formats, and I don't believe that this byte will 
sufficiently aid future interoperability to make its inclusion worthwhile. 

>2. We request to clarify the usage of LATM. It was recognized during the
>meeting that there seems no reason to use multiplexing feature of LATM for
>the purpose of this draft. In addition, limiting the usage of LATM to carry
>configuation information and concatenation of audio frames is desirable to
>make this draft more compatible to the generic payload format under
>development.

There is indeed no need for the multiplexing features of LATM. Is the gain
of designing an alternative header worth it? We may simply specify that
that feature of LATM should not be used?

Colin

---

From: "Toshiyuki Nomura" <[email-masked]>
Date: Sat, 9 Sep 2000 02:44:04 +0900

Dear Colin and Young,

> that feature of LATM should not be used?

I think the content of Comment 1 does not relate to Comment 2.
Anyway, if I get the consensus from MPEG Audio experts,
I'll modify Introduction of the I/D to specify that some features
of LATM should not be used in RTP transmission.

Best Regards,

Toshiyuki Nomura, NEC
---------------------