On 1/3/07, Daniel Rozsnyó <[EMAIL PROTECTED]> 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
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
