[FFmpeg-devel] Google Summer of Code participation

[Mike Melanson]

Reimar D?ffinger wrote:
> On Sat, Mar 28, 2009 at 01:55:38PM +0100, Thilo Borgmann wrote:
>> Reimar D?ffinger schrieb:
>>> On Sat, Mar 28, 2009 at 12:20:32PM +0100, Thilo Borgmann wrote:
>>>   
>>>> no. 12: "16-bit Interplay Video Decoder"
>>>> Sounds interesting and as there is a working 8-bit decoder, wich throws 
>>>> some errors if operating on the 16-bit demo file, there seems to be a 
>>>> good starting point. Unfortunately, the section about 16-bit opcodes is 
>>>> far from useful, if opcodes would have to be changed, this task becomes 
>>>> very difficult...
>>>> http://wiki.multimedia.cx/index.php?title=Interplay_Video
>>>>     
>>> I doubt the opcodes changed much, though the code to implement them will
>>> probably be quite different, since it (probably) operates on 16-bit
>>> data, I doubt there are dsputil functions for that.
>>> You can extract the video frames into separate files via:
>>> ./ffmpeg -i interplay-logo.mve -an -vcodec copy -copyinkf -f image2 test%04d.raw
>>> You can then try decoding a single one like this:
>>> ./ffmpeg -f image2 -vcodec interplayvideo -s 432x320 -i test0001.raw test.bmp
>>> Though you will have to comment out some of the interplayvideo code that
>>> expects a palette first - I assume that the 16 bit variant does not use
>>> a palette...
>>>
>>>   
>> Thank you for these hints!
>>
>> May be, I will inspect this issue later, as this seems to be a thing 
>> where I can also support the project, but for the time being, I decided 
>> to get on with the CorePNG problem.
> 
> Probably a good choice, we do not have automated regression tests for
> that interplay format yet, and due to this I have not yet improved the
> huge amount of needlessly complex code in it either. So there is a
> chance that task will be easier to do in the near future.
> Still if anyone wants to work on this I'll try to give them hints on how
> to "reverse engineer" this.

 From what I have read, indeed, the opcodes that define pixels through 
8-bit palette indices have just been expanded to use 16-bit RGB pixels 
in little endian format instead. I can't remember where the data is to 
specify 16-bit vs. 8-bit for the overall format, but I'm sure we could 
figure it out if we needed to.

BTW, about the automated test, I was having trouble making that work 
across configurations awhile ago (after the fix). But I just 
investigated it again and it seems to be working. I have now activated 
the test; let's see how it goes.

-- 
     -Mike Melanson