Reverse Engineering an Unknown AVI Codec (SP34 FOURCC)

[enegis]

Hello,

I'm trying to identify an old AVI video codec that uses the FOURCC SP34.

Background

Between 2001 and 2002, I recorded many videos using an external webcam connected to an IBM ThinkPad laptop.

At the time, all original AVI files played perfectly on my computer.

In 2004, I recompressed almost all of the videos to reduce their file size and then deleted the original files.

The recompressed videos also played correctly on my computer for several years.

However, after replacing my computer and reinstalling Windows, the videos could no longer be played because modern software cannot decode the video stream.

Unfortunately, I do not remember which software or codec I used for the recompression.

Reference File

One AVI file was apparently never recompressed and still works correctly.

Properties

AVI
Video codec: Cinepak (cvid)
Resolution: 320×240
15 fps
PCM unsigned 8-bit audio (11025 Hz)
Recompressed Files

The remaining AVI files have these properties:

AVI container
Video FOURCC: SP34
Resolution:
mostly 320×240
some 160×120
15 fps
PCM unsigned 8-bit audio (11025 Hz)

The audio plays correctly.

The video does not.


VLC

VLC reports:

Codec "SP34"
No suitable decoder module found.


FFmpeg

FFmpeg reports:

Unknown codec: SP34

No AVI container corruption is reported.

The files appear structurally valid.

What I Have Already Verified
AVI container is valid (RIFF / hdrl / movi / idx1).
Audio stream is intact.
File durations are correct.
File sizes are reasonable.
Microsoft FOURCC documentation contains no SP34 entry.
FOURCC.org also contains no SP34 entry.
My Questions
Has anyone ever encountered the SP34 FOURCC?
Could this be an old Video for Windows (VfW) codec?
Could it have been installed by an IBM webcam driver or another webcam application?
Does anyone have an old codec DLL registering VIDC.SP34?
Is there any known way to identify the actual codec behind this FOURCC?
Available for Analysis

I can provide:

A working Cinepak AVI file.
One or more SP34 AVI samples.
MediaInfo output.
FFmpeg/ffprobe output.
Hex dumps if needed.

Any help identifying this codec or recovering these AVI files would be greatly appreciated.

Thank you.

[jagabo]

Upload one of the sp34 files. One can often get an idea of the codec from examining a hex dump. Or try using ffplay and forcing the ffourcc to another known uncompressed "codec". I would try RGB24 and RGB32. Or the BGR variants.

[enegis]

Thank you very much for your fast response.

This is one of the original SP34 files created during the 2004 recompression process.

Looking forward to your analysis.

[Selur]

Assuming you do know what type your old laptop was exactly, you might be able to get the old drivers/software for the webcam which might include a vfw decoder,...

[enegis]

Thank you for the suggestion.
I do have one AVI from the same webcam that was never recompressed, and it still plays perfectly today. It uses the standard Cinepak (cvid) codec.
The problem only affects the files that I recompressed around 2004. That's why I currently suspect the SP34 codec came from the recompression software (or a codec installed on that system), rather than from the webcam itself.
Of course, if the webcam software installed a VfW codec that was later used by the recompression software, that is still a possibility.

[dietboby]

SP34 is the Sunplus "SP3X" Video for Windows codec, SP3X_32.DLL. It never turns up in any FOURCC list because it was never a standalone codec, it got installed by the bundled camera driver.

Your hunch about the IBM webcam was right. I found the DLL on an IBM ThinkPad UltraPort Camera II driver CD, sitting next to IBM_501B.SYS and EXVFW501.DLL, so the chipset is Sunplus SPCA501 class. That is probably the exact camera you had clipped to the ThinkPad. I used the DLL to decode your sample and it came out clean: all 373 frames, no errors, audio intact (screenshot attached). The codec even names itself when you open it:

ICGetInfo: handler='sp34'  name='SP3X_32.DLL'  desc='Sunplus 32-bit Compressor'

1. Get the codec

https://archive.org/details/22P5253

That is the "IBM ThinkPad UltraPort Camera II Option Software, IBM P/N 22P5253" disc. Free, no login. Download 22P5253.iso (274 MB, and be patient, even the page is slow). You do not need to burn or mount it. Just right click the ISO in 7-Zip and extract, then pull out this one file:

Driver\Drivers\Win2K\ENG\SP3X_32.DLL

53,760 bytes, dated 1999-10-18
MD5 cc651036e3a314ff08faa63784f433c0

It sits on the disc 24 times (Win98, WinMe and Win2K for 8 languages) and they are all identical, so any copy will do. That single 53 KB DLL is the whole fix, you can ignore the rest of the ISO.


2. Register it

Video for Windows codecs are 32-bit only, so no modern 64-bit player will ever load this one. Not a problem, you only need it once to convert everything.

On 64-bit Windows:

a) copy SP3X_32.DLL into  C:\Windows\SysWOW64\

b) run regedit and open
   HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32

c) New > String Value
   name  : VIDC.SP34
   value : SP3X_32.DLL

On 32-bit Windows, copy it to C:\Windows\System32\ and use the same key without the WOW6432Node part. A Windows XP VM works just as well and is the tidier place for a 27 year old DLL.


3. Convert your files

Use 32-bit VirtualDub 1.10.4. It has to be the x86 build, the x64 one cannot load VfW codecs. I ran these exact steps on Windows 11 and it worked first time, so they are tested, not guesswork.

a) File > Open video file, pick your AVI. It will display normally now.
b) Video > Full processing mode
c) Video > Compression, pick something modern (x264vfw or Xvid,
   or Uncompressed if you want an archival master)
d) Audio > Direct stream copy. Your PCM audio is already fine.
e) File > Save as AVI

For the whole collection, use File > Queue batch operation > Save as AVI on each file, then File > Job control > Start. Your 320x240 files need no special handling, VirtualDub takes the geometry from each file's own header.

One gotcha worth knowing: make sure you really are in Full processing mode. When I tried it in Fast recompress instead, VirtualDub wrote a file where every single video frame was empty, audio only. Full processing mode gave a correct 373 frame result.


One thing not to worry about

Roughly two thirds of the chunks in your files are zero length. That is not damage. They are duplicate frame markers that mean "same picture as the last one". In your sample, 137 chunks carry real data and 236 are repeats, so actual new content arrives at about 5.4 fps inside a 14.77 fps timeline. Any correct decoder just re-shows the previous frame, and the original timing stays intact.

I have your decoded sample here as an MP4 and as a lossless FFV1 master. I have not posted it since it is a family video and that is yours to share rather than mine, but say the word and I will send it over.

[enegis]

That's fantastic news. Thank you very much for taking the time to investigate this so thoroughly.
I'm relieved to hear that the video itself is intact and that the problem was simply the missing SP3X codec. Your explanation and step-by-step instructions are incredibly helpful.
I really appreciate your effort.

[Alwyn]

@dietboby, I've seen lots of helpful posts here on VH and yours above is up there with the best. Well done.

[enegis]

@dietboby, I will appreciate if you can send the the video to my email address: a3dnordicdesign@gmail.com

[cholla]

@dietboby, I've seen lots of helpful posts here on VH and yours above is up there with the best. Well done.

I don't believe I could have said it better.

[dietboby]

@enegis Email is out.

[enegis]

Thank you very much ❤️����