RTSP - 白手起家

RTSP - 白手起家

现在已经知道的一些信息:

1.RTSP协议实际上只是一个控制协议,实际数据还需要一个传输协议。不过RTSP也支持在同一个TCP 连接中传输数据.

2.Xine[3]有一个librtsp的库,Mplayer也是Port的这个部分.我已经把Mplayer的这个部分的代码剥离出来,已经可以单独编译了。

3.LiveMedia是一个功能比较完整的RTSP/RTP Library. 不过居然不支持RealAudio/RealVedio.

4.我真正关心的RealAudio/RealVedio Stream, 居然不是用RTP 协议传输的,是个什么RDT的Real自己的非标准协议. Mplayer/Xine的代码应该都支持这个协议.

5.RTSPget[1]是一个基于Xine code base的RTSP流下载工具,目前还不知道是不是好用.

6.A simplified RTSP cilent[4]是一个非常不错的入门资料, 比较容易在直观感性上建立对RTSP协议的概念。

7.Python这个方面的库和实现好像都比较稀少,有一个叫shtoom[6]的Project 是一个基于Python的VoIP实现。

8.实践证明4.这个消息是比较过时的。现在的RTSP流基本上都是标准的RTP 协议了。因此重新回头,实现一个基于LiveMedia的RTSPGet. 看看是否可以直接从MPlayer中剥离代码

Useful URL and reference

1/RTSPget http://users.comlab.ox.ac.uk/ ian.collier/Misc/rtspget/

2/librtsp http://rtsp.sourceforge.net/ http://cvs.sourceforge.net/ viewcvs.py/rtsp/librtsp/

3/xine http://xine.sourceforge.net/

4/A simplified RTSP client http://folk.uio.no/ meccano/reflector/smallclient.html

6/Using Python for Voice over IP http://divmod.org/ Home/Projects/Shtoom http://www.python.org/ pycon/dc2004/papers/6/

相关推荐
linux 下 select 编程 我们知道 select 是IO 多路复用的一个最简单支持,poll 和 epoll 是 select 的升级版。在 UNIX 网络编程第五章读书笔记 我们遇到这样一个问题:当客户端阻塞在 fgets() 等待客户输入的时候,服务器端断开连接。而客户端却不能及时知道,只有在客户输入完毕并发送到服务器的时候才知道连接已经断开,但是此时可能已经过了很长时间了。如果我们想及时知道服务器断开连接怎么办呢?   我们知道不管是 fgets() 等待客户输入还是 read() 从套接口读取数据,都是 IO 操作。我们不能阻塞在某个 IO 操作中一个,这样其他 IO 操作会无法进行,即使其他 IO 操作上有数据了我们也无法及时读取。select 的原理是这样的:我们将这些 IO 操作所要操作的文件描述符放到一起(比如一个数组中),然后阻塞在 select() 函数上,为什么要阻塞在这里呢?其实这时的 select 实在不停的遍历这个数组,查看其中的文件描述符上是否可读/可写,一旦可读/可写,select 返回,停止阻塞。然后我们对可读/可写的文件描述如做相应的操作即可。下面是 select 函数的原型:   int select(nfds, readfds, writefds, exceptfds, timeout)   nfds 是指定 select() 要遍历的最大文件描述符 + 1,readfds 就是放文件描述的数组,这个数组里面关心的是该数组中文件描述符的读事件,wretefds 也是放文件描述符的数组,这个数组里面关心的是该数组中文件描述符的写事件,exceptfds 也是放文件描述符的数组,这个数组关心的是该数组中文件描述符的出错事件。timeout 是 select 阻塞的时间。如果设置为 空指针,那么将永远阻塞下去直到某个描述符有事件发生(就绪)。否则的话就会在阻塞由 timeout 指定的时间后返回,无论关心的文件描述符是否有事件发生。select 返回有事件发生的文件描述符个数,失败返回 -1,超时返回 0!
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页