Subject: 2 Adelaide drafts ahead

From: "Paul Christ" <[email-masked]>
Date: Wed, 8 Mar 2000 18:49:09 +0100

Dear all,

preparing the AVT group meeting in Adelaide and
pursuing now our MPEG-4/RTP activities within
the framework of the European IST project SoNG
we would like to draw your attention to

1- the fact that our draft

"RTP Payload Format for MPEG-4 with
Scaleable & Flexible Error Resiliency",
(so-called 'GP' in short)

is under revision.  Listening somewhat to the
"complexity argument against us", we simplified a bit
the existing draft (we dropped the fragmentation
capability).

2- the fact that a new draft

- "RTP payload format for MPEG-4 Visual Advanced Profiles"
is also being produced as a specialization exercise of
our 'GP' towards visual and also as a "critique" of
"draft-jnb-mpeg4av-rtp-00.txt ". Covering mostly the
so-called simple visual profile and omitting a series of
other important video profiles, we have to disagree
with its arguments for a simple payload in general.

Five profiles have been specified
for the natural video content: the simple scalable profile
using tools for layered coding (very much relevant
for rate and congestion control especially in multicast, also
applicable in the H.323 context, see annex B of rec. H.323),
the core profile supporting coding of arbitrary shape
objects (useful for content interactive
multimedia applications), the main profile (adding to the
previous the possibility for interlaced video objects and
for sprites).

(See below the list of corresponding coding options and
parameters).

Regards,

P. Christ.

----------------------------------------------------------

List of profiles and corresponding coding options
and parameters not covered by the HEC mechanism
and that would definitely benefit from
an additional protection at the packetization level:

1- Simple scalable profile supporting
temporal and spatial scalability:

The parameter “ref_select_code” specifies
the prediction references for P and B-VOPs
in the enhancement layers and is important to protect.

2- Core and main visual profiles
allowing  the usage of sprite objects and
of arbitrary shape objects, in addition to scalability:

Sprite decoding operates in two modes: basic and low-latency.
The low latency mode allows to update the sprite or transmit new pieces
of the sprite which can be then used as reference information for
decoding  subsequent S-VOPs, and for construction of subsequent
parts of sprites.  Therefore, it is important to be able to protect
this information by  allowing  repetition of sprite data in consecutive
packets.

The decoding of arbitrary shape VOP requires the dimensions of its
bounding rectangle, its horizontal  and vertical spatial position, as
well as the shape coding type.  This information  is respectively
provided  by the parameters “vop_width”, “vop_height”,
“vop_horizontal_mc_spatial_ref” and “vop_vertical_mc_spatial_ref”,
 “vop_shape_coding_type” in the VOP header.  The parameter
“change_conv_ratio_disable” is also needed to be able to decode
properly the video packet.  The “vop_constant_alpha parameter”
as well as the “vop_constant_alpha_value” (if vop_constant_alpha==1),
scaling factor applied to the decoded VOP before display
need also protection.

When scalability is applied on arbitrary shape objects, extra
parameters  need to be protected. For the shape decoding
these parameters are “load_backward_shape”,
“backward_shape_width”,  “backward_shape_height”,
“backward_shape_horizontal_mc_spatial_ref”,
 “backward_shape_vertical_mc_spatial_ref”, “load_forward_shape”,
“forward_shape_width”, “forward_shape_height”,
 “forward_shape_horizontal_mc_spatial_ref”,
 “forward_shape_vertical_mc_spatial_ref”.

Another important parameter is “background_composition”
which signals the usage of background composition in conjunction
with scalability. A final parameter important to be protected is
“Vop_rounding_type” which sig-nals the rounding mechanism
used in the pixel value interpolation in motion compensation
for P and S(GMC)-VOPs.

---

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Thu, 16 Mar 2000 19:32:12 +0900

Dear Paul and all,

>with its arguments for a simple payload in general.

I read your Internet Drafts, but I cannot understand issues you are
trying to raise.

---  draft-gc-avt-mpeg4visual-00.txt ---

   The decoding of
   arbitrary shape VOP requires the dimensions of its bounding
   rectangle, its horizontal and vertical spatial position, as well as
   the shape coding type.  This information is respectively provided
   by the parameters "vop_width", "vop_height",
   "vop_horizontal_mc_spatial_ref" and "vop_vertical_mc_spatial_ref",
   "vop_shape_coding_type" in the VOP header.  The parameter
   "change_conv_ratio_disable" is also needed to be able to decode
   properly the video packet.  The "vop_constant_alpha parameter" as
   well as the "vop_constant_alpha_value" (if vop_constant_alpha==1),
   scaling factor applied to the decoded VOP before display need also
   protection.

The issue on the protection of the VOP header fields for the arbitrary
shaped objects was discussed one year ago(!) at the MPEG Seoul meeting.
The conclusion was to correct the HEC syntax to support the VOP header
for the arbitrary shape, and the corrected syntax has been adopted in
the
Corrigendum of MPEG-4 Visual(14496-2/DCOR1). All necessary information
in the VOP header for the decoding of the arbitrary shaped objects are
supported by the HEC.

   Depending  on  the  different  visual  profiles,  different  sets  of
   parameters will be present in the header of the VideoObjectPlane().
   In  the  simple  profiles,  essential  VOP  header  parameters  are:
   vop_coding_type,  modulo_time_base,  marker_bit,  vop_time_increment,
   fcodes when the VOP_coding_type is P or B, VOP_reduced_resolution if
   reduced_resolution_vop_enable is equal to 1.

You are correct in the meaning that all these information are supported
by HEC. But  VOP_reduced_resolution is NOT for the Simple Profile but
for the ARTS profile.

   Let us now consider the simple scalable profile supporting temporal
   and spatial scalability. Scalable or layered coding is very
   interesting for rate or congestion control on the Internet,
   especially in multicast. A key parameter in order to be able to
   decode a VOP in an enhancement layer is "ref_select_code" which
   signals the VOP that has been taken as a reference for the
   prediction.

   When scalability is applied on arbitrary shape objects, extra
   parameters need to be protected. For the shape decoding these
   parameters are "load_backward_shape", "backward_shape_width",
   "backward_shape_height", "backward_shape_horizontal_mc_spatial_ref",
   "backward_shape_vertical_mc_spatial_ref", "load_forward_shape",
   "forward_shape_width", "forward_shape_height",
   "forward_shape_horizontal_mc_spatial_ref",
   "forward_shape_vertical_mc_spatial_ref".  Another important
   parameter is "background_composition" which signals the usage of
   background composition in conjunction with scalability.

As you can see in Table G-2 in Annex G, any error resilience
tools(including video packet) are NOT supported for the enhancement
layer of the scalability. This is because the information above are not
supported in the HEC.
Even if the VOP header information above are protected by the RTP or
whatever, how you can used it for the error resilient decoding without
video packet? It is impossible to decode a middle part of a VOP without
video packet if the beginning part of the VOP is lost.

   The solution recommended in draft-jnb-mpeg4av-rtp-01.txt, when using
   the  combined  mode,  consists  in  transporting  this  configuration
   information in separate RTP packets, and in possibly repeating the
   corresponding RTP packets periodically if needed for protection
   purposes.  However, this vital information being restricted to a few
   bytes, to transport it in separate RTP packets leads to unnecessary
   overhead.

The configuration information is NOT restricted to a few bytes. It is
about 30 to 40 bytes for the typical case of the Simple Profile. When
the quantization matrix is transported by setting load_intra_quant_mat
and load_nonintra_quant_mat to 1 in Core, Main and other profiles, this
length will go up to about 200 bytes.

   More efficient transport can be reached by grouping this
   data with elementary stream data inside packets.  The same remark
   applies to the Group_of_VideoObjectPlane() entry point and to its
   corresponding header or configuration information.

It is possible to group the configuration information, GOV and the
subsequent VOP into one RTP packet by the fragmentation rule of the
MPEG-4 Visual RTP payload format. (See section 3.2 of
draft-ietf-avt-rtp-mpeg4-es-00.txt) This fragmentation rule is flexible,
and you can select either grouping or no grouping of the configuration
information or GOV adequately, depends on the bitrate, packet-loss rate,
etc.

   Depending on the visual profiles, different sets of key parameters
   will be present in the header of the VideoObjectPlane(), as
   described above.  Key parameters for the simple scalable, main and
   core profiles are not covered by the error resilience tools defined
   in MPEG-4.

I fully disagree with this as I wrote above.

   Five profiles have been defined for natural video content [3]:

Not only five profiles of MPEG-4 Visual Version 1 you raised, HEC
supports all Video coding tools having video packet for natural video
profiles in both Version 1 and Version 2. As you can see in the video
packet header syntax of Version 2 FDAM(14496-2/FDAM1), NEWPRED(ARTS
Profile), DRC(ARTS Profile), GMC(ACE Profile) are also supported by the
HEC.

I should disagree with the last sentence of bellow in
draft-ietf-avt-mpeg4streams-00.txt:

   A set of error resilience tools has been defined in the MPEG-4 vis-
   ual syntax in order to recover corrupted headers [5]. In particular,
   the VideoObjectPlane data is structured in video packets, the entry
   point being defined by the function video_packet_header(), and
   delimited by resync_markers. Basic configuration parameters can be
   inserted in the packet header.  However, this concerns only
   parameters used in the simple visual profile, many parameters
   essential in the simple scalable, main and core profiles are not
   covered by this mechanism [5].

Best regards,
Yoshihiro

----
        Yoshihiro Kikuchi

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

---

From: "Paul Christ" <[email-masked]>
Date: Thu, 16 Mar 2000 20:13:35 +0100

Dear Yoshihiro, dear all,

---  draft-gc-avt-mpeg4visual-00.txt ---

> shaped objects was discussed one year ago(!) at the MPEG Seoul
meeting.

We have checked the output documents of the MPEG Seoul meeting (March
99), and
could not find any document addressing the above issues.

We have been raising these points since november 98 (IETF in Orlando),
we have raised them on the 4onIP list, many times during the year 1999,
but these points have never been acknowledged.

Yoshihiro, you were yourself, on the 6th of March 99,
writing on the 4onIP list the following mail
arguing in the same direction, and recognizing the
limitations of the HEC mechanism for profiles other than the simple
profile:

----------------------------------------------------------------------------
------

Objet:
         MPEG-4 video over RTP
   la date:
         Sat, 6 Mar 1999 17:38:24 +0900
      De:
         Yoshihiro Kikuchi <[email-masked]>
       A:
         4onIP-sys <[email-masked]>
 Copies à:
         kiku <[email-masked]>

Dear MPEG-4 on IP experts,

I would like to raise an issue which, I think, is not discussed so well
so far.
We are thinking of a transmission of the MPEG-4 VIDEO media using RTP
through the Internet that is not so reliable in some cases (packet loss,

delay, ...). But is the RTP specification for MPEG-4 currently under
discussion enough for the error resilient transmission of MPEG-4 video?

1. Alignment of video bitstream and RTP packet

In MPEG-4 video, the video packet has a role to localize the error.
However, the underling layer (Systems/RTP/IP) should have the mechanism
to split a video bitstream so that one video packet is aligned with one
RTP packet. Is it possible in the Systems specification to do such a
fragmentation?

In the Systems FDIS, the Access Unit is defined as follows:
(I hope I'm reading the latest version of the FDIS)

Access Units (AU)
Elementary stream data is partitioned into access units. The delineation

of an access unit is completely determined by the entity that generates
the elementary stream (e.g., the compression layer). An access unit is
the smallest data entity to which timing information can be attributed
Two access units from the same elementary stream shall never refer to
the same instant in time. Any further partitioning of the data in an
elementary stream is not visible for the purposes of the Systems Decoder

Model. Access units are conveyed by SL-packetized streams and are
received by the decoding buffers. The decoders consume access units with

the necessary side information (e.g., time stamps) from the decoding
buffers.

In the case of Video, "the smallest data entity to which timing
information can be attributed" is a VOP. Am I correct? If so, is there
any way to split an Access Unit to a smaller unit than VOP so that one
video packet is mapped onto one RTP packet?

2. Duplication of video header information

In MPEG-4 video, there is a tool, HEC(Header Extension Code), to
duplicate the VOP header information into the video packet header. This
should work well for the 4-on-RTP case as well if the alignment of the
video packet to the RTP packet, as in 1, is provided. There is no
problem in the case of the Simple visual profile with only a rectangular

VOP or so.

However, at least in the current specification of MPEG-4 Visual, the HEC

does not provide duplication of all VOP header information for all video

coding mode. For example, in the case of arbitrary shape coding mode,
the following information are contained in the VOP header but not in the

HEC information:

  vop_width
  vop_height
  vop_horizontal_mc_spatial_ref
  vop_vertical_mc_spatial_ref
  change_conv_ratio_disable
  vop_shape_coding_type

Therefore, when a VOP header with these informations is corrupted, video

packets in the VOP cannot be decoded.

Is there any mechanism provided for the duplication of the video header?

(in RTP? System?)

In RFC2250, the MPEG-1/2 video specific RTP header is defined. MPEG-1/2
video picture header can be protected by this extended RTP header. Is
there any room to define this kind of specific header by extending
MPEG-4 and/or RTP? Or, are there any other ways for the duplication?

Because I am basically a VIDEO person, I may have some misunderstanding
on the Systems and the 4-on-IP specifications. It is a great help for me

if experts of this area give me advice.

Best regards,
Yoshihiro
----------------------------------------------------------------------------
------

> for the arbitrary shape, and the corrected syntax has
> been adopted in the

We have looked for the 14496-2/DCOR1 corrigendum and finally found this
document as an output document of the MELBOURNE meeting in OCTOBER
1999 (and not as an output from the Seoul meeting in march 99)..
This corrigendum has apparently been prepared at the same time as the
draft-jnb-mpeg4av-rtp-00.txt, and been discussed in October 1999 in the
MPEG4 video group.

There were two ways for correcting these limitations,
either by modifying the
visual syntax, either by proposing to add protection in the
encapsulation process.
You apparently proposed the first solution, while we were and are still
defending the second approach.  The second proposal being
more flexible in the case of pre-encoded streams for
streaming applications.

Given all the discussions that had taken place between
the MPEG-4 and the IETF
on these questions between november 98 and october 99, we would have
expected to post this corrigendum on the 4onIp reflector.
At least, this would have allowed to discuss the pro's
and con's on the two possible ways to solve the problem,
and to find in a consensual way the
best solution.

> video packet if the beginning part of the VOP is lost.

The lack of notion of video packet and the lack of protection of the
essential parameters for the enhancement layers in the
context of scalable  coding is a problem.
This means not being able to use the scalable features in
a context of packet losses (since the enhancement layer is
unlikely to be decodable, in case of losses),  although one
of the interests of scalability is its amenability for
congestion control on IP. It is especially essential for
congestion and rate control when you have pre-encoded streams
(streaming applications) or in multicast scenarios.

So, with respect to this last point, it comes again to
several possible solutions:
One additional corrigendum to the video syntax, for the
enhancement layers, or/and relying on an additional mechanism
in the encapsulation process, which we again support.

> about 30 to 40 bytes for the typical case of the Simple Profile.

30 to 40 bytes are a few bytes, compared to likely MTU sizes.
Experiments made by people from Berkeley on congestion control
assume MTU sizes of 1500 bytes.

Yours

Paul

---

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Fri, 17 Mar 2000 12:29:55 +0900

Dear Paul and all,

>could not find any document addressing the above issues.
Which document did you check?
You can find the revised HEC syntax for the arbitrary shape at item 1 in
the WD1 of the corrigendum(N2693). This syntax has been adopted in the
ISO/IEC 14496-2/DCOR1(N2919). You can find the syntax in item 12 of the
DCOR1.

>limitations of the HEC mechanism for profiles other than the simple

(snip)

Yes, I surely wrote this mail. If I remember correctly, there were
suggestions by Katto-san and Carsten to revised the HEC syntax to
support the shape coding.  I posted a contribution to the MPEG Seoul
meeting regarding this issue(m4480). The issue was discussed at the
meeting, and the conclusion was to revise the HEC syntax as suggested
and adopt it in the Corrigendum of MPEG-4 Visual so that this HEC
functionality can be used for all MPEG-4 Visual compliant codecs and all
kind of networks. So the problem I raised in my very old mail has been
solved. This is what I wrote in my previous mail.

>draft-jnb-mpeg4av-rtp-00.txt, and been discussed in October 1999 in the
No. The corrigendum of 14496-2 was initiated at the March 1999 MPEG
meeting more than half year before Melbourne, and WD1 of the corrigendum
including the revised HEC syntax was published in March as I wrote
above. It has been integrated in the reference software (ISO/IEC
14496-5) before the MPEG July 1999 meeting. It is also before Melbourne.

>expected to post this corrigendum on the 4onIp reflector.

If I was not so kind enough to post the WD of the corrigendum, I'm sorry
for it. But I'm not sure if I, just as one member of MPEG, can post the
official output document from MPEG to the open reflector.

>and to find in a consensual way the
I understand there were discussion on the reflector before March as I
wrote above. And
there is a conclusion.

>(streaming applications) or in multicast scenarios.
My understanding on the packet loss resiliency of the scalable coding is
that the scaleable coding itself has resiliency in the meaning that we
can use base layer for decoding even when enhancement layer is corrupt.
So, the base layer should be protected well. This is why MPEG-4 error
resiliency tools(video packet and others) are supported in the base
layer. But the resiliency required for the enhancement layer is
relatively low.
I remember that there were such discussions in MPEG before defining
Table G-1.

>in the encapsulation process, which we again support.
I have to ask other MPEG-4 video experts, but is this corrigendum really
possible? It requires not only syntax changes, but also changes on the
video decoding process. All video coding operation using prediction from
the surrounding macroblocks, such as motion vector prediction and AC/DC
prediction, will be affected by this.

>assume MTU sizes of 1500 bytes.
Then, you can put the configuration information with a subsequent VOP
(or video packet(s) in the VOP) into a single RTP packet. The
fragmentation rules in section 3.2 of draft-ietf-avt-rtp-mpeg4-es-00 are
designed to be able to do so.
I hope you read carefully the specifications in the I/D.

Best regards,
Yoshihiro

----
        Yoshihiro Kikuchi

---

From: "Paul Christ" <[email-masked]>
Date: Mon, 20 Mar 2000 17:25:38 +0100

Pardon, for the delay in answering your last mail.

Set aside the "who discovered what when",
let's try to look at the essence of the points
that were made and let's try again to anwer
the questions you were asking in your
previous mail about the issues we are trying to address,
since you were writing

> but I cannot understand issues you are

RUS and INRIA are currently involved in projects targeting
applications mixing real-time with streamed content,
in both IP unicast and multicast.
These applications rely therefore, on one hand,
on real-time encoders and on a server streaming
the pre-encoded streams.
These application design are guided by the following
requirements:

1-  It is desired, for the sake of architectural
simplicity, to have a single interface between
the real-time encoder and the transport mechanism
on one hand and between the server pumps
(audio-visual pumps) and the transport mechanism
on the other hand.

2- "transport mechanism" is  used here to encompass
network adaptation.  In particular, the target is to
have this transport mechanism to support:

* congestion control,
i.e. estimate available bandwith,
the corresponding rate values being passed and exploited
in the real-time encoder and/or in the streaming mechanism
(e.g. in this later case select different layers if we
have layered streams).

* FEC
one simple example of FEC being the duplication of
the vital header parameters.  For example, at the
beginning of the session, the network conditions
are good, so there is no need to
incorporate any redundant data in the stream.
Suddenly the transmission conditions deteriorates,
and we need to incorporate protection for the headers
(for example).
One could say
"use the HEC mechanism for that, as far as the video
is concerned....". This is feasible for our real-time
encoder (at least for the simple profile,
and now with the corrigendum also in the case
we have arbitrary shape objects, we will come back to
the scalable aspects later in the mail....),
but what are the implications for our server?.
If at the instant t0+ 10 seconds, we want to
use the HEC mechanism for the streamed content,
instead of a very simple pump, the server has to support a
module that would parse the stream, i.e. analyse the
syntax (starting from the vol header, inorder to know whether
for example video_object_layer_shape != “rectangular”, etc...
in order to incorporate the corresponding protection bits
(see piece of syntax copied below)

---- piece of syntax
 video_packet_header() {
  next_resync_marker()
  resync_marker
  if (video_object_layer_shape != “rectangular”) {
   header_extension_code
   if (header_extension_code && !(sprite_enable && vop_coding_type ==
“I”)) {
    vop_width
    marker_bit
    vop_height
    marker_bit
    vop_horizontal_mc_spatial_ref
    marker_bit
    vop_vertical_mc_spatial_ref
    marker_bit  1
   }
  }
  macroblock_number
  if (video_object_layer_shape != “binary only”)
   quant_scale
  if (video_object_layer_shape == “rectangular”)
   header_extension_code
  if (header_extension_code) {
   do {
    modulo_time_base
   } while (modulo_time_base != ‘0’)
   marker_bit
   vop_time_increment
   marker_bit
   vop_coding_type  2  uimsbf
   if (video_object_layer_shape != “rectangular”) {
    change_conv_ratio_disable
    if (vop_coding_type != “I”)
     vop_shape_coding_type
   }
   if (video_object_layer_shape != “binary only”) {
    intra_dc_vlc_thr
    if (vop_coding_type != “I”)
     vop_fcode_forward
    if (vop_coding_type == “B”)
     vop_fcode_backward
   }
  }
 }
-----------

I guess, we would rather avoid to have to incorporate
and develop parsers of the different types of streams
in our server (if we assume, that a parser is almost
half an encoder - and counting the numbers of encoders -
this possibly is  an argument  concerning
the succes of of MPEG-4)

We prefer to have a unique and simple interface between
the real-time encoder and the "network adaptation layer"
on one hand and the server and the network
adaptation layer on the other hand, thru which
we would pass

- a pointer to a buffer containing the segment
of bits to be sent to the network (it could be
for example for the visual streams, a VOL header,
a GOV header, a VOP header, a video packet, etc...)

- the length in bytes of the corresponding buffer
(or segment contained in the buffer)

- possibly the padding bits in the last byte
of the segment (if needed)

- the "degradation priority" or equivalently
the type (VOL header, GOV header, VOP header, video
packet, for the visual streams) of data contained
in the buffer (a degradation priority could be set for
the different types of data according to their importance).

This information of "degradation priority"  can then
be exploited for
*  deciding to repeat possibly the information in the
consecutive packet(s),
* possibly marking in the sense of diffserv marking
(you may, for example, look at
Hou Y.Th. et al. "A
differentiated services architecture for multimedia
streaming in next geration internet", Computer Networks,
Vol 32 Number 2, February 2000).
Some recent I-Dwere talking about colour markers to
mark segments of streams on the sender side
(e.g. mark I frame with a high priority, P frames
with a lower priority and B frames still with a lower
priority)

The abstraction of the core of the QoS monitoring
intelligence of the application into the so-called
"network adaptation layer" allows a joint
'supervision or control' of the qos of the different
streams (real-time and/or pre-encoded)
used in our application and which have to
share the same resources
(network, CPUs,...)

So to come back to the 2 I-Ds,
draft-gc-avt-mpeg4visual-00.txt
is simply an application of
draft-ietf-avt-mpeg4streams-00.txt
to the special case of visual streams,
in order to target applications
with the requirements described above.

>> essential parameters for the enhancement
>> layers in the  context of scalable  coding
>> is a problem.
>> This means not being able to use the scalable
>> features in a context of packet losses
>> (since the enhancement layer is
>> unlikely to be decodable, in case of losses),
>> although one of the interests of scalability
>> is its amenability for congestion control on IP.
>> It is especially essential for

> My understanding on the packet loss resiliency of the
> scalable coding is that the scaleable coding itself
> has resiliency in the meaning that we

>> enhancement layers, or/and relying on an additional
>> mechanism in the encapsulation process,
>> which we again support.

> the surrounding macroblocks,
> such as motion vector prediction and AC/DC

It is not up to us to say if formally the corresponding
corrigendum would still be possible in MPEG.
However, without the notion of independently decodable
segments (says video packet) in the enhancement layers,
we fail to see how scalability in MPEG-4
(and this concerns the simple scalable, but also
the core and the main visual profiles, since the
two latter profiles support
among other things  scalable modes, right?)
can be really used in loss-prone
or error-prone  environments,  therefore also in t
he H.323 context (see recommendation H.323 annex B).
It seems that as soon as there will be a 'non-recoverable'
loss, the enhancement layers will have to be thrown away.

As far as our implementation is concerned,
enhancement layers of the layered streams
(we are working in collaboration with an
industrial partner implementing the FGS WD for the
streamed content) are  passed via the same interface
to the network adaptation layer and treated accordingly
by the network adaptation layer with a lesser priority
than the base layer, but in an 'harmonized' way
with the other streams.

> I hope you read carefully the specifications in the I/D.
We certainly appreciate  this concern,
but if we may reassure you, yes we did :-).
However, since we failed to understand how the I/D
can be used to address the requirements that we target
in our application (as described above, and which is not
a fancy one, these requirements have been also, since
the beginning, in the core of the MPEG-4 activities,
and have motivated the powerful scene description
framework, right?),
we would certainly be grateful,
if you can enlighten us on this.

Best regards,

Paul -  Christine - Stefan

--------------------------
Christine Guillemot -  IRISA
Paul Christ, Stefan Wesner - RUS