Color depths greater than 32 have grayscale bit 0x20 set, but the
decoder incorrectly treats 32 as grayscale and and clears the bit,
leaving the color depth as zero and causing codecs to fail.
Confirmed correct behavior in the ffmpeg code that the decoder was
based off. The decoder was introduced with the Mohawk engine in
2009,so presumably no Mohawk movies had color depth 32.
Fixes videos in the Director game Virtual Cocktail Bar
QuickTimeDecoder has a bug which causes the mediaTime offset to be
ignored when a track begins with an empty edit and is followed by an
edit with a non-zero mediaTime. This causes the KQ6 Mac opening movie
to start several tracks at unintended frames (they're never supposed to
be displayed) and the intended frames at the end of the edit to never
be displayed. (Bug #11085)
QuickTimeDecoder has a workaround for a video in a Spanish version of
Riven, but this workaround breaks valid QuickTime videos such as the
KQ6 Macintosh opening movie. (Bug #11085)
Until the original Riven video bug can be debugged to improve the
workaround, it is now disabled unless an engine enables it.
Workaround added in: b8abe40085
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.
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.
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.
This name change accompanies a slight meaning change; now it means the current time position from the beginning of the video and not from starting the video.
This tries to make our code a bit more compliant with our code formatting
conventions. For future use, this is the command I used:
git ls-files "*.cpp" "*.h" | xargs sed -i -e 's/[ \t]*$//'
