[FFmpeg-devel] Unified CPU Endianness for framecrcenc

[Mike Melanson]

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 ...

Did you mean that I should actively convert 16-bit data to 24-bit data 
before running it through the CRC?

I have been sitting on this issue for awhile. It's time to bring it back up.

I have been thinking of a few different solutions to the problem.

1) Swap data in buffer before sending it to the CRC. I don't like this 
idea. The buffer might be reused by the video decoder. The workaround 
would be to allocate a local buffer for swapping.

2) Swap the data in the CRC function. I was thinking of specifying an 
extra parameter where 2 would indicate swapping pairs, 3 would indicate 
bytes 1 and 3 of triplets, and 4 would perform a 32-bit swap. The swaps 
would occur as the bytestream is being traversed.

3) Create new CRC calculators that perform the swapping is step 2.

Are any of these ideas plausible or am I way off track on this?

	Thanks...
-- 
	-Mike Melanson