I know you guys must have thought about this but theoretically couldn't you take the code for the .duk decoder from the sc2 libs and apply it to the duk extractor tool which for now only does the audio?
Or make a "2raw" variant as there are for abx and aif?
Or more likely is there actually more to it than just decoding the video contents into a raw format, and it isn't just a container format like I am thinking of it as?
This only comes to mind because it would be wonderful to have these videos perfectly preserved in a more stable format such as H.264. Not to mention plenty of other 3DO games that use the duk format to store its videos which I have had to use UQM to view. (used my FMV mod and set the duks to be the LOGO so that they would be the first video to open up.)
I'll check this later today, but I think libavcodec already supports the SC2 3DO videos. At the very least, there is already support for many close relatives of the format (Duck TrueMotion-S), so you wouldn't be working from scratch (and you'd get support in many existing encoding tools for little work).
Also since there is no real documentation on the duk format that I can find; What are the .hdr, .frm, .tbl files for? Are they just separated headers for bitrate, length, whatnot?
I think your best bet is to use UQM's DUK decoder as a basis. The source code is brief enough that it works as quite a readable specification. libavcodec only seems to support the later TrueMotion 1 format in MOV or AVI containers.
Basically, the .hdr file contains stuff like size and some information on how the video is coded, the .frm file is a list of where each frame starts and .tbl is a bunch of vectors used in decoding.
I suspect you could do a quick and dirty export of raw video data just by dumping each frame to disk at the end of dukv_DecodeFrame.
I'll have to wait until I have an abundance of time on my hands, sounds like a daunting project as it is and I'm not as good at coding as I'd like to be.