[FFmpeg-cvslog] r17404 - trunk/libavcodec/mpegvideo_xvmc.c

[Ivan Kalvachev]

On 2/18/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Feb 18, 2009 at 08:11:29PM +0200, Ivan Kalvachev wrote:
>> On 2/18/09, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Wed, Feb 18, 2009 at 12:51:28AM +0100, diego wrote:
>> >> Author: diego
>> >> Date: Wed Feb 18 00:51:28 2009
>> >> New Revision: 17404
>> >>
>> >> Log:
>> >> Replace sizeof(short) by the more robust sizeof(*s->pblocks[i]) in
>> >> memset
>> >> and
>> >> memcpy calls.  s->pblocks is the element actually being handled.
>> >
>> > ok +2 for you
>> >
>> > diego 19
>> > ivan 20.5
>>
>> That's actually wrong. XvMC defines block data as short
>
> its not wrong, the type of pblocks is wrong, it should be DCTELEM
> well actually a array of 12 pointers to arrays of 64 DCTELEM
> then it would be sizeof(*s->pblocks[i]) instead of sizeof(*s->pblocks[i])*64

Actually this is exactly what I thought that this task should do.

I've attached a patch that implements it, would you review it and
tell me if it is ok to commit. I couldn't decide myself
if memset/memcpy should take *s->pblock[i] or just s->pblock[i],
both give same pointer value.

>> and this is how it is in the xvmc structure.
>> pblocks points into the data array so sizeof(short) is the correct way to
>> use
>
> no pblocks points into array of DCTELEM, it just works out because
> short == DCTELEM and because someone added casts in mpegvideo to hide the
> (correct) warnings that its broken.
>
>
>>
>> Now, making xvmc work when DCTELEM is not short, is interesting task.
>> But for now there is no reason for me to implement it.
>
> id give you half a point for that
> and another half one if you at least get rid of the incorrect casts

Maybe I'll do it just as a sign of good fate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pblocks.patch
Type: application/octet-stream
Size: 6736 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20090221/3653d9b3/attachment.obj>