I have some comments regarding the list compression, examplified
with
CSRC-list compression.
Problems arise when the CSRC list often changes. I'll show an example
below:
Current ref. list is
obj_1
obj_2
obj_3
List at compression point:
Time=0 Time=1
Time=2 Time=3
Time=4
obj_1 obj_1
obj_1 obj_2
obj_1
obj_2 obj_2
obj_4 obj_4
obj_2
obj_3 obj_3
obj_3
obj_4 obj_2
x: no changes, #:position
Then we have to send the following:
Time=0 Time=1
Time=2 Time=3
x add obj_4
rem #2 rem #1
add obj_4,#2 rem #3
add obj_2,#end add obj_4,#end
assume that list at Time=2 becomes the new reference list, then
what to
send at:
Time=4
rem #2
rem #3
Problem!
As you can see there will be tough to have a good reference point
when
having the whole list as reference.
This will work in R-mode, but may have bad performance.
In UO-mode, it is impossible to have robustness if the list is
not constant in several consecutive packets. (One list cannot be repeated).
****************************************************************
It may be better to have a object identifier for the CSRC,
meaning, the
32 bits of CSRC is replaced by a 4 bit identifier PiT, Position
in Table.
Taking the above example again, but with this approach.
PiT_1 = The object(CSRC) stored in the table at position 1.
PiT_1+obj = The object, which will be stored in the table at position
1.
As before obj_1,obj_2 and obj_3 is known both by the compressor
and decompressor.
Current ref. list is
PiT_1 -- obj_1
PiT_2 -- obj_2
PiT_3 -- obj_3
Then we have to send the following
Time=0 Time=1
Time=2 Time=3
x add
PiT_4+obj_4 PiT_1
PiT_2
add PiT_4+obj_4 add PiT_4+obj_4
PiT_3
PiT_2
assume that list at Time=2 becomes the new reference list, then
what to
send at:
Time=4
PiT_1
PiT_2
***********************************
How does the compressor deside if it can use the PiT only and not
the object:
R-mode: PiT+obj is sent until packet with obj is acked, after that
only the PiT is sent.
UO-mode: PiT+obj repeated in x packets, then only PiT is sent.
Also if the list do not change often:
R-mode: PiT list sent until PiT-list packet acked. If PiT-list
still unchanged, skip PiT-list
UO-mode: PiT-list only sent in x packets if unchanged, then PiT-list
is skipped.
Arguments for this approach:
* The session member will probably not change often, but the contributers
to RTP-packets will. With this approach less bits has to be sent when the
list changes.
BR
/Hans H