猫头上的鹰－猫头鹰

     摘要: 随着VoIP和NGN技术的发展，H.323时代即将过渡到SIP时代，在H.323的开源协议栈中，Openh323占统治地位，它把一个复杂而又先进
的H.323协议栈展现在普通程序员的眼前，为H.323普及立下了汗马功劳。而然当在SIP时代，则出现了群雄割据的状况，SIP相对于
H.323简单，灵活，于是各种协议栈层出不穷，下面将详细对比最具有代表性的5个开源项目：OPAL,VOCAL,sipX,ReSIProcate,oSIP  阅读全文

     摘要: VoIP bookmarks from Klaus Darilion
Below you will find descriptions and links to SIP and RTP stacks, applications, test utilities, SIP proxies, SIP PBXs and STUN server and clients. Most of them are open source :-), but not all of them :-(

If you have any comments please feel free to contact me: --> klaus.darilion at pernau.at <--

There are also other VoIP related portals and link collections.

Note: I mainly searched for C/C++ stacks and applications. There also  阅读全文

     摘要: 注：其中的很多连接都失效了，但还是留着吧，最起码名称是对的。

网络资源（主要是流媒体资源）
想看更多的流媒体资源或其他的资源：可以看看：http://www.umsky.com/knowledge/Streaming/
voip书籍：
http://www.chinagk.org/technology/IPTech/001.htm
全球VOIP联盟
http://www.microvoip.com/thdmain01.htm
RTP库：
http://research.edm.luc.ac.be/jori/jrtplib/jrtplib.html
  阅读全文

     摘要: 我们的实验所用的代码都取自VideoNet。包括改造后的Karl Lillevold的Tmndecoder、改造后的Roalt Aalmoes 的h.263快速编码库TMN。同时，我们还会对VideoNet进行改造以对我们的代码进行测试，让它来发H263数据，S3C2410开发板来收数据。最后，当然是在S3C2410上进行收和发测试了。至于音频，后面再说吧。
VideoNet的原码可在下面下载：http://100.qqmdm.com/ContentPane.aspx?down=ok&filepath=tinnal%2fmedia%2fVideoNet_src.zip
该程序可以用于两个人在LAN/Intranet(或者Internet)上进行视频会议。现在有许多视频会议程序，每个都有各自的性能提升技术。主要的问题是视频会议视频帧的尺寸对于传输来说太大。因此，性能依赖于对帧的编解码。我使用快速h263编码库来达到更好的压缩率提高速度。该程序做些小改动也可以在Internet上使用。   阅读全文

     摘要: 好久没有写有关视频的东西了。前两周一个学习说要做视频相关的实验，就开了个题，用S3C2410实现H263视频会议。同时，也希望通过把这个开发过程写下来，汇聚了下个系列。
要完成H263的视频解压，而要完成视频的解压缩，又必须完成QCIF文件的播放。下面的播放器程的主程序。  阅读全文

     这段时间一直研究源码分析系统，后来发现了Code::Blocks这个编译器原码，就有了开发一个编译和调试内核IDE的想法。在为Code::Blocks是基于WxWidget编写的一个原码开放的IDE，可以在Windows和Linux下运行，而且是高度的插件化，一找到它我就爱上它了。和它相类似的还有codelite，不过这个程序结构考虑得不够Code::Blocks深入，所以最终，我选择了Code::Blocks开刀，它本来只是一个编译普通程序的编译器，和其它Linux下的编译器大相径庭的是，它采用了类似VC那种内部的项目文件管理而没有采用Makefile。所以最先需要的改动，就是增加支持Makefile工程的插件。

    由于Code::Blocks是基于WxWidget的，所以也花了很长的时间在它在面，然后是就Code::Blocks的内部结构。今天终于把Makefile工程的插件弄出来了，Code::Blocks太慢了（一是由于插件的方式比编一编译运行效率低，二是由于Code::Blocks内部的项目管理我们是不能绕过的，虽然我们不用，三是内核文件实在太多了，快2万个文件了）。真的有点灰心了。因为当时还考虑过用eclipse来开发的。

     摘要: Windows下的源码阅读工具Souce Insight凭借着其易用性和多种编程语言的支持，无疑是这个领域的“带头大哥”。Linux/UNIX环境下呢？似乎仍然是处于百花齐放，各有千秋的春秋战国时代，实际上，似乎其环境下的任何软件都是处于一种逐鹿中原的态势，也许这就是“集市”之于“大教堂”的优势所在吧！主要的交叉索引工具有：ctags、cscope、global、lxr、KScope、sourcenav、calltree、CodeViz、ncc、gprof等。下面将就各软件的优劣作一简单介绍。这里面当中，我当前分析过他们的源码的有lxr、sourcenav、calltree、ncc。现在正在sourcenav的基础上进行我需要的改造以更合适分析内核需要。KScope需要进一部考察和分析，如果KScope的代码分析能力（也就是scope的能力）跟得上sourcenav可能到时会放弃sourcenav转到KScope开发，因为sourcenav的界面和交互性都不怎么好。  阅读全文

     摘要: 自从写了一些视频的东西后就很久没有写东西了，视频的实例打算有时间的话和我培训班的学生弄出来以后再接着写。

这段时间的前半部份重新看了一下2.4内核的原码，对于网上很多人说2.4内核过时，要读就读2.6的，要写就写2.6的内核的说话，我其实挺有意见的。我认为经典的原码没有过时这一说法，嵌入式不是PC，本来就是本着够用的前提下越低成本越好的。谁敢说八几年代产的8051过时。相对于动咋几M的2.6内核，才几百K的2.4真的是娇小玲珑。

因为前几次都是以学习的方式去读，这一次也不例外（第一点的记性差，读完就忘，第二点是因为第一次读都有新感受），但这一次目和性有点变了，就是不单想把每一个局部原源读懂，而且想进一步的弄明百函数之间、文件之间、硬件相关代码和硬件完关代码之间的关联。特别的，是硬件相关代码和硬件完关代码的API。包括如下：
1：新加一个体系结构，我们应该实现那些接口
2：在一种体系结构如ARM中，新加一个支持平台，我们应实现那些接口
  阅读全文

     摘要: JPEG 的图片使用的是 YCrCb 颜色模型, 而不是计算机上最常用的 RGB. 关于色彩模型, 这里不多阐述. 只是说明, YCrCb 模型更适合图形压缩. 因为人眼对图片上的亮度 Y 的变化远比色度 C 的变化敏感. 我们完全可以每个点保存一个 8bit 的亮度值, 每 2x2 个点保存一个 Cr Cb 值, 而图象在肉眼中的感觉不会起太大的变化. 所以, 原来用 RGB 模型, 4 个点需要 4x3=12 字节. 而现在仅需要 4+2=6 字节; 平均每个点占 12bit. 当然 JPEG 格式里允许每个点的 C 值都记录下来; 不过 MPEG 里都是按 12bit 一个点来存放的, 我们简写为 YUV12.   阅读全文

     摘要: 1. 色彩模型

JPEG 的图片使用的是 YCrCb 颜色模型, 而不是计算机上最常用的 RGB. 关于色彩模型, 这里不多阐述. 只是说明, YCrCb 模型更适合图形压缩. 因为人眼对图片上的亮度 Y 的变化远比色度 C 的变化敏感. 我们完全可以每个点保存一个 8bit 的亮度值, 每 2x2 个点保存一个 Cr Cb 值, 而图象在肉眼中的感觉不会起太大的变化. 所以, 原来用 RGB 模型, 4 个点需要 4x3=12 字节. 而现在仅需要 4+2=6 字节; 平均每个点占 12bit. 当然 JPEG 格式里允许每个点的 C 值都记录下来; 不过 MPEG 里都是按 12bit 一个点来存放的, 我们简写为 YUV12.
  阅读全文