Subject: RE: Updated I/D for MPEG-4 Audio/Visual RTP payload format

From: De Petris Gianluca <[email-masked]>
Date: Wed, 28 Jun 2000 11:09:01 +0200

Leonid,
we are carrying MPEG-4 over MPEG-2 TS according to AMD7 (I can give you more
details, if you are interested).
Then either we send the MPEG-2 TS over a satellite channel (actually we are
just simulating this through a commercial DVB modulator with output in IF)
or we send the same MPEG-2 TS over UDP/IP in unicast. However, as you say, I
cannot see how this question is related with this thread of discussion.
Regards,
Gianluca De Petris ===============================================
e-mail: [email-masked]       tel.:   + 39 011 228 6109
WWW:    http://www.cselt.it/ufv/depetris fax :   + 39 011 228 6299
Services and Applications  -  Multimedia Technologies and Services
CSELT - Centro Studi E Laboratori Telecomunicazioni
Via G. Reiss Romoli, 274   -   10148 TORINO (Italy)

> ----------
> From: 	Leonid Rosenboim[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	mercoledì 28 giugno 2000 11.05
> To: 	Y. Matsui
> Cc: 	Christine Guillemot; Stephan Wenger; [email-masked];
> [email-masked]; [email-masked]
> Subject: 	Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format
> 
> Just a quick (potentially unrelated) question:
> 
> Are you aware of anyone actually using the apparently normative MPEG-4
> transport
> which maps MPEG-4 ES on top of MPEG-2 TS wich in turn is carried over
> UDP/IP ?
> 
> 
> "Y. Matsui" wrote:
> 
> > Dear Christine,
> >
> > I would like to comment on your first question.
> >
> > >1-  I understood from earlier e-mail/MPEG4-IETF phone
> > >meeting discussions that to be MPEG-4 compliant,
> > >terminals would have to support the sync layer, because
> > >the ESI is not normative.
> >
> > MPEG-4 system is not mandatory if the underlying
> > transmux provides the functionality such as synchronization,
> > multiplexing, identification, etc.,   RTP and underlying UDP/IP
> > layer provides them.
> >
> > Another example is ISO/IEC 13818-1 AMD 7, MPEG-4
> > on MPEG-2 Systems.  It has been standardized based on the
> > same concept.  This amendment allows to map MPEG-4
> > AV streams directory into MPEG-2 TS or PS packets in
> > normative way.
> >
> > >Therefore, what would be the status of
> > >the current draft with respect to MPEG-4 compliance
> > >issues, since it says:
> > >
> > >"These RTP payload formats enable to carry MPEG-4
> > >Audio/Visual streams without using the synchronization
> > >and stream management functionality of MPEG-4 Systems
> > >[6]. Such RTP payload format would be used within systems
> > >where their own stream management functionality is provided
> > >and thus such functionality in MPEG-4 Systems is not necessary.
> > >H.323 terminals are an example of such systems. MPEG-4
> > >Audio/Visual streams are not managed by
> > >MPEG-4 Systems Object Descriptors  but by H.245. The streams
> > >are directly mapped onto RTP packets without using the
> > >synchronization functionality of MPEG-4 Systems."
> >
> > Best regards,
> > Yoshinori Matsui
> > Matsushita / Panasonic
>

---

From: Christine Guillemot <[email-masked]>
Date: Wed, 28 Jun 2000 11:29:06 +0200

Dear Gianluca,

> details, if you are interested).

Sorry, I have not followed the discussions on MPEG-4 over MPEG-2 TS
closely.Could you tell me if for the transport over MPEG-2 TS,
the usage of MPEG-4 SL + MPEG-4 Flexmux is requested or whether, if
I understood Yoshinori's mail correctly, one can map
MPEG-4 ES directly into MPEG-2 TS.

Yoshinori wrote:

> This amendment allows to map MPEG-4 AV streams directory into MPEG-2 TS or PS
> packets in normative way."

Thank you,
Christine

---

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Wed, 28 Jun 2000 23:25:04 +0900

Dear Chiristine, Matsui-san, Gianluca, all,

> > > > AV streams directory into MPEG-2 TS or PS packets in

I think what Matsui-san trying to menthion here is to raise other examples
than RTP that do not mandate MPEG-4 Systems Sync Layer or Flex Mux. I can
add other such examples: 3G-324M(H.324), etc.

I believe this is also the case for the transport over RTP.

> > > > multiplexing, identification, etc.,   RTP and underlying UDP/IP

This is very correct. MPEG-4 Audio/Visual elementary streams can be mapped
directly on RTP packets without any knowledge of MPEG-4 Systems. Attributes
of the stream such as packetization format, media type and profile@level can
be signaled by H.245 in H.323, and MIME and SDP in systems such as SIP and
RTSP.

Best regards,
Yoshihiro

----- Original Message -----
From: Christine Guillemot <[email-masked]>
To: De Petris Gianluca <[email-masked]>
Cc: Y. Matsui <[email-masked]>; <[email-masked]>; Stephan Wenger
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, June 28, 2000 6:29 PM
Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format

---

From: Toshiro Kawahara <[email-masked]>
Date: Thu, 29 Jun 2000 13:21:53 +0900

Kikuchi-san and all,

I have an comment on the MIME parameters for MPEG-4 visual, or a
request to add another important parameter to them.

That is decoderConfiguraitonInformation, which indicates the 
configuration of the transmitted bitstream (i.e., VO/VOL headers). 
H.245 have this field for the use of MPEG-4 Visual, and thus
considering interworking with systems using H.245 as H.323 or H.324,
this field should also be supported by SIP with MIME parameters.

Regards,
Toshiro
---
   Toshiro Kawahara  <[email-masked]>
   NTT DoCoMo, Inc.
      (We have changed our corporate name from April!)
   Multimedia Laboratories, Multimedia Signal Processing Laboratory
   TEL: +81 468 40 3518  FAX: +81 468 40 3788
   河原 敏朗 (in Japanese)

---

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Thu, 29 Jun 2000 18:21:55 +0900

Dear Kawahara-san and all,

Thank you very much for your comment.

I agree with Kawahara-san that the interworking between the systems is the
matter to be covered in this Internet-Draft. Does the following minor
revision on section 5 meet your request?

- In section 5.1 "MIME type registration for MPEG-4 Visual", add the
following parameter to "Optional parameters":

config: A hexadecimal representation of an octet string that expresses the
MPEG-4 Visual configuration information, as defined in subclause 6.2.1 Start
codes of ISO/IEC14496-2[2][4][9]. The configuration information is mapped
onto the octet string in an MSB-first basis. The first bit of the
configuration information SHALL be located at the MSB of the first octet.
The
configuration information indicated by this parameter SHALL be the same as
the configuration information in the corresponding MPEG-4 Visual stream,
except for first_half_vbv_occupancy and latter_half_vbv_occupancy which may
vary in the repeated configuration information inside an MPEG-4 Visual
stream (See 6.2.1 Start codes of ISO/IEC14496-2).

- In section 5.2 "SDP usage of MPEG-4 Visual", replace the description for
"a=fmtp" parameter with the following:

o The optional parameter "profile-level-id" and "config" MAY go
in the "a=fmtp" line to indicate the coder capability and configuration.
These parameters are expressed as a MIME media type string, in the form of
as a semicolon separated list of parameter=value pairs.

Best regards,
Yoshihiro

----- Original Message -----
From: Toshiro Kawahara <[email-masked]>
To: Yoshihiro Kikuchi <[email-masked]>; Christine Guillemot
<[email-masked]>
Cc: 4on2andIP-sys <[email-masked]>; IETF AVT
<[email-masked]>; Yoshihiro Kikuchi <[email-masked]>
Sent: Thursday, June 29, 2000 1:21 PM
Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format