summaryrefslogtreecommitdiff
path: root/xpdf/JArithmeticDecoder.cc
diff options
context:
space:
mode:
Diffstat (limited to 'xpdf/JArithmeticDecoder.cc')
-rw-r--r--xpdf/JArithmeticDecoder.cc18
1 files changed, 16 insertions, 2 deletions
diff --git a/xpdf/JArithmeticDecoder.cc b/xpdf/JArithmeticDecoder.cc
index 56ddc31..92db326 100644
--- a/xpdf/JArithmeticDecoder.cc
+++ b/xpdf/JArithmeticDecoder.cc
@@ -92,10 +92,18 @@ JArithmeticDecoder::JArithmeticDecoder() {
dataLen = 0;
limitStream = gFalse;
nBytesRead = 0;
+ readBuf = -1;
}
inline Guint JArithmeticDecoder::readByte() {
+ Guint x;
+
if (limitStream) {
+ if (readBuf >= 0) {
+ x = (Guint)readBuf;
+ readBuf = -1;
+ return x;
+ }
--dataLen;
if (dataLen < 0) {
return 0xff;
@@ -162,9 +170,15 @@ void JArithmeticDecoder::restart(int dataLenA) {
void JArithmeticDecoder::cleanup() {
if (limitStream) {
+ // This saves one extra byte of data from the end of packet i, to
+ // be used in packet i+1. It's not clear from the JPEG 2000 spec
+ // exactly how this should work, but this kludge does seem to fix
+ // decode of some problematic JPEG 2000 streams. It may actually
+ // be necessary to buffer an arbitrary number of bytes (not just
+ // one byte), but I haven't run into that case yet.
while (dataLen > 0) {
- buf0 = buf1;
- buf1 = readByte();
+ readBuf = -1;
+ readBuf = readByte();
}
}
}