Refer to RFC 9725 4.2,
"Once a session is set up, consent freshness as per
[RFC7675] SHALL be used to detect non-graceful
disconnection by full ICE implementations and DTLS
teardown for session termination by either side"
Refer to RFC 7675,
send STUN Binding request every 5s,
expire consent after 30s without response,
terminate session when the consent expired.
TODO:
Random consent check interval (4-6s) will be
added later.
Co-authored-by: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Signed-off-by: Jack Lau <jacklau1222@qq.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>
Use __MINGW_{PRINTF,SCANF}_FORMAT which matches the format check for
implementation that is actually used.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This commit deduplicates the wrappers around the fpel functions
for copying whole blocks (i.e. height equaling width). It does
this in a manner which avoids having push/pop function arguments
when the calling convention forces one to pass them on the stack
(as in 32bit systems).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is not based on the MMXEXT one, because the latter is quite
suboptimal: Motion vector types mc01 and mc03 (vertical motion vectors
with remainder of one quarter or three quarter) use different neighboring
lines for interpolation: mc01 uses two lines above and two lines below,
mc03 one line above and three lines below. The MMXEXT code uses
a common macro for all of them and therefore reads six lines
before it processes them (even reading lines which are not used
at all), leading to severe register pressure.
Another difference to the old code is that the positive and negative
parts of the sum to calculate are accumulated separately and
the subtraction is performed with unsigned saturation, so
that one can avoid biasing the sum.
The fact that the mc01 and mc03 filter coefficients are mirrors
of each other has been exploited to reduce mc01 to mc03.
But of course the most important different difference between
this code and the MMXEXT one is that XMM registers allow to
process eight words at a time, ideal for 8x8 subblocks,
whereas the MMXEXT code processes them in 4x8 or 4x16 blocks.
Benchmarks:
avg_cavs_qpel_pixels_tab[0][4]_c: 917.0 ( 1.00x)
avg_cavs_qpel_pixels_tab[0][4]_mmxext: 222.0 ( 4.13x)
avg_cavs_qpel_pixels_tab[0][4]_sse2: 89.0 (10.31x)
avg_cavs_qpel_pixels_tab[0][12]_c: 885.7 ( 1.00x)
avg_cavs_qpel_pixels_tab[0][12]_mmxext: 223.2 ( 3.97x)
avg_cavs_qpel_pixels_tab[0][12]_sse2: 88.5 (10.01x)
avg_cavs_qpel_pixels_tab[1][4]_c: 222.4 ( 1.00x)
avg_cavs_qpel_pixels_tab[1][4]_mmxext: 57.2 ( 3.89x)
avg_cavs_qpel_pixels_tab[1][4]_sse2: 23.3 ( 9.55x)
avg_cavs_qpel_pixels_tab[1][12]_c: 216.0 ( 1.00x)
avg_cavs_qpel_pixels_tab[1][12]_mmxext: 57.4 ( 3.76x)
avg_cavs_qpel_pixels_tab[1][12]_sse2: 22.6 ( 9.56x)
put_cavs_qpel_pixels_tab[0][4]_c: 750.9 ( 1.00x)
put_cavs_qpel_pixels_tab[0][4]_mmxext: 210.4 ( 3.57x)
put_cavs_qpel_pixels_tab[0][4]_sse2: 84.2 ( 8.92x)
put_cavs_qpel_pixels_tab[0][12]_c: 731.6 ( 1.00x)
put_cavs_qpel_pixels_tab[0][12]_mmxext: 210.7 ( 3.47x)
put_cavs_qpel_pixels_tab[0][12]_sse2: 84.1 ( 8.70x)
put_cavs_qpel_pixels_tab[1][4]_c: 191.7 ( 1.00x)
put_cavs_qpel_pixels_tab[1][4]_mmxext: 53.8 ( 3.56x)
put_cavs_qpel_pixels_tab[1][4]_sse2: 24.5 ( 7.83x)
put_cavs_qpel_pixels_tab[1][12]_c: 179.1 ( 1.00x)
put_cavs_qpel_pixels_tab[1][12]_mmxext: 53.9 ( 3.32x)
put_cavs_qpel_pixels_tab[1][12]_sse2: 24.0 ( 7.47x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Basically a direct port of the MMXEXT one. The main difference
is of course that one can process eight pixels (unpacked to words)
at a time, leading to speedups.
avg_cavs_qpel_pixels_tab[0][2]_c: 700.1 ( 1.00x)
avg_cavs_qpel_pixels_tab[0][2]_mmxext: 158.1 ( 4.43x)
avg_cavs_qpel_pixels_tab[0][2]_sse2: 86.0 ( 8.14x)
avg_cavs_qpel_pixels_tab[1][2]_c: 171.9 ( 1.00x)
avg_cavs_qpel_pixels_tab[1][2]_mmxext: 39.4 ( 4.36x)
avg_cavs_qpel_pixels_tab[1][2]_sse2: 21.7 ( 7.92x)
put_cavs_qpel_pixels_tab[0][2]_c: 525.7 ( 1.00x)
put_cavs_qpel_pixels_tab[0][2]_mmxext: 148.5 ( 3.54x)
put_cavs_qpel_pixels_tab[0][2]_sse2: 75.2 ( 6.99x)
put_cavs_qpel_pixels_tab[1][2]_c: 129.5 ( 1.00x)
put_cavs_qpel_pixels_tab[1][2]_mmxext: 36.7 ( 3.53x)
put_cavs_qpel_pixels_tab[1][2]_sse2: 19.0 ( 6.81x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The prediction involves terms of the form
(-1 * s0 - 2 * s1 + 96 * s2 + 42 * s3 - 7 * s4 + 64) >> 7,
where the s values are in the range of 0..255.
The sum can have values in the range -2550..35190, which
does not fit into a signed 16bit integer. The code uses
an arithmetic right shift, which does not yield the correct
result for values >= 2^15; such values should be clipped
to 255, yet are clipped to 0 instead.
Fix this by shifting the values by 4096, so that the range
is positive, use a logical right shift and subtract 32.
bunny.mp4 from the FATE suite can be used to reproduce the problem.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The implementation hardcodes access to 3 channels, so we need to check that
Fixes: out of array access
Fixes: BIGSLEEP-445394503-crash.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without rounding them up there are too few dc coeffs for the blocks.
We do not know if this way of handling odd dimensions is correct, as we have
no such DWA sample.
thus we ask the user for a sample if she encounters such a file
Fixes: out of array access
Fixes: BIGSLEEP-445392027-crash.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
