Author Archive: Yumi Chan

Breif Description of nal_ref_idc Value in H.246 NALU

I am so sorry for my late update because of my study!
A quite update of myself: I have actually stopped working on H.264 and MP4 for some time but will probably pick up again in the near future.

As in the article Introduction to H.264: (1) NAL Unit, Suji Mani asked what is the exact meaning of different values in nal_ref_idc. In fact, nal_ref_idc is base on “Start Code Value” and represents the priority of the current frame (i.e. how important of the frame – the higher the value, the more important the frame). Here is a list of nal_ref_idc values with the corresponding Start Code Type:

Free CyberLink PowerDirector 12 LE Giveaway!!

CyberLink cooperates with SharewareOnSale to offer a PowerDirector 12 LE giveaway recently. For only 3 steps, you can get a free copy! Only 3 days left! A good news is that this is a 1-computer lifetime license for home or business use, which means you can install it in your company computers!

PowerDirector 12 LE Giveaway

Software Name: PowerDirector 12 LE
Giveaway Link:, or,

The procedure of getting the offer is very similar for both links. I just take one of them as an example to show you how to get it.

Obtain a list of process scheduling policy and priority

Normally, you can read the file /proc/[pid]/sched and get the related information. But since I am using a simplified one, the sched file is not presented. And I need to figure out another way to get it. I finally found there is a C library, <sched.h>, to do that. You can find the following declarations in the library.

In this case, we only need sched_getparam() to obtain scheduling priority and sched_getscheduler() to obtain scheduling policy.

How to get the number / id of processes and threads?

Since I am working on Hi3518 with Linux, in order to reduce the use of computing power of the device, I used a simplified version of Linux. So, most of the applications are gone or are simplified without any option. I just summarized the methods I can use on Hi3518 and should be also work on some other Embedded Linux.

In fact, the applications in Linux usually obtain related information by reading the files in /proc. Under /proc, you can see a lot of folder, some of them are in numbers. Those folders named in numbers, which are process ids (PIDs) represent the processes run in the system. Thus, you can see the details of each process in each folder.


where *** are the corresponding process pid.

Difference: Program VS Process VS Thread

Here are the definitions and the explanations from Wikipedia.


A computer program, or just a program, is a sequence of instructions, written to perform a specified task with a computer.


A process is an instance of a computer program that is being executed. It contains the program code and its current activity. Depending on the operating system (OS), a process may be made up of multiple threads of execution that execute instructions concurrently.

Embedded Linux: How to run a shell script at startup on Hisilicon’s Hi3518?

I am now developing on a Hisilicon’s chip, Hi3518E. The Linux kernal is built and compiled from the code of the SDK provided by Hisilicon. Thus, I think what I am going to say is also valid for other chips from Hisilicon.

I have studied Hi3518 for a few months. I now want to load some drives and programs at startup automatically so I spent some time to figure out how to do it on this chip. First of all, since I needed to run a set of commands, I wrote a Shell Script to organize all the commands together. Thus,I can run them all when I run the script once. Then, put the script into startup. I am not going to talk about how to write a Shell script as I don’t really know much about it.

0. Basic Knowledge

/etc/init.d/ : init.d is a folder for containing Unix/Linux Shell Scripts. If you enabled init.d in your kernal, the system will load and run the scripts placing here when it turns on. In common, all the init scripts of the services needed in a system are placed in this folder. So, you should find it on almost every Linux.

Avoid writing 0x0A as 0x0D0A: Be careful of File Access Mode

When dealing with file I/O in C/C++, we should first open a file with fopen:
FILE * fopen ( const char * filename, const char * mode )
The parameter mode refers to “File Access Mode“. You have the following options (from

“r” read: Open file for input operations. The file must exist.
“w” write: Create an empty file for output operations. If a file with the same name already exists, its contents are discarded and the file is treated as a new empty file.
“a” append: Open file for output at the end of a file. Output operations always write data at the end of the file, expanding it. Repositioning operations (fseek, fsetpos, rewind) are ignored. The file is created if it does not exist.
“r+” read/update: Open a file for update (both for input and output). The file must exist.
“w+” write/update: Create an empty file and open it for update (both for input and output). If a file with the same name already exists its contents are discarded and the file is treated as a new empty file.
“a+” append/update: Open a file for update (both for input and output) with all output operations writing data at the end of the file. Repositioning operations (fseek, fsetpos, rewind) affects the next input operations, but output operations move the position back to the end of file. The file is created if it does not exist.


Introduction to H.264: (2) SODB vs RBSP vs EBSP

Here is a summary of the relationship between SODB, RBSP, EBSP, NALU and H.264 Byte Stream.
SODB: String of Data Bits
RBSP: Raw Byte Sequence Payload
EBSP: Encapsulate Byte Sequence Payload

SODB + RBSP Stop bit + 0 bit(s) => RBSP

RBSP part 1 + 0x03 + RBSP part 2 + 0x03 + … + RBSP part n => EBSP

NALU Header + EBSP => NALU

In Byte Stream Format (Annex B),

Start CodeNALU + … + Start CodeNALU => H.264 Byte Stream

String of Data Bits (SODB)


3.149  string of data bits (SODB): A sequence of some number of bits representing syntax elements present within a raw byte sequence payload prior to the raw byte sequence payload stop bit. Within an SODB, the left-most bit is considered to be the first and most significant bit, and the right-most bit is considered to be the last and least significant bit.