[FFmpeg-cvslog] r17404 - trunk/libavcodec/mpegvideo_xvmc.c
Sat Feb 21 21:34:26 CET 2009
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
> 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...
Size: 6736 bytes
Desc: not available
More information about the ffmpeg-cvslog