Goal

Extract the FMV cutscenes from the PS3 version of Resident Evil 0 HD Remaster (MT Framework) to a normal container (MP4/MKV).

Files

Location inside the extracted PKG:

USRDIR/nativePS3/movie/*.pam

Examples: mt00.pam, mt03.pam (43,506,896 bytes), playdemo.pam.

Header layout

Hex dump of the first bytes of mt00.pam:

00000000   00 53 46 48 00 01 00 01 0D 25 80 00 00 00 00 00  .SFH.....%......
00000010   50 41 4D 46 30 30 34 31 00 00 00 02 00 01 A4 AE  PAMF0041........
00000020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
...
00000060   00 00 00 64 00 00 00 00 00 01 5F 90 00 00 01 88  ...d......_.....
00000070   0D 8A 00 01 D4 C0 00 01 5F 90 00 00 00 01 00 01  ........_.......
00000080   00 00 00 44 00 00 00 01 5F 90 00 00 01 88 0D 8A  ...D...._.......
00000090   00 01 00 00 00 32 00 01 02 00 00 00 E0 00 24 D2  .....2........$.
000000A0   00 00 00 B8 00 00 01 1D 44 00 C4 01 00 00 00 00  ........D.......

Observations:

• 0x00–0x0F — a 16-byte wrapper that is not part of the Sony PAMF spec. Contains the ASCII tag SFH at offset 0x01.

• 0x10 — the standard PAMF0041 magic.

• 0x60 onwards — a long table of repeating C0 xx ... <4-byte offset> <4-byte timestamp> records. This looks like an EP-map / seek table.

• The table ends around 0x0E30; everything from there to 0x1010 is zero padding.

Program stream layout

Scanning the whole file for the MPEG-PS pack start code 00 00 01 BA:

• First occurrence: 4112 (0x1010)

• Stride: exactly 2048 bytes

• Every 131088 bytes (64 packs + 16) one gap is 2064 instead of 2048, i.e. 16 extra bytes appear at offsets 131088 * k (k = 1, 2, 3, ...). This is perfectly regular across the entire file.

I initially assumed those 16 bytes were proprietary chunk markers injected into the payload and wrote a script that strips them. It made no difference to the decode errors, so they are most likely a legitimate pack header with stuffing.

What I tried

1. VGMToolbox → Misc. Tools → Stream Tools → Video Demultiplexer → PAM (PS3) Fails immediately:

   Error processing <...\movie\mt00.pam>.
   Error received: Input string was not in a correct format.

Presumably the PAM parser chokes on this variant of the header / seek table.

2. Manual carve from offset 4112 to EOF (the "strip 800 bytes" trick that works for Resident Evil 5 does not apply here — the header is longer). The result is a valid MPEG-PS file. ffprobe reports:

   Input #0, mpeg, from 'playdemo.mpg':
     Duration: 00:00:34.43, start: 1.600600, bitrate: 6711 kb/s
     Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt709, progressive),
       1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn
     Side data:
       CPB properties: bitrate max/min/avg: 8500000/0/0 buffer size: 9781248

Resolution, frame rate, aspect ratio, duration and CPB values are all sane. No audio stream is detected — only the 0x1e0 video stream.

3. Variant with the 16-byte markers removed — identical error profile.

The problem

The picture is recognisable but heavily blocky throughout the entire clip. ffmpeg -v error -i out.mpg -f null - produces a continuous stream of:

[mpeg2video] ac-tex damaged at 34 6
[mpeg2video] mb incr damaged
[mpeg2video] slice mismatch
[mpeg2video] invalid cbp -1 at 48 9
[mpeg2video] Invalid mb type in I-frame at 40 12
[mpeg2video] Warning MVs not available
[mpeg2video] overread 9
[mpeg2video] end mismatch left=79 5682DF at 0 45
[mpeg2video] concealing 93 DC, 93 AC, 93 MV errors in B frame

Notable: the errors hit I-frames as well as P/B, and they are spread evenly across the whole 34 seconds rather than clustered at particular offsets.

Also tried, with no improvement:

• -analyzeduration 100M -probesize 100M

• -err_detect ignore_err -ec guess_mvs+deblock+favor_inter

• transcoding through VLC instead of ffmpeg (VLC's decoder conceals a bit better during playback, but a re-encode comes out just as corrupt)

• Windows Media Player — same artifacts as ffmpeg

Reference gameplay footage on YouTube shows these cutscenes are clean in-game, so the source material itself is fine.

Hypothesis

The container is structurally perfect while the slice payload decodes wrong. That pattern doesn't look like a bad carve — a wrong offset would break the sequence headers too, and the resolution/fps/duration would not come out right.

It looks more like selective encryption of the payload with the pack/PES headers left in the clear so the hardware decoder can still parse and seek — similar in spirit to what Polyphony does with Salsa20 over PAMF in Gran Turismo, but a Capcom variant.

Questions

1. Has anyone already dealt with PAMF files from Capcom's PS3 HD remasters (RE0, RE1 HD, DMC HD Collection, etc.)?

2. Is the SFH 16-byte wrapper at offset 0 a known Capcom structure?

3. Is selective encryption on MT Framework PS3 movies documented anywhere, and if so, where does the key live?

4. Is there a newer VGMToolbox fork whose PAM demuxer handles this variant?

Edited 18 hours ago18 hr by YuryPetukhou