[MPlayer-dev-eng] [PATCH] bigendian fix for hwac3

[Ulion]

2007/9/13, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> Hello,
> On Thu, Sep 13, 2007 at 07:58:53PM +0800, Ulion wrote:
> > 2007/9/13, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > On Thu, Sep 13, 2007 at 01:14:40PM +0200, Reimar Döffinger wrote:
> > > > > Yes, I'd like to use swab for all these modifications but the swab man
> > > > > page did not say whether it works fine when src==dst.
> > > > >
> > > > > So, if you insist, I can give a bswap_16 version according to your
> > > > > sample code. Here it is.
> > > >
> > > > Please just try it with swab, if it works we should use it IMO. If there
> > > > are some weird systems where it does not work for src==dst we can write
> > > > a replacement function for those.
> > > >
> > > > Otherwise the patch looks good to me.
> > >
> > > On second thought, could you test attached patch?
> >
> > This patch will mix native byte-order with macro WORDS_BIGENDIAN, the
> > later one could be set by configure with enable/disable big-endian
> > flag which possibly be different with native byte-order, although they
> > could always be same.
>
> Uh. I think you somehow misunderstood how cross-compiling works. The
> compiler will output the same code whether you cross-compile or compile
> on the target system, that is the whole point of cross-compilation...
>
> [...]
> > If you insist, I could test it with powerpc native compile, but a
> > cross-compile could be hard ( by now I haven't done a cross-compile
> > for mplayer with different byte-order yet.)
>
> Well, I think this patch makes the code easier to understand in addition
> to working on big-endian...
>
> >   buf16[3] = burst_len;
>
> Seems more obvious than
>
> >   buf[6] = (burst_len) & 0xff;
> >   buf[7] = (burst_len >> 8) & 0xff;
>
> to me (though that is also due to the completely pointless "& 0xff").
>
> Greetings,
> Reimar Döffinger

Although you are right, I think we should try to figure out a way to
swap by output stream's format flag. We should use machine byte-order
only if there's no way to get the output stream's format.

Or we should always output little endian bytes from hwac3, and swap
bytes in ao modules if needed?

Or introduce a hwac3_be afm or a parameter for hwac3 to decide output byteorder?

-- 
Ulion