[Ffmpeg-devel] [PATCH] from DivX, Part 7: MSVC fixes

[Steve Lhomme]

Michael Niedermayer wrote:
>>> would be cleaner but even then i would say that needs some disscussion and
>>> should be a seperate patch
>> Given __align8(type, var) was rejected because it's "unreadable", I 
>> don't think this macro would qualify neither. Other than that, I agree 
>> this is a better long-term change.
> 
> who rejected __align8(type, var)? i didnt or at least i dont remember it

I think Felker was the one against it.

> no, i mean h263.c is a codec which is abstract code no (G)UI not anything 
> i dont see why that would need windows.h

It's OK. I removed it in my build and it works just fine. It was 
probably added during the early phase of MSVC porting.

>>>> Index: libavcodec/loco.c
>>>> ===================================================================
>>>> RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/loco.c,v
>>>> retrieving revision 1.5
>>>> diff -u -r1.5 loco.c
>>>> --- libavcodec/loco.c	8 Apr 2005 21:34:48 -0000	1.5
>>>> +++ libavcodec/loco.c	16 Dec 2005 23:13:42 -0000
>>>> @@ -241,14 +241,14 @@
>>>>         l->lossy = 0;
>>>>         break;
>>>>     case 2:
>>>> -        l->lossy = LE_32(avctx->extradata + 8);
>>>> +        l->lossy = LE_32((int8_t*)avctx->extradata + 8);
>>> hmmmm, IMHO make the extradata field in AVCodecContext uint8_t * instead
>> If that can be accepted, I'd be happy with that change.
> 
> yes, uint8_t extradata is ok

Applied locally and it works fine.