Have been looking into this and found the following:
There are two "official" types of FLIC files: FLI and FLC (the names of these types refer to the filename extensions). The FLI files are the older format and are limited to a resolution of 320×200. The FLC file format adds configurable resolution and better compression.
(Source:
https://www.compuphase.com/flic.htm)
The original intro file is a .FLI, as evidenced by both the file extension and the magic byte marker at offset 0x04. The original also uses a delay between video ticks of 5 (value at offset 0x10 in the .FLI).
At this point, many thanks to sylandro and his post here:
https://openxcom.org/forum/index.php/topic,3234.msg84987.html#msg84987.
That made my tinkering a lot easier. Although, I am not really sure why he suggests to set the delay to 1 and force the file type via hex-editing. My research seems to discourage that approach in favor of a toolset that encodes the correct filetype to begin with. While looking at the OXCE source code, I noticed that the FLIC player being used supports both the older FLI and the newer FLC types for playback, so we are not restricted to FLI files here. In fact, the only difference in the source code between the two file formats is how the delay between two frames is calculated.
The hard part seems to be to get the framerate of the video right. Especially since my testing indicates, that, for example, the VLC player will play FLIC files at a different frame-rate than the OXCE in-game FLIC Player.
The game will handle FLC and FLI files differently regarding to frame-rate (as the standard demands).
The default delay between frames for FLI files is
SPEED_FROM_FILE_HEADER * (1000.0/70.0)
So a speed value of 5 in the file header (as used by the original intro) would result in a delay of ~ 71,4 ticks, where one tick is one millisecond. Since there are 1000 ticks in a second this means the video plays at a frame-rate of about 14 fps. When starting out...
Stepping through the code I noticed the following behaviour with the built-in audio and intro sequence of the UK version: The frame-rate gets changed while the cutscene is playing. It goes like this, it starts out with a header speed of 5 and about 14 fps and then changes the header speed to 7 thereby reducing the frame-rate to 10 fps. The command for changing the video playback speed seems to be embedded into the intro soundtrack audio data. There are more command embedded: resetting the framerate to 14 fps for a small rendered animation of the space ship and then going to back to 10 fps.
At one point the speed even gets set to 1 resulting in 70 fps (for a few frames?!) going back to speed 6 and about 11 fps shortly after that. The Mutons teleporting out of the way is played with a speed of 10 and 7 fps and so on. Basically the animation speed is controlled by commands embedded in the audio track, which constantly changes speed to emphasize some frames or smooth the animation of others.
This also explains the hex editing of sylandros post: He sets to the speed in the file header to 1, resulting in a delay of 1000 / 70 = 14 (unsigned int) and calculated frame-rate of 70 fps. Which is the frame-rate he exported the original video file at. His file has 3300 video frames compared to the 810 frames which are really there and different to each other.
While the default delay between frames for FLC files is
1000 / (AUDIO_DATA_SAMPLERATE / AUDIO_FRAME_SIZE)
Sample Rate: 44.1 khz -> 44100 Samples per Second
Audio Frame Size: Sample Size (in Bytes) * Channels -> 32-Bit Stereo => 4 * 2 = 8 bytes
Which seems to be defined by the audio data. A bit odd to me, but maybe there are good reasons for this. However this of course has the consequence, that a FLC file will depend on the audio sample rate for its playback speed. This definitely explains some strange results I've been seeing. It also seems to contradict the FLC file specs, which state, that a FLC file's speed value represents the delay between two frames in milliseconds.
I have been using the following toolchain to successfully re-encode the cutscenes from a PSX ISO file for OpenXcom. The same approach can be used to encode any video or picture stream into cutscenes.
FLIC animations as used by OpenXcom use a 8-bit color depth with an indexed colormap (a color palette). One palette is used for the whole animation, which is the reason ppm2fli will use a remapping algorithm to make sure all the colors used in all the pictures can be mapped to one color palette. You can ensure that no changes happen to your files by preparing the images so they already use an optimized shared palette.
ppm2fli - Takes a series of .PPM picture files and encodes them into a .FLI or .FLC video file
unflick - Reverses the process and converts a .FLC or .FLI file into a series of .PPM picture files (I used this successfully on the original intro file)
http://vento.pi.tu-berlin.de/STROEMUNGSAKUSTIK/SOFTWARE/ppm2fli/main.htmlA graphics tool-suite which includes pnmremap
pnmremap - Uses an dithering like algorithm (Floyd Steinberg) in order to enhance image quality on gradients, I have used this as an alternative color mapping algorithm for better quality of the output.
http://netpbm.sourceforge.net/mogrify is part of imagemagick and allows the conversion of BMP files to PPM files
https://imagemagick.org/script/mogrify.phpgegl - Graphics manipulation toolkit written for GIMP
http://gegl.org/PSX Decode - Used for getting the video files from a PSX ISO
https://github.com/m35/jpsxdecFrom AVI to OXC FLIC File
# extract frames from AVI, changing frame-rate on export (use for example 17.5 fps for FLI)
ffmpeg -i input.avi -filter:v fps=fps=25 frame%04d.bmp
# optional: resize the frames:
for filename in *.bmp; do basename="${filename%.*}"; convert "$basename.bmp" -resize 320x200 small_${basename}.bmp; done
# convert BMPs to PPMs
for filename in *.bmp; do basename="${filename%.*}"; mogrify -format ppm "$basename.bmp"; done
# optional / alternative, use gegl for noise reduction or other cleanup during conversion
for filename in *.bmp; do basename="${filename%.*}"; gegl "$basename.bmp" -- noise-reduction iterations=2 ppm-save path="./$basename.ppm" bitdepth=8; done
# make a list of ppm files
ls -1 *.ppm > pics.list
# FLI: generate the FLIC animation, speed set to 4 for 17.5 fps in the FLI formt
ppm2fli -O -s 4 pics.list output.fli
# FLC: generate the FLIC animation, speed set to 40 for 25 fps in the FLC formt
ppm2fli -g 320x200 -s 40 pics.list output.flc
# Optional step for better quantization (use the output of this command for the list which ppm2fli uses instead)
for filename in "$i"*.ppm; do pnmremap -mapfile="table-$i.ppm" -fs "$filename" > "./requant/$filename"; done
Because of the limitations of the FLIC format, there are only a bunch of frame-rates which can be used without getting into floating point problems:
The FLI format can use these whole-number FPS values:
70fps at speed 1
35fps at speed 2
17,5fps at speed 4
14fps at speed 5
10 fps at speed 7
7 fps at speed 10
5 fps at speed 14
While the FLC format has a whole-number FPS for these speed values:
1000fps at speed 1
500fps at speed 2
50fps at speed 20
40fps at speed 25
25fps at speed 40
20fps at speed 50
In this example I used 25 fps and the FLC file format, since the FLI file format does not allow for this frame-rate. Unfortunately, the current Version of OXC is not standard compliant with regards to the FLC standard. This has to do with the suppport of the non-standard TFTD video files. I have already proposed a fix in form of a PR and hope for its inclusion in the upcoming OXC versions.
@rbuck000
The tools ppm2fli and unflick which I have been using both allow for the extraction of the color palette of the original video files. However, as far as I understand, the palette in the video files are completely indepedent of the rest of the game. So you should be able to just choose an optimal palette for your video content.