[Ffmpeg-devel] [PATCH] BMP encoder
Michael Niedermayer
michaelni
Tue Oct 31 17:46:05 CET 2006
Hi
On Tue, Oct 31, 2006 at 02:27:10PM +0100, Michel Bardiaux wrote:
> Michael Niedermayer wrote:
> >Hi
> >
> >On Mon, Oct 30, 2006 at 06:50:35PM +0100, Michel Bardiaux wrote:
> >[...]
> >
> >>Note that I have some doubts about that code: it seems to assume that IF
> >>the compiler is not gcc THEN alignment is not an issue for 16 or 32 bits
> >>store. That is clearly wrong. Is dsputil.h supposed to be included by
> >>client code?
> >
> >not really, at least ST*() isnt supposed to be used ...
>
> Well, they'll be moved anyway, see other message. But I've just
> remembered that in some app I call imgconvert directly, no codec or
> whatever involved, and for that to work I had to call dsputil_init
> directly, and for that include dsputil.h.
>
> Move the prototype for dsputil_init to avcodec.h? Or call it from
> imgconvert (and maybe other places)?
as imgconert will be replaced by swscaler, i see no sense in fixing
such things ...
>
> >
> >
> >>If not, then why the 'else not GNUC clause?
> >
> >because we do support a few other compilers ...
>
> But if dsputil.h is NOT supposed to be exported, then it has only to
> support gcc.
no because we do support other compilers, gcc is not the only c compiler
on the planet, we do not support c++ compilers but thats a differnt matter
>
> Besides, the non-gcc part is simply wrong: it assumes a naive unaligned
> store will work, and that's false on many architectures.
yes, this should be fixed with a #ifdef ARCH_X86 around the code and a
slow byte per byte reading for the non gcc non x86 case
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is
More information about the ffmpeg-devel
mailing list