|
Well, actually, I would think that these extra bytes are actually
record marking bytes, but not SigComp record marking: they are the
bytes generated by the ZLIB library when you use it for partial
compression, i.e.: call its deflate method with the flush argument set
to Z_SYNC_FLUSH to compress a partial block. This lets your compressor compress successive messages while keeping the compression history of the previous messages, hence making the compression of further messages more efficient. This mode of operation is needed to implement dynamic compression as per RFC 3321 when using ZLIB to compress the data. >From the SigComp standpoint, these ZLIB record marking bytes can then safely be suppressed from the compressed data as the decompression bytecode does not need them... Herve.
|
_______________________________________________ Rohc mailing list Rohc at ietf.org https://www1.ietf.org/mailman/listinfo/rohc