[FFmpeg-devel] [PATCH 06/10 rev2] spdifenc: fix byte order on big-endian systems

[Reimar Döffinger]

On 1 jan 2011, at 10:41, Anssi Hannula <anssi.hannula at iki.fi> wrote:
> On 01.01.2011 11:38, Reimar D?ffinger wrote:
>> On 1 jan 2011, at 06:38, Anssi Hannula <anssi.hannula at iki.fi> wrote:
>> 
>>> The preamble and final odd byte were outputted in the wrong byte order
>>> on big-endian systems.
>>> 
>>> ---
>>> 
>>> I'm wondering if this patch would be a better choice. All our audio
>>> decoders output native-endian samples. As this muxer is usually used in
>>> place of an encoder, it would be logical for it to have its output in
>>> native-endian as well.
>>> 
>>> However, this would cause (AFAIK) the muxer to be the only one that has
>>> different output depending on system endianness.. Don't know if that is
>>> very big an issue, though.
>> 
>> It is completely unacceptable, it makes it untestable.
>> You could create two muxers, one for each endianness, which is a good idea since AFAIK e.g. OSX expects the big-endian format even on x86.
>> If you really want you can also add a third one that outputs in native endianness, it's not a big issue if we don't/can't (easily) test that one.
> 
> OK. Do you think 2 (or 3) different muxers is better than using
> AVOptions for it?

Do we have muxer-specific AVOptions? Also we do currently use different muxers to handle all the different variants of the mov format.
But I don't have much of an opinion on this.
Philosophically I'd consider options more appropriate for minor stuff that will not generally affect playability. Of course this doesn't help much here, since in principle it would be trivial to auto-detect the endianness of such a file an play it in both cases.
But there is one more thing that irritates me: in MPlayer when converting between big- and little-endian SPDIF formats, the data part needs to be byte-swapped, too. Since I see no such code in your patch I suspect that we are missing something here...
>