[FFmpeg-devel] [PATCH] Common code for Indeo interactive
Sun Mar 22 22:28:28 CET 2009
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[mc_type]()
> from dsputils. And you can probably also use dsputils for all other MC
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
bits. Not sure if it's true for the output values though. But all known
Indeo decoders/encoders operate internally on 16bit signed pixels. The
pixels are clamped and converted into uint8_t values just at the very
end. So I'm not sure that the changing of the internal representation
from 16bits to 8bits wouldn't produce overflows and lead to a quality
My Question (Jason, Loren, Michael, others?): Is there any possibility
to measure the precision of the slant transform's output mathematically?
The input coeffs have 12bits precision. I'm afraid I'm not skilled
enough to do that. Examine the outputs can take long time... Any suggestion?
More information about the ffmpeg-devel