This is a post-processing codec: given delta-x/y coordinates and a run length,
the r/g/b components of the 4 surrounding pixels are summed up, and the resulting
15bit value is used as index into a color quantization table to derive the
resulting pixel at the center.
It is only used in 10-20 frames of the Rebel Assault 2 LxxRETRY.SAN files
to slightly blur the outline of the "opening aperture" effect.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The various game engines implement the following blit types, from the decoded
result to the main canvas:
- normal (opaque) blit (c37/c47/c48)
- masked blit (c37/c48)
- interpolated-frame blit (c48)
Here an artificial frame is generated by looking up the pixels
from both buffers and picking a color from the interpolation table
for the artificial frame.
This is only supported in the decoder of "Making Magic".
Implement and hook up these 3 schemes for each of the 3 compresstion types,
and switch codec20 to a call to the opaque blit function.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Making Magic makes use of codec48 flag bit 0, which, when set,
means NOT to swap both buffers on even sequence numbers.
This fixes most of the artifacts in the Making Magic videos.
It's not complete though, bits 1 and 4 still need to be handled.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
- align the incoming widths to 4(c37) / 8(c47/78) pixels. LucasArts
game videos have these aligned.
- since these codecs use their 2/3 buffers for themselves, adjust the
stride to the aligned width, keeping it even, which gets rid of
an unaligned store in c48_4to8() found by the fuzzer with an
odd stride.
- clear the whole diff buffer, not just the area described by w/h.
- adjust the RLE "decoded_size" to the product of the aligned width
and reported height.
These changes are the result of various fuzzer-found issues; all my
test videos still work fine.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Add left/top offsets and clipping to codec20 (raw images),
use it for the copying of codec37/47/48 images to main buffer.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Codec37/47/48 have their own buffers; left/top are applied after
the decoding is done when copying to the main buffer. Don't add left/top
to their width/height when doing checks against the established buffer sizes.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
This implements XPAL the same way the DOS/Windows players do, with an
additional 768-entry table holding the palette left-shifted by 7 bits,
and adding the deltapal values to this.
This results in a perfectly smooth day-to-night transition in the last
30 seconds of the Outlaws RAE.SAN (ending) video, while before there
were visible brightness "pulses" when a new palette was loaded.
It also fixes color banding in the The Dig Intro (sq1.san), in the
scene showing the shuttle launch pad and the night sky.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
the c37 mvtable has only 255 pairs, change index 255 to zero to
avoid reading outside the table boundaries.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
When checking for oversized frames, check not only for the width
and height being larger, but also the area not outgrowing the
allocated buffer.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
When decode_init() is called for ANIM content, zero the dimensions
set in avctx width/height. Only SANM files have image dimensions in
their header, while ANIM do not.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Reimplement opcodes 0xFF and 0xFD the same way the c48 decoder
in the "Mysteries of the Sith" game engine does it:
The source pixel(s) and various pixels from inside the same and above
block of the second to last image rendered to the destination buffer
are used together with the interpolation table to generate a 4x4 pattern,
which is then expanded by doubling each pixel horizontally and vertically
to produce the final 8x8 block.
This fixes visible artifacts in frames 25-50 of the S1L1OCS.SAN
video of Mysteries of the Sith.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
It was initially implemented as 4 4x1 blocks, reimplement it as 4 2x2 blocks.
Fixes a few The Dig videos, esp. black dots on the asteroid in the
intro scene.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Codec48 opcodes F9 and FC take per-subblock indices into the motion vector
table from the source stream, however the table has only 255 entries.
Luckily, index 255 is index 0 of the following table, which means no
motion vector, the same as index 0 of the current table.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Create a separate GetByteContext from the general one, to be able
to limit the size of the FOBJ to the size described in the tag size.
Otherwise each fobj could theoretically use all the remaining data
in the FRME (which also contains audio, subtitles, ...).
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
some videos have a FTCH at the start of the video, to restore the
last image produced by the previous game file. This leads to
ugly messages like these:
[sanm @ 0x7f18cc001980] [IMGUTILS @ 0x7f18d7ffe8e0] Picture size 0x0 is invalid
[sanm @ 0x7f18cc001980] video_get_buffer: image parameters invalid
[sanm @ 0x7f18cc001980] get_buffer() failed
Fix this by not setting the got_frame_ptr when there is nothing to
restore/fetch. Seen with a lot of RA1 and the RA2 Level 11/12 videos.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Rename the generic motion_vectors to c47_mv, as this vector table
was initially introduced with codec47 which predates bl16 by 1-2 years,
and bl16 is a development of codec47 (with a bit of c48 thrown in).
No functional change.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Both of these encode a quarter-sized keyframe, with missing pixels
interpolated from the immediate neighbours.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Restructe the SANM (or BL16 as LucasArts calls it) decoder to make it
look like the others, as it is basically a development of old_codec47
for rgb565 values.
No functional changes.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
codec47 carries a 4-byte small codebook in its header. Read those
4 bytes into context member instead of awkwardly redirecting the
bytestream pointer every time it needs to be accessed.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The mv check introduced with d5bdb0b705 broke MotS videos:
- their height (300 lines) is 37,5 blocks; unfortunately the videos try to
access up to 1 block more.
Extend the mv check to the aligned_height, which fixes most artifacts.
- don't return an error when an mv is invalid; rather skip the (subblock).
Gets rid of almost all artifacts.
Some artifacts still remain, esp in space scenes where the original
encoder apparently fetched black pixels from outside of the aligned
height. An increase of the buffer size by 8 lines will fix that later.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
- don't draw outside the buffers
- don't wrap around when coordinates go over the edge
this is especially noticeable in the e.g. O1OPEN.ANM, C1C3PO.ANM
RA1 files with planets wrapping around.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
- don't draw outside the buffers
- don't wrap around when coordinates go over the edge
this is especially noticeable in the e.g. O1OPEN.ANM, C1C3PO.ANM
RA1 files with planets wrapping around.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Just add an extra x/y offset parameter pair to process_frame_obj(),
and store the size of the data to FTCH in a separate context member.
The only valid sizes for FTCH are 6 and 12, reject any other.
Finally, if a FOBJ uses codecs37 and above, enforce it to be subversion 2,
to use the simpler STOR/FTCH method.
Fixes BIGSLEEP-440183164/process_ftch.anim
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AFAIK the original decoder uses the frame buffers in very strange ways
our implementation seems to mimic that and that results in the
bitstream input to point into a frame buffer while code then
parses that and potentially reallocates the frame buffer
leaving pointers hanging into dealllocated space
This simply uses a temporary buffer
Fixes: Writing into freed buffers
Fixes: BIGSLEEP-440183164/old_codec21.anim
Fixes: BIGSLEEP-440183164/old_codec4.anim
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It's like cmd 2. Fixes the Rebel Assault 1 Intro Video "C1BLOCK.ANM"
crossfade from planet view to space view and subsequent wrong colors.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The DOS/Windows decoder precomputes a table of linear offsets of
all motion vectors given the current image width.
For larger widths (>=762), the pairs starting at indices 1 and 254
of motion_vectors[] will overflow the int16_t, changing the sign.
Playing back the 800x600 "jonesopn_8.snm" video of "Indiana Jones and
the Infernal Machine" reveals a lot of artifacts and a lot of
"Ignoring invalid motion vector (149, -41)->(136, 0), block size = 8"
messages, hinting at the wrong direction of the motion vectors.
Fix this by doing the calculation that the DOS/Windows players do,
let the value overflow and reextract the "new" mvec x/y components.
The setup code fow w,h,left,top is complex, the code using it also falls in
at least 2 different classes, one using left/top the other not.
To ensure no out of array access happens we add this clear check.
Fixes: out of array access
Fixes: 439261995/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5383455572819968
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 436943287/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5011037029203968
This issue did oddly enough, not replicate
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5466731806261248
Fixes: out of array access
Reviewed-by: Manuel Lauss <manuel.lauss@gmail.com>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: writing over the end of the array
Fixes: BIGSLEEP-434637586/payload
Regression since: b22ce90d42
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 410609432/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-4935159201988608
Fixes: out of array access
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
codec31/32 are similar to codec1/3 (RLE coding) but with two 4-bit pixels
per byte; they are only used in the Sega-CD release of Rebel Assault 1.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Some of the calculated values were wrong and/or assigned
to the wrong pixel of the 4x4 block.
Found during testing with Rebel Assault Sega-CD release.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
it has a bug and its effects aren't that noticeable, esp. with
the smoothing applied to the whole picture by modern video display
engines.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Videos of "StarWars - Making Magic" consist of 640x480 codec3 frames
which establish a background, and a 320x240 codec48 video put on top
at random left/top offsets.
To support this, a new default buffer "fbuf", which holds the final
image to be presented, is added, since codec37/47/48 need their 2/3 buffers
to be private to themselves. The decoded result is then copied to the fbuf,
honoring the left/top offsets if required.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Change the size detection a bit to recognize common video sizes,
as the FOBJ codecs>=37 cannot always be trusted, since they can
be embedded in a larger frame.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
