[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