[FFmpeg-devel] Unified CPU Endianness for framecrcenc

[Michael Niedermayer]

On Sat, Jan 26, 2008 at 11:19:20PM -0500, Rich Felker wrote:
> On Sun, Jan 27, 2008 at 04:50:51AM +0100, Michael Niedermayer wrote:
> > On Sat, Jan 26, 2008 at 03:21:19PM -0800, Mike Melanson wrote:
> > > Hi,
> > > 
> > > I am using libavformat/framecrcenc.c for automated testing on the FATE
> > > Server ( http://fate.multimedia.cx ). For those who don't know, '-f
> > > framecrc' is a neat tool that "muxes" a file by simply running the Adler
> > > CRC algorithm over incoming packets and printing some frame stats to the
> > > stdout. It's great for validating bit accuracy for file/codec types that
> > > are expected to be bit exact.
> > > 
> > > I am having trouble with certain formats, however. For example, if the
> > > data is decoded as 15- or 16-bit RGB/BGR, the data will be stored in CPU
> > > endianness. Would it be acceptable to have a special "#ifdef BIG_ENDIAN"
> > > case in the muxer that swaps bytes before running the CRC? Or is there a
> > > better solution to the problem? I'm asking before I do the coding work.
> > 
> > convert to rgb24 or bgr24 maybe ...
> 
> If the format of frames being sent to the _muxer_ depends on the host
> cpu endianness, something is seriously broken. 

well, decoders output the native colorspace, and raw muxers store that
doing anything else by default (if it were supported) would mean
doing an unneeded colorspace convertion step by default
decoders generally cant easily work with bswaped rgb15/16 so they have
to output the native one ...


> LE/BE versions of
> RGB15/16 should be considered separate formats...

we do not support non native rgb15/16 currently, and if we did there would
be native/non native LE and BE variants (well only 2 and the other 2 set per
#define and #ifdef WORDS_BIGENDIAN)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080127/f82222ea/attachment.pgp>