Multiple zstd frames support? about zstd-jni HOT 10 CLOSED

Hi,

Thanks for the interest. You are right it does not handle this case yet. I will take a look to add it with the next release (0.8) that's coming soon. There is also a re-work in progress of the Zstd streaming API (https://github.com/Cyan4973/zstd/issues/271) that will significantly simplify these bindings.

from zstd-jni.

Ah, yes. I am watching zstd the main repo too. Waiting for the new streaming api.

from zstd-jni.

@advancedxy , I just pushed the zstream branch that is based on the new streaming API and is also updated to zstd-1.0.0. I have added support for decoding multiple frames. You can try it.

My intention is to release it this week after figuring out the interaction of the multi-frame support and the ability to decode files that are not yet finished.

from zstd-jni.

Hi @luben, thanks for your info.

After check your implementation, there are some questions in my mind:

1. https://github.com/luben/zstd-jni/blob/zstream/src/main/java/com/github/luben/zstd/ZstdInputStream.java#L78
   toRead can be 1 if the output is not fully flushed according to the api documentation. This case is not handled?
2. https://github.com/luben/zstd-jni/blob/zstream/src/main/java/com/github/luben/zstd/ZstdInputStream.java#L28
   srcPos looks never being used, is it necessary to declare the variable?
3. what about skippable frame? can toRead be larger than recommendedDInSize() in skippable frame, and results an IndexOutOfBoundsException in https://github.com/luben/zstd-jni/blob/zstream/src/main/java/com/github/luben/zstd/ZstdInputStream.java#L78

from zstd-jni.

@advancedxy , thank for looking up.

1. I tried to read from upstream only when toRead > 1 but it does not function properly. I don't know why. Will investigate and write a test for the worst case (reading 1 byte at a time) to see if we handle it correctly. On another hand I just added an initial implementation of available() that will return 1 if there is a data in the output buffer.
2. Good catch. I am filling the input buffer only with the requested amount so there is no risk for not being
   able to consume it all.
3. Good question. I will ask Yann about it with bunch of other question I am gathering:
   • could the amount of available data in the output buffer be exposed so that the available() method can return in. Also what's expected as next invocation of decompressStream when the previous one returned 1.
   • could he implement a "skip" operation that will be like decompressStream but without copying it in the destination buffer.

from zstd-jni.

Hi, @luben look at the decompressStream code https://github.com/facebook/zstd/blob/master/lib/decompress/zstd_decompress.c#L1553 (It's still in flush stage if not fully flushed), I believe another decompressStream call should be made(and maybe multiple calls). Of cause, you should always consult Yann for that.

Hopes that can fix the case 1.

As for 3rd question, please make the conversion public(Issues?) or cc me if you are going to communicate by email, thanks very much.

from zstd-jni.

Yes, sure... actually I made a progress on 1 but I am not satisfied. I will CC you on the conversion.

from zstd-jni.

@advancedxy : 4a61bbe fixes some of the discussed issues but is quite ugly - let's hope we will find a better solution.

from zstd-jni.

@advancedxy , just released the 1.0.0 based on the Yann's suggestions. I believe it handles all discussed cases as well as decompressing multiple frames.

from zstd-jni.

supported and tested in v1.0.0

from zstd-jni.