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/*.pamExamples: 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
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.
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: 9781248Resolution, frame rate, aspect ratio, duration and CPB values are all sane. No audio stream is detected — only the 0x1e0 video stream.
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 frameNotable: 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
Has anyone already dealt with PAMF files from Capcom's PS3 HD remasters (RE0, RE1 HD, DMC HD Collection, etc.)?
Is the SFH 16-byte wrapper at offset 0 a known Capcom structure?
Is selective encryption on MT Framework PS3 movies documented anywhere, and if so, where does the key live?
Is there a newer VGMToolbox fork whose PAM demuxer handles this variant?
By
YuryPetukhou ·
