[Ffmpeg-devel] swscale and 64 bit problem (mmx code)
Fri Mar 2 03:02:10 CET 2007
On Thu, Mar 01, 2007 at 08:50:26PM +0100, Reimar D?ffinger wrote:
> On Thu, Mar 01, 2007 at 08:28:14PM +0100, Michael Niedermayer wrote:
> > On Thu, Mar 01, 2007 at 06:12:53PM +0100, Reimar D?ffinger wrote:
> > > On Thu, Mar 01, 2007 at 02:28:44PM +0100, Baptiste Coudurier wrote:
> > > > Reimar D?ffinger wrote:
> > > > > Well, the non-SWS_ACCURATE_RND case is trivial to fix I think, see attached
> > > > > patch.
> > > [...]
> > > > > - chrMmxFilter[4*i+0]= (int32_t)chrSrcPtr[i];
> > > > > + chrMmxFilter[4*i+0]= (uintptr_t)chrSrcPtr[i];
> > > > > + chrMmxFilter[4*i+1]= (uintptr_t)chrSrcPtr[i] >> 32;
> > > [...]
> > > > Isn't uintptr_t optional extended type in C99 ? I don't have specs,
> > > > but Mans said last time those types were optional:
> > > > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-February/052196.html
> > >
> > > Well, I originally intended to submit this only for testing, not for
> > > inclusion since it is a hackish fix. Though probably no worse that it is
> > > currently.
> > > Attached is an alternative, since we can only support up to 64 bits that
> > > way anyway, not using a *ptr_t type isn't a real loss.
> > looks ok
> For the SWS_ACCURATE_RND case I think it might be best to either just
> ignore SWS_ACCURATE_RND with a warning printed or fall back to the
> non-MMX version for ARCH_X86_64. Opinions?
id say non MMX, or fix the code
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel