2006-2-27日

decoder_file_stream流类提供了一个4096字节的缓冲区，对缓冲区的操作有get_bits_1()和get_bits_2(),缓冲区有指向当前所读字节的指针uchar *Pin_buf_ofs。缓冲区为 uchar in_buf[JPGD_INBUFESIZE + 128]，不知道padd指的是什么。还有缓冲区未读字节数in_buf_left,当get_bits_1()和get_bits_2()读到超过缓冲区时（这两个函数都是读一个uint类型的位缓冲区bit_buf的，这个缓冲区是32位，每次读的时候都是读的高n位，n必须小于等于32，并且用一个整数bits_left来记录剩下未读的位数，当调用get_bits时读得超过了剩余位数，将调用get_char()来读缓冲区，一次读两个uchar,并且放到位缓冲区的高16位。get_char()函数检查in_buf_left，当为0时就调用prep_in_buffer(),从而重新开始读file_stream，填充缓冲区）。

这是全部的对输入的读取操作的函数，可以看出，为了使得代码对两种字节序都适用，get_bits这族函数写的很复杂，并且操作也较多，如果重写，可以牺牲代码的可移植性，采用一次读一个int字节，甚至更多，来提高效率，因为arm是采用big_endian，跟jpeg文件的字节序是一样的。

huffman解码的几个函数写的很复杂，还并没完全看懂。

读取标记并且初始化的函数写的也很复杂，原因是它是要支持progressive jpeg的，所以要支持重读标记，重新初始化，而我们现在只需要在开始读一下并且初始化一下就可以了，所以我作了简化。我希望还能有进一步的简化。

write_tga部分已经率先改成了c，但是前面的两个类decoder_file_stream和jpeg_decoder因为连接的紧密，以及函数和变量的众多，暂时还不好下手（已经做了数次尝试，但均不成功）。