Subject: Re: In Defense of Interleaved Data Formats

From: Guido Franceschini <[email-masked]>
Date: Thu, 06 Mar 1997 12:36:02 +0100

Dear all,

I am quite new to this list, and have a different background. However I am
very interested in some threads of your discussions, and would like to give
my contributions too.
Well, in this case [In Defense of Interleaved Data Formats] my comment is:
both an application layer multiplex (that is the Interleaver), and a network
layer multiplex have pros and cons. Some of you have proposed arguments in
favour or against one or the other, but what I think is that the combination
of both is the best solution!

What I and others are designing in MPEG4 is a model comprising two multiplex
layers: the FlexMux is actually an interleaver; the TransMux is the
multiplex mechanism provided by the network (e.g. IP sockets, or ATM VCs, or
MPEG2 PIDs ...). This model gives the maximum of flexibility to the
multimedia content author, while complying with all the requirements that
some of you brought up in the e-mails.
For example, if the application requires an equal treatment (Quality of
Service) for all stream components, than a single FlexMux would be used and
carried over a single, say, IP socket. If instead audio and video need
different treatment, two FlexMuxes would be used on 2 separate, say, IP
sockets. We assume to have a method to inform the network about the QoS
required for the individual FlexMux Streams.

Hope this helps
__________________________________________________________________________

Guido Franceschini

Multimedia Applications

CSELT                         Tel.:  + 39 11 2286137
Via G.  Reiss Romoli, 274     Fax :  + 39 11 2286190
10148 Torino - Italy          E-mail :  [email-masked]
__________________________________________________________________________

---

From: Eric Fleischman <[email-masked]>
Date: Thu, 6 Mar 1997 08:36:33 -0800

Your point
		>It is a REQUIREMENT of this type of presentation that
all media suffer
		>network effects exactly in proportion to the way they
are interleaved....
is right on the mark. 

However, your follow-on comment isn't. Because "on demand" content isn't
constructed in "real time", we have been able to give attention to
implementing error mitigation (error discovery, error hiding, error
correction) approaches within our data streams. We could certainly
benefit from your considerable expertise in improving our current
implementation of forward error correction. Might you be interested in
pursuing this issue "off line" with us?