[Ffmpeg-devel] [PATCH] from DivX, Part 7: MSVC fixes
Thu Jan 26 00:30:44 CET 2006
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;
>>>> 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.
More information about the ffmpeg-devel