Subject: [AVT] Re: doubts on interleaving in multisldraft-02

From: [email-masked]
Date: Wed, 31 Oct 2001 12:10:41 +0100

Dear Austin,

good remarks, I forward them to the reflectors.

1) we say that decoders MUST implement de-interleaving (we have to!)
so the problem is to ease the job of implementers
by providing some signaling about the presence of interleaving ...

my understanding is that once you start to implement a RTP reception stack
that can reorder UDP packets and re-assemble codec frames
you are starting with a software architecture that will have to do
quite some buffer handling ... interleaving is a small thing on top of that...

**
Yes and no ...

in theory indexDeltaLength was designed for
transport of the SL packet sequence number
(in conjonction with IndexLength !=0)

then we invented this +1 rule so that if you are not interleaving
you actually dont *need* indexDeltaLength ...

However I did not want to *forbid it* ... and then
we need it because ISMA does USE it:
they always reserve indexLength =  indexDeltaLength so as to have
always the same "bit mask" for header procesing ...

that is why ...

2)Thanks for spotting a typo in section 4: indexLength = 0 DOES NOT imply indexDeltaLength=0

3) switching interleave "mode" during a stream is probably a bad idea,
I dont know of anybody who would see a point/need for that ...
but it would be possible with the current text.

Should we explicitely forbid it ?

I prefer the IndexLength=0 option, because this means that the decision is at the session level,
and cannot change during the stream.... however Index=0 is required for ISMA
compatibility (Jan Van der Meer's draft)

we could add a MUST NOT sentence ... (advice anybody  ?)

4) buffering/delay is very application dependant,
a good example is ISMA: they enforce a limit.

the original thinking was to not do so in the generic payload format
because we cannot choose a suitable delay:

* for media delivery of a movie on a PC
 tens of seconds of delay would be acceptable
(with street RAM price now below .2 $ /MByte !!!!!!!!!!!!!)

* for other applications short delays (300 ms)  may be
required ....

Regards,

Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
[email-masked]
http://www.mpeg-4.philips.com

Austin Lobo <[email-masked]> on 10/31/2001 06:04:41 AM

To:     Philippe Gentric/LIM/CE/PHILIPS@EMEA1
cc:     Sang-ug Kang <[email-masked]>
Subject:  doubts on interleaving in multisldraft-02
Classification:

Dear Mr. Philippe Gentric,

        Greetings !

        In the draft draft-ietf-avt-mpeg4-multisl-02.txt I have a few doubts regarding interleaving.

 1)     How will the multisl decoder know whether the streams exhibit interleaving ?
         Non zero values of  IndexDeltaLength cannot be considered as it is used for streams
         that may or may not exhibit interleaving (It is optional). Is there any other reasons other than for
        de-interleaving for the encoded streams  to use indexDeltaLength ?

        Sec 3.8
              "  Senders SHALL use non zero values of IndexDeltaLength only for
               streams that MAY exhibit interleaving, so that this CAN be
               interpreted by receivers as an indication that interleaving may be
               present. "

               There are, based on this, two ways for a receiver to implement de-
               interleaving, using either Index or timestamps. This is signaled
              using mime parameters as in the following table, where TSBI and IBI
              stand respectively for Time-Stamp-Based-Interleaving (see section
               3.8.1) and Index-Based-Interleaving (see section 3.8.2).

              ==================================================================
               |                                                       | IndexDeltaLength = 0      | IndexDeltaLength !=  0 |
               ------------------------------------------------------------------
              | IndexLength=0                               |   no interleaving               |          TSBI                  |
               ------------------------------------------------------------------
              | IndexLength!=0                             |   no interleaving,             |   Index=0  |  Index!=0    |
               |                                                      |   SL.packetSeqNum        |-------------------------
               |                                                      |    transport                      |    TSBI      |    IBI            |
              ==================================================================

2)       Can the case as pointed out by above table possible i.e IndexLength = 0 & IndexDeltaLenght !=0 possible ?

    Sec 4.1

        IndexLength:
       The number of bits on which the Index is encoded in the first MSLH.
       The default value is zero and indicates the absence of Index and
       IndexDelta for all MSLHs.

3)    Should the reciever use TSBI or IBI consistenly.  Or when indexLength != 0 & indexDeltaLength != 0 should the reciever switch from
        IBI to TSBI  if index = 0 ?

        Sec 3.8.1
                   Senders MUST use either IndexLength=0 or set all Index values in all
                   packets to zero so that receivers CAN detect this as an indication
                   that de-interleaving SHOULD be performed using time stamps.

4)   Is there any indications to the decoder side  of the maximum delay or size of buffers to use when interleaving is used ?
      Otherwise how will the de-interleaving module know how many SL packets to buffer.

        Sec 4.1
         Profile:
               The meaning of this parameter may be defined by a mode. This is
               meant to be used in order to define sub-configurations of a given
               mode, for example the maximum delay (and therefore the size of
               buffers) induced by the usage of interleaving. Implementations of
               this specification can ignore this parameter.

Have a nice day !

Regards,

Austin
Engineer,
PIC, Samsung Electronics,
S Korea.

Ph: 82-31-200-3756

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt