[MPlayer-dev-eng] Solaris patches
Michael Niedermayer
michaelni at gmx.at
Mon Sep 4 14:08:35 CEST 2006
Hi
On Sun, Sep 03, 2006 at 02:49:27PM +0100, Robin KAY wrote:
[...]
> >Can you explain why this doesn't work for you?
> >It apreantly works for everone else on a big endian machine.
> >(including my tests on solaris/sparc)
>
> Sorry, the patch is erroneously named. It's not really a big-endian bug
> at all (although that's where I discovered it), but a bug in the plain C
> versions of the YUV conversion routines (technically) affecting both
> byte orderings.
>
> The real bug was in assigning the wrong (inverted) value to isRgb in
> yuv2rgb.c. This is not apparent if platform-specific versions of the
> conversion routines are used. Neither is it apparent if Xvideo is used.
> Your test builds under Solaris/SPARC are probably compiled with mediaLib.
>
> Since vo_x11.c always used machine word BGR irrespective of the colour
> masks, the bug is also not apparent if the server XImage format matches
> the client's machine word RGB. The changes to vo_x11.c perform a more
> stringent test of the colour masks in order to select machine word RGB
> or BGR.
>
> Modified the if statement as above and removed the change to the switch
> statement:-
>
> http://www.blastwave.org/~komadori/patches/mplayer-head-20060902-fix-broken-colours.diff
the change to yuv2rgb.c is wrong and rejected, please read
DOCS/tech/colorspaces.txt
>
> >>http://www.blastwave.org/~komadori/patches/mplayer-head-20060902-fix-solaris8-errors.diff
> >>
> >>
> >What error is fixed here?
> >
> >
> Answered in my replay to 'Dominik Mierzejewski'.
>
> >>http://www.blastwave.org/~komadori/patches/mplayer-head-20060902-fix-unaligned-read.diff
> >>
> >>Fixes a crash on SPARC in the ASF demuxer.
> >>
> >>
> >Using memcpy to fix alignment here looks bogus to me.
> >But i'm not sure what the correct way to do it would be.
> >I've never dealt with such issues.
> >
> >
> I initially just used ptr[0] | (ptr[1] << 1),
you mean ptr[0] | (ptr[1] << 8) ?
> but then I saw the
> memcpy(3C) method was used elsewhere in asfheader.c. I imagine this was
> done to make the code portable to systems with non-octet chars.
IIRC sizeof(char) = 1 per c standard
[...]
--
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 MPlayer-dev-eng
mailing list