RLE seek (was Re: [Open-graphics] A really good immediate use for OGD1: PCI bus analyzer)

[Daniel Rozsnyó]

> Which is compression. Another way to say this is that we use 
> RLE-compression between the capture and the on-board storage, rather 
> than between the storage and the output. This is nice memory-wise, but 
> it does complicate seeking to a specific time, since there's no 1:1 
> correspondence between time and bit position anymore.

You can do a hw-accelerated RLE decoder too, or just a block which reads
the compressed stream from DRAM until it finds the desired seek time. I
don't assume you can do it on "wire speed" of DRAM chips (xy GBps), but
still processing the whole 256MB (~ 8B codes) takes at most 32 M
periods. After finding the bit location it states the previous absolute
timestamp and starts dumping the RLE data. The rest is handled by the
client software (fine-seeking inside the first RLE sample + decoding
originally requested data).

If you pan the window it can start decoding from current location, so
forward seek is quick. The backwards seek could use a reverse index,
where the above described decoder will dump the abs. time for each N rle
code. Then the client software finds out in which memory block lies the
wanted data and asks to seek only from it, not the start.

Solved, aint?