In the Spanish version of Riven, the last edit of the video ogk.mov
ends one frame after the end of the media causing the playback to fail
without this check.
Fixes Trac#10633.
Our decoder currently only supports the standard FLC format which
does not rely on the stored packet count (which is part of the FLI
format and limited to 255 packets per line).
Instead, the image width should be used as criterion when decoding
a frame which allows for more than 255 packets per line.
See also https://www.compuphase.com/flic.htm
When decoding blocks, the YUV planes' pitches were computed using the
target video surface size instead of the block based size, resulting in
decoded plane data being overwritten for some video sizes.
Affected videos are LEOS-11102.bik and LEOS-11152.bik from Myst III.
And fix an out of bounds acces when seeking to the end of a video.
Skipping samples is needed even when seeking through silent edits
because a silent stream is queued for those.
Fixes#10219.
All users of BitStream were in fact using a specific, hardcoded variant,
so we can hardcode that variant, removing the need for virtual calls,
and enabling inlining.
A lot of the standard VideoDecoder methods were still treating the
transparency track as part of the video, so methods like getFrameCount
would return double the amount it should be. This refactoring properly
separates the transparency track into a separate field entirely.
The 16-bit DPCM decompressors in SSCI and Urban Runner use a 16-bit
register to store sample data, without any special handling of
overflow. As such, out-of-range samples simply wrap around, rather
than getting clipped.
It is not totally clear if the wrapping behaviour was intentionally
exploited to handle extreme transients, but in any case, videos
like GK2 5280.VMD that generate samples outside the signed 16-bit
range cause a loud pop when using clipping, but play back correctly
when wrapping.
It turns out that at least one video in Starship Titanic, for the
Lift Indicator, has only a single transparency frame in track 2.
The added code, therefore, when it doesn't find an index entry
for the desired frame number, works backwards until it finds a valid
frame (likely frame 0), and then scans forward. If it hits the end
of the video, then it simply uses whatever last frame it last decoded.
