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

[Michael Niedermayer]

Hi

On Wed, Jan 25, 2006 at 09:49:18AM -1000, Steve Lhomme wrote:
[...]
> >>+#if __STDC_VERSION__ >= 199901L
> >>     uint8_t fixed[s->mb_stride * s->mb_height];
> >>+#else
> >>+    uint8_t *fixed=(uint8_t*)alloca(s->mb_stride * s->mb_height);
> >>+#endif    
> >
> >rejected
> >
> >#define A(type, name, size) type name[size];
> >#define A(type, name, size) type *name= alloca(size * sizeof(type));
> >
> >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


> 
> >>Index: libavcodec/h263.c
> >>===================================================================
> >>RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/h263.c,v
> >>retrieving revision 1.292
> >>diff -u -r1.292 h263.c
> >>--- libavcodec/h263.c	12 Dec 2005 01:56:45 -0000	1.292
> >>+++ libavcodec/h263.c	16 Dec 2005 23:10:06 -0000
> >>@@ -39,6 +39,9 @@
> >> #include "h263data.h"
> >> #include "mpeg4data.h"
> >> 
> >>+#ifdef CONFIG_WIN32
> >>+#include <windows.h>
> >>+#endif
> >
> >rejected, this doesn belong in here
> 
> You mean it should be made more general ?

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


> 
> >>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

[...]
-- 
Michael