lidp的专栏

android 系统级 bug audio latency

李小 — Fri, 01 Jul 2011 14:35:00 +0800

android 一直没有提供 real-time audio, 现有的音频延时大概 500ms~1000ms, 这对于voip通信来讲是不可容忍的，此bug 在android 上一直存在，引起大量开发者的抱怨，下面为几个链接。 http://forums.adobe.com/message/3684365， http://www.androidannoyances.com/post/38 http://code.google.com/p/android/issues/detail?id=3434#makechanges 上面 3434 bug id 已经存在两年，其中一条内容为： My next phone will probably be an iPhone mainly due to this issue. Nuff said?!?! 可见次你问题对开发者的影响。。。

git 使用详解

李小 — Thu, 30 Jun 2011 23:56:00 +0800

考虑到CVS的一些局限性，最近和同事在公司推行Git。
其实，如果推行SVN的化，可能推行的难度会降低很多。不过lark说既然推行一个新的版本管理工具，总要花费一定的时间进行培训、部署、转换。而推行Git和SVN的代价不如想象中差距那么大。因此，不如就多花些精力推行Git ，可以带来更多的好处。这个想法说服了我。然后就开始筹备了。我发现网上很多git教程对一些基础命令（比如git-reset）的介绍还是不够清楚。另外，介绍git1.5的少，介绍git1.4的多。此外，对于如何基于Git合作开发，介绍的内容也是少之又少。因此，决定写一份教程，以减少在公司推广Git的培训代价。
其实我也是一个Git的新手。写这份教程也是我自己学习和摸索git的过程，其中基于Git进行合作开发的模式参考了CVS，应该是很初级的合作模式。但是当前自己也只能做到这一步了。教程所述都是自己通过试验验证的。至少可以满足公司基本的合作开发。教程写完后，谢欣说可以放到blog与大家共享。我觉得是个不错的主意。一方面我觉得这个文档应该可以给git的新手一些帮助，另一方面也欢

h264 rtp payload

李小 — Mon, 27 Jun 2011 14:12:00 +0800

H.264 视频 RTP 负载格式
1. 网络抽象层单元类型 (NALU)
NALU 头由一个字节组成, 它的语法如下:
      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+
F: 1 个比特.
forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.
NRI: 2 个比特.
nal_ref_idc. 取 00 ~ 11, 似乎指示这个 NALU 的重要性, 如 00 的 NALU 解码器可以丢弃它而不影响图像的回放. 不过一般情况下不太关心
这个属性.
Type: 5 个比特.
nal_unit_type. 这个 NALU 单元的类型. 简述如下:
0     没有

Using libavformat and libavcodec

李小 — Tue, 21 Jun 2011 18:33:00 +0800

The libavformat and libavcodec libraries that come with ffmpeg are a great way of accessing a large variety of video file formats. Unfortunately, there is no real documentation on using these libraries in your own programs (at least I couldn't find any), and the example programs aren't really very helpful either. This situation meant that, when I used libavformat/libavcodec on a recent project, it took quite a lot of experimentation to find out how to use them. Here's wh

Ffmpeg快速应用开发

李小 — Tue, 21 Jun 2011 18:25:00 +0800

Ffmpeg 中的Libavformat 和 libavcodec库是访问大多数视频文件格式的一个很好的方法。不幸的是，在开发您自己的程序时，这套库基本上没有提供什么实际的文档可以用来作为参考（至少我没有找到任何文档），并且它的例程也并没有太多的帮助。这种情况意味着，当我在最近某个项目中需要用到 libavformat/libavcodec 库时，需要作很多试验来搞清楚怎样使用它们。这里是我所学习的－－希望我做的这些能够帮助一些人，以免他们重蹈我的覆辙，作同样的试验，遇到同样的错误。你还可以从这里下载一个demo程序。我将要公开的这部分代码需要0.4.8 版本的ffmpeg库中的 libavformat/libavcodec 的支持（我正在写最新版本）。如果您发现以后的版本与我写的程序不能兼容，请告知我。在这个文档里，我仅仅涉及到如何从文件中读入视频流；音频流使用几乎同样的方法可以工作的很好，不过，我并没有实际使用过它们，所以，我没于办法提供任何示例代码。或许您会觉得奇怪，为什么需要两个库文件 libavforma

音视频同步-时间戳

李小 — Tue, 21 Jun 2011 18:19:00 +0800

媒体内容在播放时，最令人头痛的就是音视频不同步。从技术上来说，解决音视频同步问题的最佳方案就是时间戳：首先选择一个参考时钟（要求参考时钟上的时间是线性递增的）；生成数据流时依据参考时钟上的时间给每个数据块都打上时间戳（一般包括开始时间和结束时间）；在播放时，读取数据块上的时间戳，同时参考当前参考时钟上的时间来安排播放（如果数据块的开始时间大于当前参考时钟上的时间，则不急于播放该数据块，直到参考时钟达到数据块的开始时间；如果数据块的开始时间小于当前参考时钟上的时间，则“尽快”播放这块数据或者索性将这块数据“丢弃”，以使播放进度追上参考时钟）。可见，避免音视频不同步现象有两个关键——一是在生成数据流时要打上正确的时间戳。如果数据块上打的时间戳本身就有问题，那么播放时再怎么调整也于事无补。假如，视频流内容是从0s开始的，假设10s时有人开始说话，要求配上音频流，那么音频流的起始时间应该是10s，如果时间戳从0s或其它时间开始打，则这个混合的音视频流在时间同步上本身就出了问题。打时间戳时，视

关于 frame的一些基本知识

李小 — Tue, 21 Jun 2011 18:18:00 +0800

关于 frame的一些基本知识只是摘抄了一部分，供初学者参考。 b.帧速率：帧速率是每秒显示的图像数。标准影片(NTSC) 是29.97 帧第秒 (fps)，电影是每秒24 帧fps。欧洲标准是(PAL) 25 帧fps。如果你对你影片的尺寸不是太注重的话，保留默认的Current选项。这将会使你制作的影片的帧速率和源文件一致。不管怎样，如果你想降低带宽和CPU的占用，你可以选择一个低的帧速率。高的帧速率拥有高的品质的，但文件尺寸也更大。如果你选择的帧速率低于你的源文件的帧速率，一些帧将被删除。如果你选择的帧速率比你的源文件高的话，已有的帧将被重复 (不推荐，因为增加了尺寸，但品质没有提高)。如果你选择的帧速率低于你的源文件的帧速率，使用一个你当前帧速率的简分数，比如 1/2， 1/3 等等。例如，你当前的帧速率是30 (29.97)，使用15 或10。但话说回来了，要最好的H.264品质，最好保留Current，当前）设置。c.关键帧：很多编码软件使用frame differencing（帧差

RFC 3263 SIP: SIP 定位服务器

李小 — Sat, 18 Jun 2011 18:07:00 +0800

............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |------------- | Proxy | .
. | 1 | . . | 2 | .
.

VoIP技术应用中存在的问题的分析研究

李小 — Sat, 18 Jun 2011 13:14:00 +0800

摘要 VoIP技术是由原来的一种互联网上的增值应用发展成为一种得到广泛应用的通信技术，较传统的PSTN通信具有明显优势，但在实际应用中也面临诸多问题。文章简述了VoIP基本原理及其分析研究了实际应用中VoIP技术现存问题，并提出了相应的解决方法，最后讨论了VoIP技术的发展方向和研究趋势。关键词 VoIP；QoS；攻击；语音编码
1 引言 VoIP 又称 IP电话或IP网络电话，是Voice over IP的缩写，这种技术通过对语音信号进行编码数字化、压缩处理成压缩帧，然后转换为IP数据包在IP网络上进行传输，从而达到了在IP网络上进行语音通信的目的。IP电话极大地改进了网络带宽的利用率，大大降低了通信的费用，它的广泛应用也促进了宽带多媒体应用的发展。VoIP可以在IP网络上便宜地传送语音、传真、视频和数据等业务，如统一消息、虚拟电话、虚拟语音/传真邮箱、查号业务、Internet呼叫中心、Internet呼叫管理、电视会议、电子商务、传真存储转发和各种信息的存储转发等。VoIP对于传统的电信业

IMS网络的功能实体介绍

李小 — Tue, 14 Jun 2011 15:56:00 +0800

http://blog.csdn.net/foolskindom/archive/2009/12/16/5018547.aspx

2.2 IMS实体和功能描述
本节讨论IMS实体和关键功能。这些实体可以被粗略的分为六大类：会话控制和路由实体族（CSCFs）、数据库实体（HSS、SLF）、互联实体（BGCF、MGCF、IM-MGW、SGW）、服务相关实体（应用服务器、MRFC、MRFP）、支持性实体（THIG、SEG、PDF）和计费相关实体。需要理解一个非常重要的事实，IMS标准没有详细描述网络实体的内部功能。例如，HSS内部有三个功能部分：IMS功能、CS域所需的必要功能和PS 域所需的必要功能。3GPP标准没有描述IMS功能部分PS功能部分如何交互。相反的，它描述实体间的接口和接口支持的功能（例如CSCF如何从HSS获取用户数据）。2.3节将会介绍这些不同的接口。另外，GPRS网络中的功能体将会在本节结束部分介绍。
2.2.1 代理CSCF
代理呼叫会话控制功能实体（P-CSCF）是用户接入IMS过程中的第