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

[Timothy Miller]

On 1/3/07, Daniel Rozsnyó <daniel at rozsnyo.com> wrote:
> > 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.

I think we need totally random access.  But like I say, we have so
much memory that storing it uncompressed in RAM is not a big deal.

Even if we DID want to store it compressed, we can compress in blocks
and have a table of contents that tells us which block to look in for
a given time range.

-- 
Timothy Miller
http://www.cse.ohio-state.edu/~millerti