OSC compression (was: OSC bandwidth)

[Stephen Sinclair]

On Thu, Jul 17, 2008 at 1:28 PM, Andy W. Schmeder
<andy@...> wrote:
> I am well aware that the O(1) overhead of the header can be a rather
> large fraction of the total in practice--but this depends greatly on
> the message, which is why for analysis it should be considered
> separately.  Incidentally, a compression strategy applied to OSC would
> likely approach this part of the protocol first--e.g. by using a
> lookup table of common strings.  Also, because OSC addresses are human-
> readable they are an obvious target for compression due to their low
> information-density (english being only ~1 bit per character).

I've had in mind for a while to try running a stream of OSC messages
over a TCP connection going through a gzip compression-decompression
on either side of the connection to see how well that would work.
However I haven't read up on whether or not gzip is the most
appropriate approach to compression of streams.  Has anyone tried
this?  Are there other compression algorithms better designed for
streaming data?  (In particular I'm imagining problems with an
ever-growing string table.)  I wonder how much CPU overhead it would
incur.  Maybe something extremely simple like run-length encoding
would even improve bandwidth.


Steve
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Adrian Freed]

>On Thu, Jul 17, 2008 at 1:28 PM, Andy W. Schmeder
><andy@...> wrote:
>> I am well aware that the O(1) overhead of the header can be a rather
>> large fraction of the total in practice--but this depends greatly on
>> the message, which is why for analysis it should be considered
>> separately.  Incidentally, a compression strategy applied to OSC would
>> likely approach this part of the protocol first--e.g. by using a
>> lookup table of common strings.  Also, because OSC addresses are human-
>> readable they are an obvious target for compression due to their low
>> information-density (english being only ~1 bit per character).
>
>I've had in mind for a while to try running a stream of OSC messages
>over a TCP connection going through a gzip compression-decompression
>on either side of the connection to see how well that would work.
>However I haven't read up on whether or not gzip is the most
>appropriate approach to compression of streams.  Has anyone tried
>this?  Are there other compression algorithms better designed for
>streaming data?  (In particular I'm imagining problems with an
>ever-growing string table.)  I wonder how much CPU overhead it would
>incur.  Maybe something extremely simple like run-length encoding
>would even improve bandwidth.

It is best to build or share a dynamic data dictionary for the strings and substitute dictionary references for OSC message strings. There maybe some merit to representing streams of 0's efficiently (e.g.RLL) because so many OSC streams contain values that are cast up from short 8-12-bit integers.

The only case for me where these space efficiencies matter is wireless. It is interesting in many of these applications that the carbon footprint and silicon associated with encryption of the data streams far exceeds any packet encoding costs.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev