> 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? _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
