FF7 upside-down movie problem - found fix

[Myria kitty]

I figured out the application compatibility fix that Windows did to fix the upside-down movies.  This may help make a more permanent fix.  I don't know why the fix works, but I do know what it does.

The fix involves a codec DLL named tm20dec.ax.  Within it are two video fourcc's that Windows changes to be four dashes.  I'm not sure what the significance of four dashes is, however.

My tm20dec.ax has SHA-1 hash 06F37EEDB992E04F2D46C254079C1E439BF70B43.  Windows XP's AcLayers.dll patches these two fourcc's in memory with four dashes:

.text:1D0417C6 68 55 59 56 59                          push    'YVYU'

.text:1D04187D 68 59 55 59 32                          push    '2YUY'


I don't know what the significance of these values are, other than that they're associated with the TrueMotion codec.  Interestingly, AcLayers.dll does not patch other instances of those strings within the DLL.  Changing those four bytes above to dashes in memory is enough to make the videos play correctly.

This sounds like a bug in either tm20dec.ax or FF7's movie mastering process.  Either tm20dec.ax itself is broken, or FF7's movies are mastered incorrectly such that a bug is triggered.

[halkun]

To answer that: It's a bug in FF7

It appears that FF7's movies were mastered with the wrong codec, It uses a colorspace that requires a particular video memory format. This means the movies were only designed for a particular set of graphic cards. The problem is that when the Truemotion codec detects an incompatible color format, it does a silent fallback to another colorspace, as opposed to giving an error. The problem is that the fallback mode is the wrong one.

Here are how the errors are laid out.

1) The FF7PC design team convert the PSX video into 24 bit graphics.
2) They design the game to run in 16 bit mode  <---- Mistake number 1
3) When the movie plays, the video player makes a request for 24 bit color space  <---- Error in FF7
4) Truemotion reads the FourCC, realizes that it can't play 24 bit color in 16 bit, so it does one of two things.

a) Converts the video to a {YUY2} colorspace (This is a 16 bit colorspace, it is an alias for {2YUY})
b) if that fails because of a video card error, it converts the video to the {UYVY} codec. This is a YUV 4:2:2 (8 bit) colorspace (Y sample at every pixel, U and V sampled at every second pixel horizontally on each line)

The problem is that the fallback is supposed to be {YVYU}, which is a 'YUV 4:2:2 colorspace like UYVY but with different component ordering within the u_int32 macropixel. Because macropixel (8x8 block) is rendered in reverse, the picture is rendered from the bottom-up as opposed to top-down... or upside-down!

The patch appears to fix the fallback.

My guess is the FF7PC dev team assumed the truemotion codec fell back a particular way when it didn't. In their defense, it's not like they had the sourcecode to truemotion, so they didn't know. I still lay the blame on them. It was their fault to have the movies encoded on the wrong colordepth in the first place.

Wow, mystery solved! Good job!

[Myria kitty]

If you play the movies in Winamp or Windows Media Player, they're upside down, even if your desktop bit depth is 16 or 24.

I don't know about video codecs at all, but it seems to me like the movies were mastered upside down intentionally to deal with some problem with TrueMotion playing movies upside down.

Perhaps in the Win95 days, TrueMotion could not handle playing 24-bit movies in 16-bit modes, and it falls back as you say.  Eidos responds to the problem by remastering the movies upside down.  Then, in later versions of the codec, 16-bit playback is supported, and suddenly the fallback doesn't happen.

I wonder what a good solution would be for making a permanent fix.  If this is right, short of modifying video files, it's hard to fix.  Binary patching a DLL that's loaded quite late (by msacm32.dll?) when multiple versions exist sucks.  My current workaround does LoadLibrary(L"tm20dec.ax") before running FF7 so that it's already in memory and will remain.  Then I patch it at a fixed address >_<

A strange possibility would be putting in libavcodec, which supports TrueMotion.  We might be able to trick it into working by passing a negative surface pitch value =)

[halkun]

Your movie player is using the same decoder, and falling back the same way.

The problem is your video card does not support the correct colorspace that is hard-coded in the video FourCC and the truemotion decoder is compensating by using another decoder, but the fallback is still going to the wrong one.

The video was hard coded for only one type of video card colorspace. That's the problem. If your card doesn't support it, the software make assumptions on how it's encoded.

1) The video was hard-coded for only particular colorspaces (video memory formats)
2) the colorspace is not available on your graphics card
3) The truemotion decoder assumes that if they encoded in X, then they need to use Y for different colorspaces.
4) The encoded video should of used codec Z in the first place, which has a different fallback path.