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

Benjamin Larsson banan
Mon Mar 23 21:54:07 CET 2009


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.

MvH
Benjamin Larsson



More information about the ffmpeg-devel mailing list