Open jrevels opened 4 years ago
My current thinking here is the level to implement seekability on frames rather than blocks.
Through a combination of ZSTD_findDecompressedSize
and ZSTD_getFrameContentSize
we can get the total decompressed size and the decompressed size of individual frames, if saved such as via our ZstdFrameCompressor
.
To seek, we iterate through frames. For each frame
ZSTD_isSkippableFrame
ZSTD_getFrameContentSize
ZSTD_findFrameCompressedSize
To better support random access, especially remotely, we could encode a directory into a skippable frame at the beginning or end of the stream.
ref https://github.com/facebook/zstd/issues/395#issuecomment-492741194 ref https://discourse.julialang.org/t/ann-onda-jl-a-format-for-multi-sensor-multi-channel-lpcm-encodable-recordings/32650/3
I'm not sure if the upstream
zstd
's seek support is considered stable enough to support here, or what the most desirable interface would be from a TranscodingStreams perspective, but it would definitely useful if this feature was useable with CodecZstd.Even if the upstream seekable format is still considered experimental, it may still be worthwhile to support here; the referenced thread makes it seem like more downstream usage of the experimental API would motivate further development/codification of the seekable format.