Re: Run-length encoding (RLE) of stream segments ...

RLE is quite easy to implement in Java.
You might look into a more sophisticated version using controlbytes or
control sequences.
You chose the byte that is the least likely to occur in the data stream
as control byte and encode runs like follows ("#" being the
controlbyte):
#12WB#12W#3B#24WB#14W
instead of: 12W1B12W3B24W1B14W
That approach will waste some bytes for each run, but it will save on
random data, because you'd get:
WBWBWBWBWBWBWB
Instead of: 1W1B1W1B1W1B1W1B1W1B1W1B1W1B
Controlbytes itself can be encoded like: "#1").
An even shorter method is to substitute the controlbytes by using the
first two characters of a run to act as control sequence, so you'd get:
WW10BWW10BB1WW22BWW12
Any time your decoder finds two subsequent characters, it assumes the
next byte is a count for the same characters to follow.

Controls bytes offer more flexibility though, because for 2-byte-runs
you might introduce a second controlbyte for another coding scheme.
Imagine 2-byte runs:
$7WB
Anyway, since it's hard to know the optimum chunk-size, which may be
locally different, you're usually better off with using an LZSS
(Lempel,Ziv,Storer,Szymanski variant of LZ77 with controlbyte)
for anything else but simple runs.
LZSS encodes using references to previous ocurrences, using a
controlbyte:
The whiskymixer mixes whisky in a whiskymixer.
becomes
The whiskymixer $6,4s$18,7 in a$30,12.
where
$6,4
reads: copy from cursor position minus 6, 4 characters.

Any sequence smaller than 3 bytes gets ignored, any controlbyte gets
encoded as $1.

The end of file can be denoted by a zero offset or a zero run length:
#0 or $0 respectively.

Please note that all numbers in the schemes are raw values, no text, and
that the comma I used in the LZSS sequences is just a separator for the
human eye.

So you could imagine a hybrid approach using different controlbytes (or
"escapes", as they are also called) for different encodings:
#=RLE (run length, byte)
$=RLE2 (run length, 2 bytes)
%=LZSS (displacement, n)
&=LZSS+run (displacement, n, run length)

There have been several compressors which use a hybrid approach and more
sophisticated encoding of the encoding sequence, for example with Elias
Gamma codes, which encode near sequences with less bits than far
sequences.
Be warned that LZSS is not quite the fastest way to compress data, but
it's rather easy to implement and decompression is tivial.
This could be an interesting read on a hybrid approach, there is:
http://www.cs.tut.fi/~albert/Dev/pucrunch/
http://www.cs.tut.fi/~albert/Dev/pucrunch/packing.html
The latter being a link with good explainations to different algorithms.