Subject: [AVT] Re: MPEG-4 RTP (was IndexLength/IndexDeltaLength and packetSequenceNumberLength in SLConfigDescriptor)

From: [email-masked]
Date: Tue, 28 Aug 2001 19:39:39 +0200

Dear Dorairaj,

thanks for your perspicacity !

(I copy this to the AVT list)

yes, I agree that  (a) is the correct solution.

First note that we have at least one other roll-over issue in the payload format:
time stamps are another example, for example the SLConfigDescriptor
could state that timestamp resolution is 12 bits: RTP does not care ...
its 32 bits in all cases, so a receiver will see time stamps roll over
before 2^32-1....

but let us come back to your remark:

Indeed IndexLength and SLConfigDescriptor.packetSeqNumLength
may differ ... (for example you may prefer to have IndexLength a
multiple of 8 bits or fixed to some other value for byte alignement
purpose as in Jan van der meer's mode (used by ISMA)..)

I conceed that  (IndexLength < SLConfigDescriptor.packetSeqNumLength)
would be bad, (although depending on the actual difference
a receiver could still figure out the sequence, which is the most
important thing ...unless you care about being able to reconstruct
the *exact* SL stream at the receiver side rather than a simply
*a* valid SL stream ...).

Maybe the memo should describe this problem ?

In all other cases (IndexLength > SLConfigDescriptor.packetSeqNumLength)
I dont think there is actually a problem becuase
the receiver has access to both numbers (IndexLength AND SLConfigDescriptor.packetSeqNumLength)
one as a mime parameter, the other one is either available in the "SLConfigDescriptor"
mime parameter or in the Object Descriptor (that for example
you would get through an OD stream)

Again maybe the memo should describe this issue ?
Or is this implementation details ?

Finally note that IndexDeltaLength is a completely different issue:
it DOES NOT have to be related to SLConfigDescriptor.packetSeqNumLength
at all, the only requirement is that it has enough bits to encode
the *relative* values inside a packet, which normally never gets
nowhere close to be as large as the abosolute value,
(the worst cases being for interleave schemes with large delays
on streams with small SL packets (relative to MTU)...)

==> if you dont use interleaving
 IndexDeltaLength SHOULD actually be 0
since IndexDelta would be zero all the time anyway ... !

Should the memo document that better too ?

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

"Dorairaj V" <[email-masked]> on 28-08-2001 13:26:56

To:     <[email-masked]>
        Philippe Gentric/LIM/CE/PHILIPS@EMEA1
cc:
Subject:  Reg IndexLength/IndexDeltaLength and packetSequenceNumberLength in SLConfigDescriptor
Classification:

Hi All /Philippe,

In the latest draft of Multi-sl , Index/IndexDelta are used to encode the packetSequenceNumber of SL packet

1) Can packetSequenceNumberLength in SLConfigDescriptor and IndexLength/IndexDeltaLength be different ?
 2) If they can be different , how does one handle the following scenario ?

Inside the SLConfigDescriptor , packetSeqNumLength = 12 , So SLPacketSequenceNumber will have values ranging from 0-4095 and after that it wraps to 0 .
 .
If IndexLength/IndexDeltaLength is 16 bits  (Range of values = 0 - 2^16 -1), how will the decoder handle the situation  ?

Eg: If a Multi-sl packet carries say 6 SL packets and SLPacketSequence Number starts at 4094 ,
 the absolute value of SLPacketSequenceNumbers will be 4094 , 4095 , 0 , 1 , 2 , 3 (Wrap around occurs since the SLPacketSequenceNumber is only 12 bits in length) .

In a MultiSL packet , the Index/IndexDelta will be  4094 , 0 , 0 , 0 , 0 , 0 (If IndexDelta is 0 , then it SLPacketSequenceNumber automatically increments by 1) .

Now the question is how will the decoder interpret it .

a) If it considers PacketSequenceNumLength = 12 bits while decoding multi-sl packet  , the SLPacketSequenceNumber will be correctly decoded as 4094 , 4095  , 0 (Wrap around occurs) 1 , 2 , 3

b) But if it considers IndexLength/IndexDeltaLength for decoding then the SLPacketSequenceNumber can have a maximum value of 2^16 -1 and the SLPacketSequenceNumber will be 4094 , 4095 , 4096 , 4097 , 4098 , 4099 .

In my opinion , (a) should be  the correct interpretation and IndexLength/IndexDeltaLength are just used to extract the exact number of bits and not used while determining the wrap around condition .

With warm regards
Dorairaj V

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