Big endian and little endian

Big/little endian issue, which has been wasted for more than two hours today, I would like to reiterate here to avoid ignoring this issue next time.

Big/little endian concepts:

The so-called Big-end mode stores the index data low (that is, the few digits after the smaller weights) in the memory's high location, while the data is high, stored in a low address in the memory, this storage mode is a bit similar to processing data as a string Order: The address increases from small to large, and the data is placed from high to low;

For example, 0x789e5799, but in actual use, 78 is used first, and then 9e.

The so-called small-end mode stores low data points in the low memory address, while the high data points are stored in the high memory address, this storage mode effectively combines the high and low addresses with the data bit permissions. The high address part has a high weight, and the low address part has a low weight, which is consistent with our logic method.

For example, it is opposite to big endian.

You can Google the introduction of these two models. Currently, both arm and DSP are in the small-end mode by default, but many of them can change the size of the end mode by setting.

At present, many complier are small-end models, but you writeCodeBoth modes should be supported at the same time, and macro should be used for switching. This test should be added to your test plan. This is necessary and will be analyzed below.

How to test the core or complier size-end mode. There is a simple way to add the following code (Google, some are simpler)

Short x = 0x1122;

Char X0 = (char *) & X) [0];

If X0 = 0x22, little endian.

 

The principle is very simple, but sometimes it is easy to make mistakes when dealing with this. I have two experiences.

The first time is AC3 decoder. the AC3 decoder reference code has a macro that controls little or big endian. However, to support block input and more frame output, in frame input and frame output mode, when the data sent to decoder process is insufficient, the storage format of the data must be restored, and the data needs to be directed to the outermost layer, and the corresponding buffer is spliced. This process is very error-prone, and we hope to be careful when encountering this situation.

Another point is that bitstreams that have passed the AC3 authentication are all stored on the big end, but all the music in the AC3 format is stored on the small end.

 

Another time is today, we have recently improved ape codec. The reference code was written in C ++ template, which is a bit difficult to read. For porting to startphone, I used C to rewrite it. The music in APE format is inconsistent with the code processing mode. If the code stream is a big end, the code processing is a small end. Ape processes bits in bytes. This is simpler. We should not consider how many bits are used like AAc/ac3.

The problem still lies in buffer splicing, or in order to support output in multiple modes, namely frame input and frame output, block input and more frame output.

The buffer at the API layer is of the unsigned char type, while the ape reference code operates the buffer in the int type.

When get one output frame data is used, the buffer used is exactly 4 alignment.

 

If not, there is a problem. For example, 0x789e57990x9e999db7. If 0x78 is used, the complete output frame data is obtained. I return to the API layer, put the data in the corresponding buffer, and then splice the buffer. 0xb7789e57

Decoder next frame, get the B7 data first, but this is incorrect. Correct, we should get 9e, and delete the correct data 0x99 during the operation.

 

Finally, modify the scheme: Change the ape bits operation to byte instead of int, and allow the code to support the little and big endian modes.

 

It is suggested that both audio and video codec support big/little endian mode and perform relevant tests.