DefineBitsJpeg2 fails when JPEG data is truncated

[torokati44]

https://z0r.de/259 (SWF) does not display anything because the jpeg-decoder dependency fails to decode any of the 6 embedded JPEG images.

The actual error message is: Error running definition tag: DefineBitsJpeg2, got failed to fill whole buffer

After extracting the binary data of these tags into separate files, every image viewer/loader I tried opens them:

• convert of ImageMagick outputs a warning: convert: Premature end of JPEG file 'image1.jpg' @ warning/jpeg.c/JPEGWarningHandler/389., but converts the image nevertheless
• Gwenview shows the same result as Flash Player, and what convert exports
• VS Code shows the (incomplete) bottom row of blocks as blank (transparent)

Of course Adobe Flash Player is also willing to decode these images just fine.

There is a report for this already in the repo of the jpeg-decoder crate, but it's closed without a proper fix: https://github.com/image-rs/jpeg-decoder/pull/98

[Herschel]

Not sure if we should ping jpeg-decoder again and see if it's within the scope of their project; or else we should track down another JPEG decoder.

On web, we could try to decode using the browser natively via image element, as this would be the most most performant. Ruffle used to do this a while ago for at least certain JPEG tags, but it switched to be consistent with desktop for simplicity at some point.

[torokati44]

I also had an idea that maybe if we padded the data we pass in to jpeg-decoder with some (arbitrary) number of (I guess) zeroes, it could maybe work in some cases? I know this is hacky and ugly and potentially less performant... Also, since I don't know by heart how the JPEG container format works, this might also just introduce new, invalid "sections" to each file, so the decoder would always fail?

Anyways, I might first ask the original reporter of the issue linked about whether they found a fix or a workaround since.

[Diatonator]

I don't see any developments in that jpeg-decoder library for fixing the problem and the loop https://z0r.de/259 isn't working still. Is anything planned here?

[torokati44]

As written above, I thought about maybe padding the buffer with "some number" of zeros - but this requires copying it out somewhere, so it's not ideal. Or we could catch that error, and only do the copy+pad when it occurs.

The third alternative, where an "array accessor" is used, which simply returns zeros for any overflowing index, may not be technically feasible (anyone knows if it is?).