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'm facing a problem to decompress a object that was compressed by C# code using lz4-net.
I've tried all possibilities using many libraries and no one was able to decompress.
In my research I found that this .net library stores a header of 8 bytes. In this header they store the compression level, compressed length and original length of the object.
I was debuging the C# code and in their decompress implementation they are really handling this first bytes as headers.
The point is that I almost sure that in my example was needed only 4 bytes to store the header nedded, but my guess is that depends on the data size they will use more bytes to store the header, then I think that can be 3 to 8 bytes and the code needs to be smart to find this boundaries.
This Library was supposed to handle this type os compressing natively?
Am I doing something wrong?
The text was updated successfully, but these errors were encountered:
Hi ,
I'm facing a problem to decompress a object that was compressed by C# code using lz4-net.
I've tried all possibilities using many libraries and no one was able to decompress.
In my research I found that this .net library stores a header of 8 bytes. In this header they store the compression level, compressed length and original length of the object.
https://code.google.com/archive/p/lz4-net/
In object example I only was able to ready discarding some initial part of the byte[].
safeDecompressor.decompress(byteaero, 5, byteaero2.length - 5, restored, 0);
I was debuging the C# code and in their decompress implementation they are really handling this first bytes as headers.
The point is that I almost sure that in my example was needed only 4 bytes to store the header nedded, but my guess is that depends on the data size they will use more bytes to store the header, then I think that can be 3 to 8 bytes and the code needs to be smart to find this boundaries.
This Library was supposed to handle this type os compressing natively?
Am I doing something wrong?
The text was updated successfully, but these errors were encountered: