[FFmpeg-devel] [PATCH] Indeo5 decoder

Maxim max_pole
Thu Apr 2 13:14:11 CEST 2009


Reimar D?ffinger schrieb:
> On Thu, Apr 02, 2009 at 11:40:49AM +0200, Maxim wrote:
>   
>>> useless & [0]
>>> indeo5patch.txt:676:+                band->dequant_intra = &deq4x4_intra[0][0];
>>> indeo5patch.txt:677:+                band->dequant_inter = &deq4x4_inter[0][0];
>>>   
>>>       
>> changing it to
>>
>> band->dequant_intra = deq4x4_intra;
>>
>> causes the following compiler's message:
>> warning: assignment from incompatible pointer type
>>     
>
> One & cancels with one [0], so that would be
> band->dequant_intra = deq4x4_intra[0];
>   

thanks, fixed...

>>> indeo5patch.txt:1035:+    av_freep(&planes[0].buf1);
>>> indeo5patch.txt:1036:+    av_freep(&planes[0].buf2);
>>>   
>>>       
>> Hmm, shouldn't av_freep receive a POINTER to a POINTER as it's declared
>> in its prototype? Will then the removing of the "&" lead to a wrong
>> program behavior?
>>     
>
> I think those a false positives, if you still haven't noticed that was
> an automated "review" by tools/patcheck
>   

Aha, thanks! I didn't noticed it because I'm not familiar with this
tool/script...

> You could probably use &planes->buf1 here though, but that's probably
> worse (i.e. uglier)
>   

I would leave it as is because there are several other statements like
&planes[x]->buf1
so the line
&planes[0]->buf1
looks more readable IMHO...
It would be possible to use constants instead of those numbers, i.e.

av_freep(&planes[LUMA]->buf1);

would it be better?

>>> missing const?
>>> indeo5patch.txt:1248:+    int32_t *src, *dst, tmp[64];
>>> indeo5patch.txt:1295:+    int32_t *src, *dst, tmp[16];
>>>       
>> Yes, this is abit complicated! The src pointer should be declared as a
>> pointer to a const data in fact. But due to the given design of the
>> transform it cannot be made so because both IVI_IREFLECT and
>> IVI_SLANT_BFLY make changes to their operands. I need to redesign the
>> whole transform in order to make the src const. Will it worth it?
>>     
>
> This might just be a false positive by the script.
> I think Michael just wanted to make you look over the obvious things a
> simple tool can detect before "wasting" a human's time with a review
> (there are just too few people doing patch reviews).
>   

Ok, I'll leave the code as is then...

Regards
Maxim



More information about the ffmpeg-devel mailing list