[FFmpeg-devel] [PATCH] Common code for Indeo interactive

[Maxim]

Benjamin Larsson schrieb:
> Ivan Kalvachev wrote:
>   
>> On 3/22/09, Maxim <max_pole at gmx.de> wrote:
>>     
>>> Aurelien Jacobs schrieb:
>>>       
>>>> On Thu, Mar 19, 2009 at 11:12:40PM +0100, Maxim wrote:
>>>>
>>>>         
>>>>> Hello guys,
>>>>>
>>>>> here is the 1st part of my patch making FFmpeg decode Indeo interactive
>>>>> (indeo4/indeo5) streams. Both codecs are very similar but use abit
>>>>> different bitstream formats, so I decided myself to put all common
>>>>> functions and tables together and submit them as a separate patch.
>>>>> The 2nd part will be the long-awaited indeo5 decoder...
>>>>> Please review!
>>>>>
>>>>> [...]
>>>>>
>>>>> /**
>>>>>  *  motion compensation without adding delta
>>>>>  *
>>>>>  *  @param  buf     [in,out] pointer to the block in the current frame
>>>>> receiving the result
>>>>>  *  @param  ref_buf [in] pointer to the corresponding block in the
>>>>> reference frame
>>>>>  *  @param  pitch   [in] pitch for moving to the next y line
>>>>>  *  @param  mc_type [in] interpolation type
>>>>>  */
>>>>> static void ivi_mc_8x8_no_delta (int16_t *buf, int16_t *ref_buf, uint32_t
>>>>> pitch, int mc_type)
>>>>>
>>>>>           
>>>> This function probably is exactly the same as put_pixels_tab[1][mc_type]()
>>>> from dsputils. And you can probably also use dsputils for all other MC
>>>> functions.
>>>>
>>>>         
>>> I just looked into it.
>>> First problem I encountered is that my code operates on int16_t pixels
>>> instead of uint8_t ones in the dsputils. The Intel's slant transform
>>> requires that the pixel values are concentrated about zero - also being
>>> signed values. That's why the bias value 128 is subtracted in the
>>> encoder and added back again after decoding in order to convert unsigned
>>> pixel values into signed ones and back again. I need to integrate a step
>>> of the adding the bias value right after the inverse transform in order
>>> to be able to use the motion compensation functions from dsputils...
>>> 2nd problem is even bigger: Indeo's transform requires 12 bits of
>>> processing in order to obtain the desired precision. Some Intel patents
>>> defines the precision of the input transform coefficients to be = 12
>>>       
>> Intel patents? WTF??
>>
>> Have you read patents in order to implement this codec?
>> If you have knowingly implemented codec that is covered under
>> patent you'd probably won't be able to release it under gpl
>> and we'll have to enable it only when --enable-nonfree.
>>
>> Until these patents expire.
>>     
>
> Those patents are void in the EU (software algorithms) so we don't have
> to worry about that.
>   

The patents I know about describe another algorithm (a hardware unit for
telecommunications) that uses the same transform. There are no known
patents regarding the Indeo video codec in means of bitstream
description, tables an so on. That's why I'm agreed with Benjamin -
don't worry...