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

Ivan Kalvachev ikalvachev
Wed Mar 25 17:12:20 CET 2009


On 3/24/09, Maxim <max_pole at gmx.de> wrote:
> 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 -

This is what I wanted to hear.
Thank you very much.



More information about the ffmpeg-devel mailing list