You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that in #66, @unsightlygod implemented iterative decompression using the mz_zip_reader_extract_iter functions. Would it make sense or even be possible to add mz_zip_reader_extract_iter_seek to this, to seek within a file? Or would this not make sense in terms of compression?
Additionally, I noticed there is this unimplemented API, which looks to be pretty similar to the "iter" interface, which would be nice to have implemented.
You can build seeking based on the existing mechanism...
To seek forward an amount of bytes, read that amount, but discard the data.
To seek backward, start iteration from the beginning, and seek forward.
Especially the latter is, of course, terribly inefficient.
However, if it's possible to "clone" the iterator (I didn't try), this could be used to somewhat lessen the overhead of seeking backwards: the idea would be to "clone" the iterator at some points (maybe an interesting point in the file if you know the structure, maybe something like "every N megabytes"), and then "seek forward" again from one of these clones (ie the closest one before the desired position).
I wonder if it might make sense to allow passing pVbuf=0 to the mz_zip_reader_extract_iter_read() function.
It would then be able to act as a forward seek.
I noticed that in #66, @unsightlygod implemented iterative decompression using the
mz_zip_reader_extract_iter
functions. Would it make sense or even be possible to addmz_zip_reader_extract_iter_seek
to this, to seek within a file? Or would this not make sense in terms of compression?Additionally, I noticed there is this unimplemented API, which looks to be pretty similar to the "iter" interface, which would be nice to have implemented.
The text was updated successfully, but these errors were encountered: