Subject: Re: Types of MPEG-4 streams over IP

From: "Olivier Avaro" <[email-masked]>
Date: Tue, 3 Oct 2000 12:14:13 +0200

Dear Jan,

> I would like to verify my understanding on the types of MPEG-4 streams
that
> need tools for transport over IP. I summarized my understanding by the
> following list.

Here is the list you can find in V2 :

0x00 Forbidden
0x01 ObjectDescriptorStream (see 8.5)
0x02 ClockReferenceStream (see 10.2.519)
0x03 SceneDescriptionStream (see 9.2.1)
0x04 VisualStream
0x05 AudioStream
0x06 MPEG7Stream
0x07 IPMPStream (see 8.3.2)
0x08 ObjectContentInfoStream (see 8.4.2)
0x09 MPEGJStream

I don't have anything for Flexmux.

cu,

O.

---

From: [email-masked]
Date: Wed, 4 Oct 2000 16:26:02 +0200

Dear Young,

You wrote :

>Can we assume that the following streams are probably most efficiently
>contained in a FlexMux stream, and consequently that is no need to specify
>use of RTP and SDP for those streams:

>- ObjectDescriptorStream
>- ClockReferenceStream
>- SceneDescriptionStream
>- MPEG-7Stream
>- IPMPStream
>- ObjectContentInfoStream
>- MPEGJStream

In general we are not allowed to assume this condition because there is no
normative limitation to this even though practically it is valid. Do you
want to put a normative usage of FlexMux for those cases?  And I think IPMP
streams should not be multiplexed with other streams.

I am asking just for getting opinions; I am not sure how practical it is to
have a separate session for each of the above streams. You may be right that
IPMP streams should not be multiplexed with other streams, but for that case
FlexMux could offer a useful multiplex solution for multiple IPMP messages
within an RTP payload.

Kind regards,

Jan

---

From: "Narasimhan, Sam (SD-EX)" <[email-masked]>
Date: Wed, 04 Oct 2000 13:28:24 -0400

Dave,

 The MPEG requirements document asks for a payload
mapping scheme to carry flexmux streams. This is possible in
MPEG-2 transport and must be possible in RTP. We need to
define a mapping scheme which will be normative for those
applications that want to transmit flexmux streams over
RTP. I will strongly object to a mapping scheme that 
excludes or precludes the carriage of flexmux streams
over RTP.

Regards
Sam Narasimhan
Motorola

-----Original Message-----
From: Dave Singer [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 9:17 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: Types of MPEG-4 streams over IP

>- ObjectContentInfoStream

I would be strongly opposed to mandating the use of flexmux for any 
stream.  What is wrong with Carsten et al.'s sync layer mapping into 
RTP?
-- 
David Singer
Apple Computer/QuickTime

---

From: [email-masked]
Date: Thu, 5 Oct 2000 14:56:57 +0200

Dave, all,

Dave wrote :

>I am not opposed to allowing the use of flexmux.  The proposal was
>that certain stream types (e.g. MPEG-7) could *only* be carried in
>flexmux.

I was not that strong, but only asked whether there is a need for direct
carriage over RTP, given that there is a solution to carry such streams
inside a FlexMux.

But anyhow, I think the answer is clear, though I still don't understand how
to reduce the huge overhead in case of the (usually) small messages if not
by using FlexMux.

Regards,

Jan

---

From: [email-masked]
Date: Thu, 5 Oct 2000 17:45:55 +0200

Dave,

You wrote :

>What is wrong with Carsten et al.'s sync layer mapping into RTP

Good question, as usual. Let me list a few issues :

1) Substantial overhead for small access units; a solution is being
discussed for audio, but not yet for the other streams I listed; some may
indeed deserve a more reliable transport method, but an RTP solution will be
required too, I think. Perhaps use of FlexMux the only solution here.
2) Inclusion of a plain SL header with associated fields; I would prefer to
start with a byte indicating the length of the subsequent field that
contains the SL header. Such field is easily decodable by non-MPEG-4 system
receivers, provides a future proof solution (in future more information may
be contained in the SL header with a length that is unknown by now), and
creates room for fully compatible extensions.
3) Little commonality with the Kikuchi-san drafts for audio and video.
Perhaps it is possible to merge both solutions by extending the Kikuchi-san
drafts with the option to carry an SL header (preceded by the above length
field), for example signaled by a new attribute "MPEG-4 SL header carried"
at SDP level.

Kind regards,

Jan