[FFmpeg-devel] [PATCH] FLIC demuxer fix for the first two X-COM games (also adds audio)

[Mike Melanson]

Michael Niedermayer wrote:
> On Fri, Feb 26, 2010 at 10:05:00AM +0100, Tomas H?rdin wrote:
>> Good morning
>>
>> Last christmas I reverse-engineered the video format used in the first
>> two X-COM games ("UFO: Enemy Unknown" and "X-COM: Terror from the
>> Deep"). It turned out to simply be normal FLIC files with extra audio
>> chunks. This patch detects the presence of such a chunk at the start of
>> the file, and adds a 22050 Hz mono 8-bit audio stream in that case. It
>> also calculates the proper framerate, since these videos appear to have
>> been created in a two-step process (audio added later, thus altering the
>> frame rate).
>>
>> In order to detect these videos I had to peek at the first preamble in
>> the file, which means reading and rewinding six bytes. This should
>> hopefully not be a problem since I'm fairly sure ByteIOContext has a
>> small buffer for these sort of things. A similar trick is used in the
>> Magic Carpet case, so I've figured it's OK anyway.
>>
>> Regarding audio, the code assumes all audio chunks contain the same
>> number of samples and sets block_align accordingly. One final thing is
>> that these audio chunks have an extra 10 B header not accounted for in
>> the chunk header, which caused the old demuxer to "derail".
>>
>> I ran the regression test for good measure. They still pass. Samples
>> uploaded to incoming/xcom/ (*.VID). Works for all five videos in the
>> second game, but I haven't been able to test it on those in the first
>> game.
>>
>> /Tomas
> 
>>  flic.c |   72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------
>>  1 file changed, 66 insertions(+), 6 deletions(-)
>> b303ed0974425f738f96476229cd75b8c01817a3  xcom.patch
> 
> looks ok, probably mike will want to add a test to fate
> and maybe flic needs a second maintainer

Indeed. Thanks for the contributions. No game format is too minor.

-- 
     -Mike Melanson