64

run函数的基本流程是，每次从文件中读2048个字节到sockbuf缓冲区，然后在MergeBuffer()函数中一个字节一个字节的拷贝到nalbuf缓冲区并识别0x00000001开始字做nal分割，再把nalbuf中完整的nal调用DecoderNal做解码，依返回值判断是否刷屏，解码sps，pps等nal不用刷屏。
因为此开源代码是从网络播放器中删减而来，所以是sockbuf。
NalBufUsed和SockBufUsed是计数控制变量。
int mTrans=0x0F0F0F0F 为监视是否是0x00000001开始字而定义的变量，其初值尽量和0x00000001开始字不相关，可以是其他值。

或者你看一下h264的标准可能会更好的理解。

刚接触android方面的开发，博主的共享很有指导性意义，用Cortex-A9运行demo发现解码720x576帧率跟不上，开始怀疑解码器是不是有问题，从ffmeg源码编译后重新封装libh264android，发现效率并没有实质性提高（解码稳定性貌似要强许多）,后来又怀疑是否是绘制的问题，换成用OpenGL绘制，也没有实质性提高。跟踪后发现问题出在颜色空间转换的地方，YUV转RGB效率太低了，不转单单解码可以达到25fps，加上转换就会降一半，试了试libstagefight里的转换函数，效率一样的。真不知道mediaplayer解码怎么弄的，1080p都能解得那么流畅，郁闷啊！

对你这个问题，如果是我，我会找JM参考代码跑一下，看是否正常，如果不正常，那就是码流出了问题，如果JM代码正常，我会用最新的ffmpeg源码在linux下编译跑一下看是否正常，如果正常，那就重新移植ffmpeg，如果不正常，那就是你的编码器打开了很生僻的开关，而此开关ffmpeg不支持。
如果JM代码正常，ffmpeg代码不正常，要不找其他开源的能正确跑的解码器，从其他的地方移植。或者debug JM的代码，看码流到底打开了什么鬼鬼开关，自己在ffmpeg代码中添加上对这个开关的支持，当然这个难度很大。