Subject: [rohc] LZJH bad end

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Wed, 7 Aug 2002 10:37:49 +0200

Hi,

The LZJH decompressor works fine except one thing: if it comes to the padding bits at the end, it goes on trying to get another ordinal, which results in decompression failure, though the decompression itself was successful. The code as it is written in the UG is only applicabe if there is not any padding bits at the end of the bitstream. I suggest that the INPUT-BITS instruction of the ordinal part should jump to the end_of_message label instead of the fail label. This way it works properly, with the compromise that it will not be able to detect the insufficient number of bits.

Regards,

Zacco

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 7 Aug 2002 11:42:59 +0100

Hi,

The LZJH compressed message is terminated by a special FLUSH
control character that makes sure the decompressor does not
accidentally read the 4 padding bits on the end of the message.
If your implementation tries to read the padding bits then it
might not be running the FLUSH bytecode correctly.

When a FLUSH control character is encountered the decompressor
must discard any bits in the compressed message up to the next
complete byte. The following bytecode implements a FLUSH character
at the decompressor:

:flush

; The FLUSH control character jumps to the beginning of the next 
; complete byte in the compressed message:

INPUT-BYTES (0, 0, 0)
JUMP (standard_prefix)

The FLUSH character is implemented using the UDVM instruction
INPUT-BYTES (0, 0, 0). When this instruction is encountered the
decompressor takes the following action (defined in SigComp-07):

"If the INPUT-BYTES is encountered after an INPUT-BITS or an
INPUT-HUFFMAN instruction has been used, and the dispatcher currently
holds a fraction of a byte, then the fraction MUST be discarded..."

So when decompressing the LZJH compressed message, the FLUSH control
character should cause the 4 padding bits to be discarded. Since
there is no more compressed data after the padding bits, the
decompressor should then successfully terminate.

It may be the case that your own implementation of INPUT-BYTES isn't
discarding the padding bits - fixing this will hopefully allow the
LZJH decompressor to terminate without a decompression failure.

Hope this helps!

Regards,

Richard

> -----Original Message-----
> From: Lajos Zaccomer (ETH) [mailto:[email-masked]]
> Sent: Wednesday, August 07, 2002 9:38 AM
> To: [email-masked]'
> Subject: [rohc] LZJH bad end
>
>
> Hi,
>
> The LZJH decompressor works fine except one thing: if it
> comes to the padding bits at the end, it goes on trying to
> get another ordinal, which results in decompression failure,
> though the decompression itself was successful. The code as
> it is written in the UG is only applicabe if there is not any
> padding bits at the end of the bitstream. I suggest that the
> INPUT-BITS instruction of the ordinal part should jump to the
> end_of_message label instead of the fail label. This way it
> works properly, with the compromise that it will not be able
> to detect the insufficient number of bits.
>
> Regards,
>
> Zacco
>

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Wed, 7 Aug 2002 13:02:43 +0200

Hi,

You revealed a bug for us, thank you! :-)

Regards,

Zacco

-----Original Message-----
From: Price, Richard [mailto:[email-masked]]
Sent: Wednesday, August 07, 2002 12:43 PM
To: 'Lajos Zaccomer (ETH)'; [email-masked]'
Subject: RE: [rohc] LZJH bad end

Hi,

:flush

INPUT-BYTES (0, 0, 0)
JUMP (standard_prefix)

Hope this helps!

Regards,

Richard

---

From: [email-masked]
Date: Wed, 7 Aug 2002 10:21:56 -0700

Zacco

The standard LZJH decompressor is always expecting a FLUSH code at the end 
of a block as a signal that the decompressed data is finished.  Without a 
FLUSH code from the peer compressor the decompressor will not recognize 
end of data.  You can change the decompressor to stop when it has 
processed the last compressed byte based on the compressed data length, 
but in some cases that is not an accurate indication of when it should 
stop decompressing.

regards

Jeff Heath
Chief Scientist
Hughes Network Systems

"Lajos Zaccomer (ETH)" <[email-masked]>
Sent by: [email-masked]
08/07/02 01:37 AM

        To:     "[email-masked]'" <[email-masked]>
        cc: 
        Subject:        [rohc] LZJH bad end

Hi,

The LZJH decompressor works fine except one thing: if it comes to the 
padding bits at the end, it goes on trying to get another ordinal, which 
results in decompression failure, though the decompression itself was 
successful. The code as it is written in the UG is only applicabe if there 
is not any padding bits at the end of the bitstream. I suggest that the 
INPUT-BITS instruction of the ordinal part should jump to the 
end_of_message label instead of the fail label. This way it works 
properly, with the compromise that it will not be able to detect the 
insufficient number of bits.

Regards,

Zacco

---

From: [email-masked]
Date: Wed, 7 Aug 2002 10:28:48 -0700

All

I guess I should have read all my messages before I replied.  Richard is 
correct in his explanation. 

The LZJH algorithm has codes that are as small as 6 bits,  so the FLUSH 
code is the only unambiguous way to determine when the decompressor has to 
stop.

regards
Jeff

"Price, Richard" <[email-masked]>
Sent by: [email-masked]
08/07/02 03:42 AM

        To:     "'Lajos Zaccomer (ETH)'" <[email-masked]>, 
"[email-masked]'" <[email-masked]>
        cc: 
        Subject:        RE: [rohc] LZJH bad end

Hi,

:flush

INPUT-BYTES (0, 0, 0)
JUMP (standard_prefix)

Hope this helps!

Regards,

Richard