[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt
Hello Magnus,
[I address the comments relating to the timestamp report block in this
mail. A previous mail addressed the comments relating to signalling.]
I agree that the timestamp report block potentially uses a large amount
of space, and could benefit from compression. The method you propose
looks promising to me. As in the case of signalling, though, I wonder
if we could not go forward with the present format and consider this for
a subsequent draft.
We proposed the Loss RLE block, for instance, after studying a number of
different compression techniques and concluding that run length
encoding, while not always offering the best ratio, was simple and could
reliably provide 5:1 compression over a fair range, given typical
observed loss patterns.
The current format for timestamps allows timestamps to be reported in a
simple and straightforward way. It does not preclude a future format
that would show better compression characteristics.
Best regards,
Timur
-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
Sent: Thursday, February 20, 2003 11:17 AM
To: Timur Friedman
Cc: avt@ietf.org
Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt
Hi Timur,
I have in the last few weeks come to some insight on where I desire to
use some of the reporting blocks. Therefore I have two general comments
on what I would in fact like to add to the XR format:
...
2. The timestamp report block results in extremely large reports I think
the block would much more useful if it default contains a less bandwidth
using scheme for reporting the timestamps. My proposal is to change the
format to the following.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First RTP timestamp and base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable length encoded diff 1| diff 2 | Diff 3 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
My idea is to take the first packet reception timestamp as is to form a
base. Then for each following packet only the delta timestamp value from
the previous packet is included. To save bytes this values is then
encoded as one, two, three or four octets. This would in most case allow
for reducing this block with 50% or more. At the same time the operation
is not that complex and does not require substantial amount of
processing. to end up on the next 32 bit boundary padding is required.
This padding is easy to find as the number of reports are indicated with
initial and last sequence number of the packets and the thinning factor.
A simple variable length encoding would be:
0-127 1 byte with first bit = 0, i.e. 0xxxxxxx
128-16383 2 bytes in the form 0xxxxxxx1xxxxxxx
16384-2097151 3 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx
2097151-268435455 4 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx1xxxxxxx
As this clock is running at the media clocks used it will have rates
from 1000 up to 90000 in most case. For most packet rates that will mean
that the diff between each packet will fit into a 2 byte value instead
of four, reducing the necessary block size with almost 50 %. I assume
that there are smarter variable encoding. So please propose anything
that works better.
Best Regards
Magnus Westerlund
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt