[SDDL] Decoder Testing

[Tabaie]

Decoders (be it SDDL or programmatic) can be non-trivial and pair with encoders written in other languages. Errors are hard to catch since a faulty decoder will not crash the compressor, rather silently produce worse results.

Is there an existing or planned testing framework for decoders? Perhaps a minimal interface along the lines of zli decode spec.sddl -i input-stream.bin -o output-segments.json with the user responsible for inspecting and validating the output. This is CI friendly, one can commit to the desired output and have git check that it hasn't changed after the zli call.

[Cyan4973]

The wording of this question doesn’t match how I understand the system.

SDDL is only relevant on the compression side—it does not exist on the decompression side. Its purpose is to help libopenzl choose the appropriate operations for the data being compressed. However, what gets recorded in the frame is just the resulting list of decisions; there is no remaining SDDL “spec” after compression. As a result, decompression does not depend on SDDL.

You shouldn’t need any SDDL specification to decompress your data. Just decompress.

[Tabaie]

I'm talking about the need for "unit" testing of the SDDL spec independently, not the decompression process. My interest is in developing or identifying a framework that verifies the integrity and correctness of the SDDL specifications used during compression/training, perhaps similar to how one might validate code through unit tests. The goal is to ensure the specifications perform as expected before they are used in the compression process, not during decompression.

[Victor-C-Zhang]

@Tabaie take a look at the visualizer and see if this fits your needs. You can run a sample compression and inspect the resulting graph. The results include a "preview" of each stream that SDDL creates if you mouse over the stream info.