The movies for Crusader: No Remorse have a unique decoder which is not too hard
to implement. Unfortunately, they don't properly implement the "compression"
FourCC, and instead put their ID in the "Stream Handler". Since supporting
them requires a change to the existing Image API, I thought I should make a
pull request for comments.
With this change, the movies in Crusader can all be played nicely.
Symbols for codes shorter than the prefix table index width are stored
in the table. All the entries in the table with an index starting with
the code are set to the symbol value. That way, when decoding it is
possible to get the number of bits corresponding to the table width from
the bitstream and directly find the symbol value. Longer code still need
to be searched for in the codes list.
The high-resolution videos play back at much lower volume than the
original ones. This adds hard-coded values for how much to amplify
each cutscene. It's all done by ear, and it does introduce some
clipping, but I think it should be acceptable.
Of course, it could also be a problem with the audio decoder, so
this may be the wrong approach entirely.
In all my attempts to get the audio and video to sync up in the
ZGI videos, there have always been 9-10 frames of video before the
audio even starts, even though the audio is timestamped to start
before. This attempts to fix that by prioritizing sending audio
packets to the decoder in a timely fashion.
I do not know if this is the correct way of doing this, and there
are still some things that need to be fixed. But pragmatically, it
does procude significantly better sync, so...
Sometimes (only at the very start of a movie?) there will be a
video packet that has a PTS but no frame to display. Save that PTS
and use it for the next frame. This doesn't actually improve
anything, as far as I can tell, but feels right.
This is another attempts at improving the audio/video sync in the
MPEG-PS decoder. Unfortunately, the audio probably also needs to
be synced to its pts timestamps...
This code comes from clone2727's now defunct (?) ac3 branch, with
some minor compile fixes. This represents the latest version of
the stalled AC-3 decoder work for Zork: Grand Inquisitor. Note,
however, that I have not yet asked for clone2727's permission to
use this. I'm just experimenting.
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.
This is needed for Starship Titanic, where videos can have a secondary
video track. It was simpler to use the callback as a means to select
one video track each across two decoders than trying to make VideoDecoder
and/or AVIDecoder support decoding from multiple video tracks simultaneously
Starship Titanic in particular needs this, since some of the videos
have extra junk at the end of the file, such as ycursors.avi,
and parsing fails if we don't respect the filesize field
In SSCI, VMD is drawn by a standard CelObjMem wrapped by a
ScreenItem, giving the location of the bitmap memory to the
decoder. The decoder already supports this, but the API was
previously hidden behind the AdvancedVMDDecoder wrapper
(which is more convenient to use than the VMDDecoder class).
We don't support playing videos with multiple edits backwards. Taking the code
path to move to the next edit when playing backwards sets the current edit index
to an invalid value with the video still trying to play. Which results in out of
bounds reads, and ultimately a crash.
This fixes multiple crashes in Myst. Using the key without the chest on
Stoneship, resetting the clock tower puzzle, and using the switch in the trees
in Channelwood.
This was a regression introduced in a59f5db505.
If seeking to the final frame of an edit, _nextFrameStartTime wouldn't be adjust properly and would wrongly say that it's at the end of the edit. This never affected anything because of the edit "-1" hack.
